I'm a web developer of WebRTC based web app for video and audio calls. After updating to iOS 26.1 beta I noticed, that my app can't use microphone anymore.
When I'm calling to getUserMedia with audio set to true, Safari returns error "No AVAudioSessionCaptureDevice device".
Other WebRTC demo apps also can't access microphone on this firmware.
And maybe it's connected somehow, but safari can't detect connected AirPods Pro 2 as an input device.
So, this bug brakes any WebRTC app, that uses microphones.
Explore the integration of web technologies within your app. Discuss building web-based apps, leveraging Safari functionalities, and integrating with web services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I am posting here because we have an urgent issue affecting the operation of our service and are in need of a solution after our own analysis has come up with few answers.
Beginning in iOS 18.2.x, we experienced exactly the same issue as the author of this thread, as we are also operating a service that allows for device certificate login for users configured to require one:
https://developer.apple.com/forums/thread/767374
The author seems to have resolved the issue but the fix mentioned in the thread did not resolve our problem for iOS devices with iOS 18.2.x installed and the contents of that private support ticket are, of course, not visible to us. Furthermore, we have a different issue that surfaced with the release of iOS 18.3.x.
Namely, the issue in iOS 18.3.x is more severe than the one in iOS 18.2.x, in that instead of simply taking a long time for the certificate/identity selection dialog to appear, it simply fails immediately and is returning a “no certificate selected” response to our server.
One thing to note here is that, curiously, if we wait for several seconds (about 10-15 seconds) this behavior is not replicated. So, it seems there is potentially something going in the background, and the certificate selection process will only occur successfully like before if we wait. This is a very unideal workaround.
After entering user credentials, we have the user navigate to a dedicated certificate authentication page. On the BIG IP side, upon users visiting this page, we have it configured to apply an SSL profile that contains appropriate CAs for the given user, and then requests to the browser that a new connection requiring a certificate be made.
We are investigating this by checking logs in in a variety of places:
We can verify in BigIP logs that a response is being returned to the server without a certificate included. For the sake of our application, this is handled as a “user did not select a certificate” event, and thus the attempted login is failed. Using the MacOS “Console” application, we are able to see the following logs from the “trustd” process of the target iOS 18.3.x device:
Failure case:
debug 11:19:49.648581+0900 trustd XPC [com.apple.WebKit[1034]/1#25 LF=0] operation: trust_evaluate (8)
debug 11:19:49.648766+0900 trustd complex trust settings anchor
Successful case (after waiting 10-15 seconds after initial login page load/before moving to certificate page):
debug 11:26:02.803153+0900 trustd XPC [MobileSafari[1031]/1#169 LF=0] operation: trust_evaluate (8)
debug 11:26:02.804219+0900 trustd non ev score: 121 <private>
There appears to be no attempt by MobileSafari to initiate the display of a certificate selection window in the failure cases. The iOS device is swift to return a response with no certificate selected to Big IP, and the result of “no certificate selected” is thus propagated through Big IP and ultimately to our web service.
Does anyone have any advice or information on the following?
Recommended tools to gather more data that may be pertinent.
Any ideas on changes in iOS 18.2.x+ that could have resulted in the behavior changing as described above?
If more information is necessary, I will do my best to supply it. Thank you in advance!
Topic:
Safari & Web
SubTopic:
General
Hi, We are facing a major issue with our application. We are using FolioReaderkit to read epub files. Currently, it's working on the iOS 18.1 device and simulator, but it's not working on the iOS 18.2 and later version devices.
we are facing this error in Folioreaderkit
I use WKWebView to display a webpage that requires authentication through an authentication provider. This works as expected, but when I close and reopen the app, I have to reauthenticate. However, if I open the same page in Safari, I only have to authenticate once. If I close Safari and reopen it, the page displays without prompting me to authenticate again. I see some cookies stored in httpCookieStore, so I assume that storing cookies works. Does anyone have an idea why authentication is not persistent between app launches? Thanks in advance.
Best regards,
Marc
On my native app, will open a wkWebview to display some content. And it will crash on iOS26:
*** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan 103.667]. Layer: <CALayer:0x14c2457d0; position = CGPoint (0 0); bounds = CGRect (0 0; 0 48); delegate = <_UIEditMenuListView: 0x14c273980; frame = (nan 0; 0 48); anchorPoint = (inf, 0); alpha = 0; layer = <CALayer: 0x14c2457d0>>; sublayers = (<CALayer: 0x1306320a0>, <CALayer: 0x14c245a70>); opaque = YES; allowsGroupOpacity = YES; anchorPoint = CGPoint (inf 0); opacity = 0>'
Is this code invalid on a phone running xcode16 iOS18?
Class cls = NSClassFromString(@"WKBrowsingContextController");
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:");
if ([(id)cls respondsToSelector:sel]) {
[(id)cls performSelector:sel withObject:@"http"];
[(id)cls performSelector:sel withObject:@"https"];
}
}
Topic:
Safari & Web
SubTopic:
General
I recently upgraded my device from IOS 18.4 to IOS 26. My web extension has disapeared from safari. I can see it in Settings > Apps > Safari > Extensions and when I turn it on and re-open safari. I just get a mesasge that says "{extension name} is no longer avaiable". I have tried Manifest V2 and Manifest V3 both yield the same results. The current production extension bundled with the IOS app has the same problem. I can no longer use or test my own extension !? Help please !
I am currently operating an app using an embedded web server that communicates over local HTTP.
Recently, when opening Safari, I started encountering the following error message:
"Safari cannot open the page. Error: Failed to navigate to an HTTP URL with HTTPS-only mode enabled."
However, I am currently in a situation where switching to HTTPS is difficult. Are there any solutions to resolve this issue besides using HTTPS?
Thank you.🙏
Hello,
I'm not able to get the webauthn attestation statement using the option (attestation.direct) on Safari. The answer I get is a fmt of none and a aaguid of zeros.
The same code works on Chrome and I was able to get a none zero aaguid and a packed fmt attestation.
Can you explain why this does not work on Safari ?
Thank you.
I am encountering an issue where we are unable to run or launch Safari Driver in our automation tests using macOS. When attempting to run safaridriver -p 8888 from the terminal, we receive the following error message:
ERROR: safaridriver could not launch because it is not configured correctly or you need to authenticate. Re-run safaridriver(1) and pass the '--enable' flag to configure and/or authenticate.
For more information, consult the safaridriver(1) man page.
Despite running sudo safaridriver --enable as an administrator (even as root), the issue persists.
I’ve searched through various online forums and GitHub repositories but couldn’t find a working solution. Some references are:
Apple Developer Forum Thread: https://forums.developer.apple.com/forums/thread/762321
GitHub Issue: https://github.com/SeleniumHQ/selenium/issues/11381
Hello WebKit Team,
I’m writing to ask if iOS provides a native way to intercept AJAX (XMLHttpRequest or fetch) calls inside WKWebView.
On Android, this is handled via:
shouldInterceptRequest(WebView view, WebResourceRequest request)
but iOS currently seems to have no equivalent.
We’ve tried:
WKURLSchemeHandler → works only for custom schemes
URLProtocol with WKProcessPool → unreliable for AJAX in WebView
JavaScript injection → partial and unofficial
Could you please clarify:
Is there a recommended native approach to intercept AJAX requests?
If not supported, is it planned for future releases?
Any official workaround or guidance?
This is critical for debugging, analytics, and compliance in hybrid apps.
I want to migrate from a Safari App Extension to a Safari Web Extension, but don't know how to get rid of the message, telling users that my extension can access their passwords. Here is a message which I see:
I was thinking that this might be because all Safari Web Extension get this type of access, but I have a Safari Web Extension which does not require such level of access:
Here is the manifest:
{
"manifest_version": 2,
"default_locale": "en",
"name": "__MSG_extension_name__",
"description": "__MSG_extension_description__",
"version": "1.1",
"icons": {
"48": "images/icon-48.png"
},
"background": {
"scripts": [
"background.js"
],
"persistent": true
},
"browser_action": {
"default_popup": "popup.html",
"default_icon": {
"16": "images/toolbar-icon-16.png"
}
},
"permissions": [
"nativeMessaging", "tabs"
]
}
and here is the Info.plist file:
Here is the entire code of the extension:
https://github.com/kopyl/web-extension-simplified
Is it possible to open the native app from a web extension?
I have tried creating a new tab that uses the app's URL scheme but the UI asking the user to open the app is not shown until the new page UI is dismissed.
Creating a tab with an HTTPS URL that the app is setup to handle does not work and always the link in a new tab.
I tried sending a message to the app extension and using NSExtensionContext.open(_:completionHandler:) but the URL is not opened and the closure received false, indicating it was not handled.
Having the option to link back to the native app would be very useful.
Starting in iOS 26 (tested on 26.1), when I use any of the “policy” methods of WKNavigationDelegate to return an action policy of cancel I get a trace like this printed to console:
1 0x18de71bbc WebKit::WebFramePolicyListenerProxy::ignore(WebKit::WasNavigationIntercepted)
2 0x18db3dd50 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)::$_0::operator()(WKNavigationActionPolicy, WKWebpagePreferences*)
3 0x100189e5c $sSo24WKNavigationActionPolicyVIeyBhy_ABIeghy_TR
4 0x100189d38 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctF
5 0x100189df4 $s16WebkitPolicyTrap14ViewControllerC03webD0_06decideB3For15decisionHandlerySo05WKWebD0C_So18WKNavigationActionCySo0lmB0VctFTo
6 0x18db255c0 WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction(WebKit::WebPageProxy&, WTF::Ref<API::NavigationAction, WTF::RawPtrTraits<API::NavigationAction>, WTF::DefaultRefDerefTraits<API::NavigationAction>>&&, WTF::Ref<WebKit::WebFramePolicyListenerProxy, WTF::RawPtrTraits<WebKit::WebFramePolicyListenerProxy>, WTF::DefaultRefDerefTraits<WebKit::WebFramePolicyListenerProxy>>&&)
7 0x18dea9848 WebKit::WebPageProxy::decidePolicyForNavigationAction(WTF::Ref<WebKit::WebProcessProxy, WTF::RawPtrTraits<WebKit::WebProcessProxy>, WTF::DefaultRefDerefTraits<WebKit::WebProcessProxy>>&&, WebKit::WebFrameProxy&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)
8 0x18dea7a34 WebKit::WebPageProxy::decidePolicyForNavigationActionAsync(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)
9 0x18d9cbbf4 void IPC::handleMessageAsync<Messages::WebPageProxy::DecidePolicyForNavigationActionAsync, IPC::Connection, WebKit::WebPageProxy, WebKit::WebPageProxy, void (IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(IPC::Connection&, WebKit::NavigationActionData&&, WTF::CompletionHandler<void (WebKit::PolicyDecision&&)>&&))
10 0x18d9c7728 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
11 0x18e49a0d8 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&)
12 0x18df1908c WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&)
13 0x18d9dfc28 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
14 0x18e47f72c IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>)
15 0x18e47fac4 IPC::Connection::dispatchIncomingMessages()
16 0x199ad3758 WTF::RunLoop::performWork()
17 0x199ad4eb0 WTF::RunLoop::performWork(void*)
18 0x1804563a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
19 0x1804562ec __CFRunLoopDoSource0
20 0x180455a78 __CFRunLoopDoSources0
21 0x180454c4c __CFRunLoopRun
22 0x18044fcec _CFRunLoopRunSpecificWithOptions
23 0x1926be9bc GSEventRunModal
24 0x18630f0d8 -[UIApplication _run]
25 0x186313300 UIApplicationMain
26 0x18554ac38 block_destroy_helper.15
27 0x10018a70c $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ
28 0x10018a67c $s16WebkitPolicyTrap11AppDelegateC5$mainyyFZ
29 0x10018a818 __debug_main_executable_dylib_entry_point
30 0x1000cd3d0 29 dyld 0x00000001000cd3d0 start_sim + 20
31 0x1002bab98 30 ??? 0x00000001002bab98 0x0 + 4297829272
This doesn’t happen in 18.6. Also, it doesn’t seem to have any negative consequences other than the console spam? But then, the navigation is being cancelled anyway, so maybe it’s trapping and just happens to have the effect of not loading the request?
Anyway, I guess I can’t upload zips. But it’s pretty easy to reproduce. Just assign a WKWebView a navigationDelegate with an implementation like:
func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, decisionHandler: @escaping @MainActor (WKNavigationActionPolicy) -> Void) {
decisionHandler(.cancel)
}
and then have it .load() anything. Have I been doing this wrong and 26 exposes it? Or is this a bug in 26? If the latter, any downstream consequences I should be looking out for?
macOS 15.7.1 (24G231)
Xcode 26.1.1 (17B100)
iOS 26.1 (23B86)
Hey Guys
My PWA video playback and even youtube videos stopped working after updating iOS to 26.0.1.
The video thumnails appear fine and if i try to play the video, it remains stuck.
If i restart the phone, the video plays for a second in the PWA and then stops again and entire app gets stuck.
Request apple team to fix this issue at the earliest. This is hampering all my iOS users who install the PWA on their device homescreen and use it as app.
FYI strangely EVERYTHING WORKS FINE ON iOS SAFARI browser including videos playback If i open it as a web app.
so this seems like a specific PWA issue on latest ios 26.0.1
Topic:
Safari & Web
SubTopic:
General
I'm building a macOS extension that needs to track multi-step navigation chains (A → B → C) to adjust behavior based on where users came from.
Current approach: Using webNavigation.onBeforeNavigate to detect intermediate steps, but experiencing issues in Safari that don't occur on Chrome/Firefox/Edge.
Questions:
Is webNavigation the right API for tracking redirect chains in Safari?
Does ITP/Private Browsing affect event delivery?
Any alternative approaches recommended?
(Safari version 26.0.1)
Any guidance appreciated!
Hi, in our app we have a WKWebView with complex web content that is loaded with cachePolicy: .reloadIgnoringLocalCacheData. If the app is in the background for several hours and returns in the foreground we noticed that the system reloads the webpage, but it does so with a cachePoliy returnCacheDataElseLoad. This could break the app if older cache content is present.
To reproduce start an app in the simulator (tested with iOS 17.2), put it in the background and via activity monitor stop the processes
com.apple.Webkit.WebContent
com.apple.Webkit.networking
After foreground the reload will happen.
Two questions:
why is this reload happening after some hours in the background? We haven't seen any crash reports related to this. It mostly happens on one of our test devices (iphone13 with iOS17.2.1).
why is the webview reloading with a modified cachePolicy (returnCacheDataElseLoad)?
Our temporary fix is to detect this case in "webView:decidePolicyFor navigationAction decisionHandler", cancel the request and reload with modified cachePolicy.
Any ideas?
Thanks,
Heiko
Sample code:
class ViewController: UIViewController, WKNavigationDelegate, WKUIDelegate {
var webView: WKWebView!
override func viewDidLoad() {
super.viewDidLoad()
let config = WKWebViewConfiguration()
webView = WKWebView(frame: .zero, configuration: config)
webView.uiDelegate = self
webView.navigationDelegate = self
view.addSubview(webView)
let myRequest = URLRequest(url: URL(string: "https://www.apple.com")!, cachePolicy: .reloadIgnoringLocalCacheData)
print("request \(myRequest)")
webView.load(myRequest)
}
func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction, decisionHandler: @escaping (WKNavigationActionPolicy) -> Void) {
print("start loading \(String(describing: navigationAction.request.url)), cache:\(navigationAction.request.cachePolicy)")
decisionHandler(.allow)
}
override func viewDidLayoutSubviews() {
super.viewDidLayoutSubviews()
let fullscreen = CGRect.init(x: 0, y: 0, width: view.frame.size.width, height: view.frame.size.height)
webView.frame = fullscreen
}
}
Hello,
After upgrading to macOS 26.2, I’ve noticed a significant performance regression when calling evaluateJavaScript in an iOS App running on Mac (WKWebView, Swift project).
Observed behavior
On macOS 26.2, the callback of evaluateJavaScript takes around 3 seconds to return.
This happens not only for:
evaluateJavaScript("navigator.userAgent")
but also for simple or even empty scripts, for example:
evaluateJavaScript("")
On previous macOS versions, the same calls typically returned in ~200 ms.
Additional testing
I created a new, empty Objective-C project with a WKWebView and tested the same evaluateJavaScript calls.
In the Objective-C project, the callback still returns in ~200 ms, even on macOS 26.2.
Question
Is this a known issue or regression related to:
iOS Apps on Mac,
Swift + WKWebView, or
behavioral changes in evaluateJavaScript on macOS 26.2?
Any information about known issues, internal changes, or recommended workarounds would be greatly appreciated.
Thank you.
Test Code Swift
class ViewController: UIViewController {
private var tmpWebView: WKWebView?
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
setupUserAgent()
}
func setupUserAgent() {
let t1 = CACurrentMediaTime()
tmpWebView = WKWebView(frame: .zero)
tmpWebView?.isInspectable = true
tmpWebView?.evaluateJavaScript("navigator.userAgent") { [weak self] result, error in
let t2 = CACurrentMediaTime()
print("[getUserAgent] \(t2 - t1)s")
self?.tmpWebView = nil
}
}
}
Test Code Objective-C
- (void)scene:(UIScene *)scene willConnectToSession:(UISceneSession *)session options:(UISceneConnectionOptions *)connectionOptions {
NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970];
WKWebView *webView = [[WKWebView alloc] init];
dispatch_async(dispatch_get_main_queue(), ^{
[webView evaluateJavaScript:@"navigator.userAgent" completionHandler:^(id result, NSError *error) {
NSTimeInterval endTime = [[NSDate date] timeIntervalSince1970];
NSLog(@"[getUserAgent]: %.2f s", (endTime - startTime));
}];
});
}
Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content.
The EPUB content format is XHTML and uses namespaces (for the epub:type declaration).
On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace:
0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968
1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940
2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984
3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708
4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636
5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304
6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268
7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488
8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52
9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228
10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268
I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html>
I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not.
It happens on iOS, macOS, and iPadOS.
This has never been a problem in any earlier release of macOS / iOS.
Topic:
Safari & Web
SubTopic:
General
Hello - we have a Mac application that uses a browser extension and the web extension JS APIs to communicate with Safari. As of macOS 15.4 / Safari 18.4 the tab OnAttached and tab onDetached events are no longer received.
After some testing we verified that the events were working properly as of macOS 15.3 / Safari 18.3 but appear to have been broken in macOS 15.4. Note a similar issue was reported previously for Safari 17.6 and was fixed in macOS 15.0 (FB14324177).
We have made a TestFlight version of our app (Tabby) available to simplify debugging via https://testflight.apple.com/join/Va8Zdv9d.
To reproduce the issue:
Install the Tabby TestFlight build on macOS 15.4 or 15.4.1
Open Safari, go to Safari settings and select the Extensions tab
Enable the Tabby extension and grant permissions to all windows all the time
Open a Safari window with at least 3 tabs
Note the open window and tabs displayed in Tabby
In Safari, perform a tab detach by dragging a tab out of the window
Expected behavior
Within Safari the detached tab should now be in it’s own window, and via the onDetached event Tabby should update to show the tab in it’s own window AND removed from the original window.
Observed
Safari fails to send the onDetached event and Tabby will continue to display the detached tab in its original window in addition to the new window.
You can also use the repro steps above to observe the onDetached event being received or not by Tabby in the Safari developer console. The same steps but re-attaching the tab to the original window can be used to observe the onAttached event being received or not.
We’ve attached two screen recordings to the Feedback ID below, one showing the events working on macOS 15.3, and one showing the events failing to be received on macOS 15.4.1. Note it also fails on macOS 15.4.
FEEDBACK ID: FB17367977