New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 617706 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Load never finishes for back after fragment navigation from document.write page without document.close

Project Member Reported by creis@chromium.org, Jun 6 2016

Issue description

Version: 53.0.2760.0
OS: All

What steps will reproduce the problem?
(1) Start Chrome in --isolate-extensions or --site-per-process mode.
(2) Go to https://csreis.github.io/tests/simple.html
(3) In DevTools, run: document.write("<a href='#frag'>link</a>");
(4) Click the link.
(5) Go back.

What is the expected output?

The URL should go back to simple.html and the throbber should stop spinning.

What do you see instead?

The throbber never stops spinning, and the load stop event never happens.

This is causing problems in a test I'm writing for  issue 446959  (in https://codereview.chromium.org/2032903007/).
 

Comment 1 by creis@chromium.org, Jun 6 2016

Labels: -Pri-2 -Proj-IsolateExtensions-BlockingLaunch Pri-1
Summary: Load never finishes for back after fragment navigation from document.write page (was: OOPIF: Load never finishes for back after fragment navigation from document.write page)
Ah, nevermind about step one of the repro steps.  Turns out this affects default Chrome as well.  Verified in Chrome OS 50.0.2661.104, with no OOPIF modes enabled.

Comment 2 by creis@chromium.org, Jun 6 2016

Cc: dcheng@chromium.org clamy@chromium.org japhet@chromium.org
Components: Blink>Loader
Labels: -Pri-1 Pri-2
Summary: Load never finishes for back after fragment navigation from document.write page without document.close (was: Load never finishes for back after fragment navigation from document.write page)
[+japhet,dcheng for Blink Loader]
[+clamy for FTN start/stop loading behavior]

If you don't involve document.write at all, both clicking a fragment link and clicking the Back button will generate DidStartLoading/DidStopLoading IPC messages, sent from RenderFrameImpl::did{Start,Stop}Loading.

If you follow the repro steps and use document.write to create the link to click, then no calls are made to RenderFrameImpl::didStartLoading or RenderFrameImpl::didStopLoading.  Those are WebFrameClient methods, called from FrameLoaderClientImpl.  Looks like FrameLoader::updateForSameDocumentNavigation might suppressing them because loadEventFinished isn't true.

Looks like it works properly if you call document.close() before you click the link and go back.  That's sufficient to unblock  issue 446959 , and we might be able to WontFix this.

Then again, it's frustrating to end up with a spinner with no load occurring, so I wonder if we can find a way to handle the case that document.close() isn't called.  For example, the test in my CL passed in default Chrome, since RenderFrameImpl::NavigateInternal was sending the DidStopLoading IPC if should_load_request was false.  I'm not sure yet why that doesn't help here or in the --site-per-process version of the test.  Adding clamy@ for ideas since she added that line in r376732.

Comment 3 by creis@chromium.org, Jun 23 2016

This came up again in  issue 622764 , in some layout tests.

Sign in to add a comment