Bug 109602 – Web Inspector: page load for about:blank never finishes

• Component: Web Inspector
• Status: NEW

[BJ Homer]

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.

[Radar WebKit Bug Importer]

<rdar://problem/13200641>

[Alexey Proskuryakov]

Could be another issue with resource identifier assignment.

[BJ Homer]

This appears to be fixed in the latest nightly.

[Alexey Proskuryakov]

OK, thank you for the update.

[Timothy Hatcher]

I still see about:blank taking up the whole Timeline.

[Timothy Hatcher]

Created attachment 208277 [details]
Screenshot

[Brady Eidson]

(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?

[Timothy Hatcher]

This is likely just a UI issue with the bar graph rendering.

[László Langó]

Created attachment 225030 [details]
Patch

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Build Bot]

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

[Brady Eidson]

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.

[László Langó]

(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.

[Brady Eidson]

(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?

[Timothy Hatcher]

We should just special case about:blank unless there really is a backend bug.

[Joseph Pecoraro]

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.

[Jérémy Lal]

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.

[Blaze Burg]

*** Bug 169556 has been marked as a duplicate of this bug. ***

[Matt Baker]

Created attachment 306573 [details]
Patch

[Matt Baker]

Created attachment 306574 [details]
[Image] w/ patch applied

[Joseph Pecoraro]

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.

[Timothy Hatcher]

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.

[Joseph Pecoraro]

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.

[Matt Baker]

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.

[Matt Baker]

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.

[Matt Baker]

(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.

[Joseph Pecoraro]

Comment on attachment 306573 [details]
Patch

r- for earlier comments. But I think you also wanted to investigate an alternative solution.

[Joel Glovacki]

when is this expected to make its way into a build? this endlessly spinning resource breaks popstate in Safari 13.0.1