Using the new nightly Safari Web Inspector, I noticed that the dashboard timer for the load timer never stopped climbing on this page. When I loaded the page with the inspector open, it appears that everything is loading correctly except "about:blank". I don't know if this is an inspector bug or a webkit bug, but I don't see the same behavior in stable Chrome.
<rdar://problem/13200641>
Could be another issue with resource identifier assignment.
This appears to be fixed in the latest nightly.
OK, thank you for the update.
I still see about:blank taking up the whole Timeline.
Created attachment 208277 [details] Screenshot
(In reply to comment #5) > I still see about:blank taking up the whole Timeline. What would cause it to stop? What callback is the inspector looking for that it's not getting?
This is likely just a UI issue with the bar graph rendering.
Created attachment 225030 [details] Patch
Comment on attachment 225030 [details] Patch Attachment 225030 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/6198401171456000 New failing tests: http/tests/misc/window-dot-stop.html http/tests/cache/iframe-304-crash.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-conflict.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-deny.html http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-deny.html fast/loader/main-document-url-for-non-http-loads.html http/tests/security/XFrameOptions/x-frame-options-allowall.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-allow.html http/tests/security/XFrameOptions/x-frame-options-invalid.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-deny.html webarchive/loading/test-loading-archive-subresource-null-mimetype.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-allow.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-in-body.html http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-allow.html webarchive/loading/test-loading-archive.html webarchive/loading/cache-expired-subresource.html http/tests/misc/will-send-request-returns-null-on-redirect.html http/tests/security/XFrameOptions/x-frame-options-deny.html
Created attachment 225036 [details] Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-13 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Comment on attachment 225030 [details] Patch Attachment 225030 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/5300014272217088 New failing tests: http/tests/misc/window-dot-stop.html http/tests/cache/iframe-304-crash.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag.html http/tests/cache/willsendrequest-returns-null-for-memory-cache-load.html http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-deny.html webarchive/loading/cache-expired-subresource.html fast/loader/main-document-url-for-non-http-loads.html http/tests/security/XFrameOptions/x-frame-options-allowall.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-allow.html http/tests/security/XFrameOptions/x-frame-options-invalid.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-deny.html webarchive/loading/test-loading-archive-subresource-null-mimetype.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-allow.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-in-body.html http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-allow.html webarchive/loading/test-loading-archive.html http/tests/misc/will-send-request-returns-null-on-redirect.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-conflict.html http/tests/loading/redirect-methods.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-deny.html http/tests/security/XFrameOptions/x-frame-options-deny.html
Created attachment 225043 [details] Archive of layout-test-results from webkit-ews-05 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Comment on attachment 225030 [details] Patch Attachment 225030 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/4909275327496192 New failing tests: http/tests/misc/window-dot-stop.html http/tests/cache/iframe-304-crash.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag.html http/tests/cache/willsendrequest-returns-null-for-memory-cache-load.html http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-deny.html webarchive/loading/cache-expired-subresource.html fast/loader/main-document-url-for-non-http-loads.html http/tests/security/XFrameOptions/x-frame-options-allowall.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-allow.html http/tests/security/XFrameOptions/x-frame-options-invalid.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-deny.html webarchive/loading/test-loading-archive-subresource-null-mimetype.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-allow.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-in-body.html http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-allow.html webarchive/loading/test-loading-archive.html http/tests/misc/will-send-request-returns-null-on-redirect.html http/tests/security/XFrameOptions/x-frame-options-multiple-headers-conflict.html http/tests/loading/redirect-methods.html http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-deny.html http/tests/security/XFrameOptions/x-frame-options-deny.html
Created attachment 225047 [details] Archive of layout-test-results from webkit-ews-03 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-03 Port: mac-mountainlion Platform: Mac OS X 10.8.5
Comment on attachment 225030 [details] Patch This seems super wrong. How did you determine that the bug isn't in the web inspector as Tim suspects, and rather that DocumentLoader should be changed? Definitely can't take such a fundamental WebCore change without a new layouttest, either.
(In reply to comment #16) > (From update of attachment 225030 [details]) > How did you determine that the bug isn't in the web inspector as Tim suspects, and rather that DocumentLoader should be changed? It looks to me like the finish event never fires on a blank page.
(In reply to comment #17) > (In reply to comment #16) > > (From update of attachment 225030 [details] [details]) > > How did you determine that the bug isn't in the web inspector as Tim suspects, and rather that DocumentLoader should be changed? > > It looks to me like the finish event never fires on a blank page. If that's the case then why does this only affect the web inspector and not, say, Safari? Have you verified with direct debugging? Can you write a layout test that shows this?
We should just special case about:blank unless there really is a backend bug.
The inspector does better here, but it has issues trying to show the contents of the resource, because it never things the resource completes loading. * STEPS TO REPRODUCE 1. Inspect <http://webkit.org> 2. Load "about:blank" 3. Click "about:blank" main resource in the inspector 4. Go to Source Code => infinite loading indicator We could special case this. I think, like was originally suggested, the resource is never considered "finished" in Web Inspector because we never got a finish timestamp.
Created attachment 250503 [details] test about blank Hello, Using webkitgtk 2.8.0 with epiphany 3.16 and this test.html file shows a hanging about:blank. Upon investigation i found that "change" events stay at WEBKIT_LOAD_STARTED.
*** Bug 169556 has been marked as a duplicate of this bug. ***
Created attachment 306573 [details] Patch
Created attachment 306574 [details] [Image] w/ patch applied
Comment on attachment 306573 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=306573&action=review > Source/WebInspectorUI/ChangeLog:22 > + finishes loading (or fails). The first resource timestamp for "about:blank" > + will always be NaN, so it isn't enough to just check load and start times. Should we fix this in the backend? I guess I'm not understanding why this frontend fix is correct (though it will help with legacy backends). > Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:920 > +localizedStrings["about:blank"] = "about:blank"; I don't think we will want to localize this, it is a literal URL.
Comment on attachment 306573 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=306573&action=review > Source/WebInspectorUI/UserInterface/Views/ResourceContentView.js:125 > + this.element.appendChild(WebInspector.createMessageTextView(WebInspector.UIString("about:blank"), false)); I agree, "about:blank" should not be localized.
Comment on attachment 306573 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=306573&action=review > Source/WebInspectorUI/UserInterface/Base/URLUtilities.js:267 > +WebInspector.isAboutBlank = function(url) This also doesn't seem particularly useful. If I want to search the code for "about:blank" I now have to do a second search for isAboutBlank.
Comment on attachment 306573 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=306573&action=review >> Source/WebInspectorUI/UserInterface/Base/URLUtilities.js:267 >> +WebInspector.isAboutBlank = function(url) > > This also doesn't seem particularly useful. If I want to search the code for "about:blank" I now have to do a second search for isAboutBlank. Will remove.
There is also this comment in FrameResourceManager.prototype.frameDidNavigate (line 80): if (!frame) { // If the frame wasn't known before now, then the main resource was loaded instantly (about:blank, etc.) // Make a new resource (which will make the frame). Mark will mark it as loaded at the end too since we // don't expect any more events about the load finishing for these frames. ... frameWasLoadedInstantly = true; ... } At the end of frameDidNavigate the main resource is marked finished if frameWasLoadedInstantly or the URL equals "about:blank". The above comment implies that the check for frameWasLoadedInstantly should be enough. Will investigate.
(In reply to Matt Baker from comment #29) > There is also this comment in > FrameResourceManager.prototype.frameDidNavigate (line 80): > > if (!frame) { > // If the frame wasn't known before now, then the main resource was > loaded instantly (about:blank, etc.) > // Make a new resource (which will make the frame). Mark will mark it as > loaded at the end too since we > // don't expect any more events about the load finishing for these > frames. > ... > frameWasLoadedInstantly = true; > ... > } > > At the end of frameDidNavigate the main resource is marked finished if > frameWasLoadedInstantly or the URL equals "about:blank". The above comment > implies that the check for frameWasLoadedInstantly should be enough. Will > investigate. Interesting: when navigating from webkit.org to about:blank, the new frame payload has the same ID as the existing main frame. As a result the FrameResourceManager thinks the new frame already exists, and the path that sets frameWasLoadedInstantly is not taken. Checking to see if this is a bug.
Comment on attachment 306573 [details] Patch r- for earlier comments. But I think you also wanted to investigate an alternative solution.
when is this expected to make its way into a build? this endlessly spinning resource breaks popstate in Safari 13.0.1