On iOS 15.4, the following code loading a local .log file (works on iOS 15.2.1) stops working. ``` let url = Bundle.main.url(forResource: "ABC", withExtension: "log")! webView.loadFileURL(url, allowingReadAccessTo: url) ``` Some logs: ``` [Process] 0x7fa558809220 - [pageProxyID=6, webPageID=7, PID=81527] WebPageProxy::didFailProvisionalLoadForFrame: frameID=3, domain=WebKitErrorDomain, code=102, isMainFrame=1 ``` Error object in func webView(_ webView: WKWebView, didFailProvisionalNavigation navigation: WKNavigation!, withError error: Error) ``` Error Domain=WebKitErrorDomain Code=102 "Frame load interrupted" UserInfo={_WKRecoveryAttempterErrorKey=<WKReloadFrameErrorRecoveryAttempter: 0x6000000a2120>, NSErrorFailingURLStringKey=LOG_FILE_PATH, NSErrorFailingURLKey=LOG_FILE_PATH, NSLocalizedDescription=Frame load interrupted} ```
<rdar://problem/92442408>
Thanks for filing, can you please submit a sysdiagnose via http://feedbackassistant.apple.com/ and mention this report (Bug 239591)? When filing that report please capture a sysdiagnose immediately after the issue reproduces with the web view in the foreground. Additionally, please note the exact time (ex: 1/1/19 12:51PM) and URL so we can investigate further. Thanks again! macOS Sysdiagnose documentation: https://developer.apple.com/services-account/download?path=/OS_X/OS_X_Logs/sysdiagnose_Logging_Instructions.pdf
(In reply to Smoley from comment #2) > Thanks for filing, can you please submit a sysdiagnose via > http://feedbackassistant.apple.com/ and mention this report (Bug 239591)? > > When filing that report please capture a sysdiagnose immediately after the > issue reproduces with the web view in the foreground. Additionally, please > note the exact time (ex: 1/1/19 12:51PM) and URL so we can investigate > further. Thanks again! > > macOS Sysdiagnose documentation: > https://developer.apple.com/services-account/download?path=/OS_X/OS_X_Logs/ > sysdiagnose_Logging_Instructions.pdf I've filed a feedback with FB10000223 and attached an Xcode project for reproducing and a sysdiag
Thanks Levin I've added the attachments to the original report and will route accordingly.
It looks like this regressed in the iOS-specific changes for Bug 229414.
This use case was previously handled in the Quicklook code path (even though QL isn't actually needed for this).
Created attachment 459187 [details] Patch
Comment on attachment 459187 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=459187&action=review r=me Does something specifically prevent us from adding a regression test that loads a .log file? > Source/WebCore/platform/network/ios/WebCoreURLResponseIOS.mm:72 > + } else > #endif // USE(QUICK_LOOK) > + if (!type) > + CFURLResponseSetMIMEType(response, CFSTR("application/octet-stream")); > } Super-hard to read an else-if that spans an #ifdef. Can the previous block use an early return instead?
Comment on attachment 459187 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=459187&action=review > Source/WebCore/platform/network/ios/WebCoreURLResponseIOS.mm:-53 > - return; @Darin: It's surprising to me that our iOS code path only ever dealt with the amusingly-named 'mjs' file extension, while our macOS code deals with a myriad of things. Before your refactoring, we would fall through to the QuickLook case which seems like it would generally hand off to the equivalent of your new 'preferredMIMETypeForFileExtensionFromUTType' method, and return a valid MIME type. I wonder if we should just always check 'preferredMIMETypeForFileExtensionFromUTType' if we have a valid file URL, rather than depending on the main resource load + QuickLook case handling them.
(In reply to Geoffrey Garen from comment #8) > Comment on attachment 459187 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=459187&action=review > > r=me > > Does something specifically prevent us from adding a regression test that > loads a .log file? > > > Source/WebCore/platform/network/ios/WebCoreURLResponseIOS.mm:72 > > + } else > > #endif // USE(QUICK_LOOK) > > + if (!type) > > + CFURLResponseSetMIMEType(response, CFSTR("application/octet-stream")); > > } > > Super-hard to read an else-if that spans an #ifdef. Can the previous block > use an early return instead? Oh, gosh -- yes. I should have done that instead. I'll fix before landing, though I'm going to wait until Darin has had a look since he may have other ideas for how to address this.
Comment on attachment 459187 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=459187&action=review >> Source/WebCore/platform/network/ios/WebCoreURLResponseIOS.mm:-53 >> - return; > > @Darin: It's surprising to me that our iOS code path only ever dealt with the amusingly-named 'mjs' file extension, while our macOS code deals with a myriad of things. Before your refactoring, we would fall through to the QuickLook case which seems like it would generally hand off to the equivalent of your new 'preferredMIMETypeForFileExtensionFromUTType' method, and return a valid MIME type. > > I wonder if we should just always check 'preferredMIMETypeForFileExtensionFromUTType' if we have a valid file URL, rather than depending on the main resource load + QuickLook case handling them. I did make a mistake in my refactoring. I assumed that shouldUseQuickLookForMIMEType would return false if passed null for a MIME type, and clearly it returns true for that case. Oops! Your change looks fine.
Created attachment 459245 [details] Patch for landing
Committed r294118 (250499@main): <https://commits.webkit.org/250499@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 459245 [details].
Thanks for the quick fix! Do you know in which iOS version will this fix be included?
Brent, please consider my comment: https://github.com/WebKit/WebKit/commit/5883fa195996d3faa26e6a8453505a1169548719#r73616271 Levin, Apple folks generally can’t announce which fixes go into which iOS versions. I understand how useful it would be for you to have that information!
Reopening to add a follow-up fix.
Created attachment 459322 [details] Patch for landing
Committed r294182 (250549@main): <https://commits.webkit.org/250549@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 459322 [details].