Bug 109602 - Web Inspector: page load for about:blank never finishes
Summary: Web Inspector: page load for about:blank never finishes
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Matt Baker
URL: http://canvas.instructure.com/login
Keywords: InRadar
: 169556 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-12 11:58 PST by BJ Homer
Modified: 2019-09-18 02:12 PDT (History)
14 users (show)

See Also:


Attachments
Screenshot (48.24 KB, image/png)
2013-08-07 10:00 PDT, Timothy Hatcher
no flags Details
Patch (1.69 KB, patch)
2014-02-24 00:07 PST, László Langó
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2 (616.72 KB, application/zip)
2014-02-24 01:03 PST, Build Bot
no flags Details
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion (667.77 KB, application/zip)
2014-02-24 01:26 PST, Build Bot
no flags Details
Archive of layout-test-results from webkit-ews-03 for mac-mountainlion (671.48 KB, application/zip)
2014-02-24 02:35 PST, Build Bot
no flags Details
test about blank (186 bytes, text/html)
2015-04-10 01:01 PDT, Jérémy Lal
no flags Details
Patch (5.78 KB, patch)
2017-04-08 12:31 PDT, Matt Baker
joepeck: review-
Details | Formatted Diff | Diff
[Image] w/ patch applied (120.07 KB, image/png)
2017-04-08 12:33 PDT, Matt Baker
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description BJ Homer 2013-02-12 11:58:18 PST
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.
Comment 1 Radar WebKit Bug Importer 2013-02-12 11:58:30 PST
<rdar://problem/13200641>
Comment 2 Alexey Proskuryakov 2013-02-12 18:46:05 PST
Could be another issue with resource identifier assignment.
Comment 3 BJ Homer 2013-03-05 14:20:10 PST
This appears to be fixed in the latest nightly.
Comment 4 Alexey Proskuryakov 2013-03-05 14:58:42 PST
OK, thank you for the update.
Comment 5 Timothy Hatcher 2013-08-07 10:00:06 PDT
I still see about:blank taking up the whole Timeline.
Comment 6 Timothy Hatcher 2013-08-07 10:00:36 PDT
Created attachment 208277 [details]
Screenshot
Comment 7 Brady Eidson 2013-08-07 10:07:54 PDT
(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?
Comment 8 Timothy Hatcher 2013-08-07 11:10:08 PDT
This is likely just a UI issue with the bar graph rendering.
Comment 9 László Langó 2014-02-24 00:07:18 PST
Created attachment 225030 [details]
Patch
Comment 10 Build Bot 2014-02-24 01:03:53 PST
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
Comment 11 Build Bot 2014-02-24 01:03:57 PST
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 12 Build Bot 2014-02-24 01:26:43 PST
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
Comment 13 Build Bot 2014-02-24 01:26:45 PST
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 14 Build Bot 2014-02-24 02:35:52 PST
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
Comment 15 Build Bot 2014-02-24 02:35:54 PST
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 16 Brady Eidson 2014-02-24 07:45:08 PST
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.
Comment 17 László Langó 2014-02-25 00:04:12 PST
(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.
Comment 18 Brady Eidson 2014-02-25 07:28:53 PST
(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?
Comment 19 Timothy Hatcher 2014-02-25 08:58:30 PST
We should just special case about:blank unless there really is a backend bug.
Comment 20 Joseph Pecoraro 2014-09-11 17:25:30 PDT
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.
Comment 21 Jérémy Lal 2015-04-10 01:01:44 PDT
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.
Comment 22 BJ Burg 2017-03-14 10:04:08 PDT
*** Bug 169556 has been marked as a duplicate of this bug. ***
Comment 23 Matt Baker 2017-04-08 12:31:25 PDT
Created attachment 306573 [details]
Patch
Comment 24 Matt Baker 2017-04-08 12:33:19 PDT
Created attachment 306574 [details]
[Image] w/ patch applied
Comment 25 Joseph Pecoraro 2017-04-10 11:32:31 PDT
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 26 Timothy Hatcher 2017-06-02 10:19:30 PDT
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 27 Joseph Pecoraro 2017-06-02 11:33:07 PDT
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 28 Matt Baker 2017-06-02 13:37:38 PDT
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.
Comment 29 Matt Baker 2017-06-02 13:48:05 PDT
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.
Comment 30 Matt Baker 2017-06-02 14:58:44 PDT
(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 31 Joseph Pecoraro 2017-06-30 11:04:15 PDT
Comment on attachment 306573 [details]
Patch

r- for earlier comments. But I think you also wanted to investigate an alternative solution.
Comment 32 Joel Glovacki 2019-09-18 02:12:04 PDT
when is this expected to make its way into a build? this endlessly spinning resource breaks popstate in Safari 13.0.1