When you change the document that you are viewing, e.g. by clicking on a link or by switching panels in the prefs dialog, we tear down the entire world -- all the frames and everything -- before having anything ready to replace it. This results in flicker (for chrome) blank pages (for the content area) and, when the next page stalls during load (e.g. for a big stylesheet or a slow link), it means that the user cannot interact with the old page anymore. In contrast, in IE, when you click on a link, you are able to interact with the old page right until the very millisecond that IE is ready to paint the next document. This means that users can change their minds and click on other links, scroll the page, and whatever, while waiting for the next page to load. It also means that you get no flicker. We should fix this so that we create the new frames before deleting the old ones. This is the "correct" fix to bug 76303 and bug 72230 and bug 75591.

Plat/OS All/All... See also bug 60780.

This is a dup of the above bug.

Ok, here comes the patch.

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

+ mContentViewer->Destroy(); + aNewViewer->SetPreviousViewer(mContentViewer); + mContentViewer = nsnull; Eh? What's the use of having a destroyed content viewer around? (Calling destroy triggers the SetDocument(null,...) calls on all the content in the document and then releases the document from the document viewer.) Won't that mess things up enough that it's not usable (or stable)? Isn't there a way we could avoid calling SetupNewViewer until we have something to do? IIRC (although I'm not sure), we used to do better on this a bit before bug 60780 was filed.

Well, I am able to scroll around and use links with no problem. The content nodes having no document doesn't cause any destabilization. All event handlers in the DOM are unhooked and all scripts are blown away and all JS timeouts are canceled, so no script can execute. The frame tree is quite capable of functioning without the DOM still being alive (and remember the page is only in this state for at most a second... it's very difficult to do anything to the page in that time).

testing on linux...

Here comes version 4 of the patch. I forgot that I had to patch the plugin dir since it implemented nsiContentViewer.

Applied the latest patch to my debug build (pulled right after your landing yesterday), and I crash on startup. (assertions cleaned up for readability): ###!!! ASSERTION: NS_ENSURE_TRUE(mDocument) failed: 'mDocument', file nsDocumentViewer.cpp, line 3605 ###!!! Break: at file nsDocumentViewer.cpp, line 3605 ###!!! ASSERTION: NS_ENSURE_TRUE(docShellElement) failed: 'docShellElement', file nsXULWindow.cpp, line 938 ###!!! Break: at file nsXULWindow.cpp, line 938 ###!!! ASSERTION: NS_ENSURE_TRUE(windowElement) failed: 'windowElement', file nsXULWindow.cpp, line 958 ###!!! Break: at file nsXULWindow.cpp, line 958 ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../../dist/include/nsCOMPtr.h, line 652 ###!!! Break: at file ../../../dist/include/nsCOMPtr.h, line 652

dan, i was missing the DOM patch. That's probably why your build is unhappy. You should have gotten a compile error during building.

Going to run some mac test builds of this tonight

ran these tonight on mac, seeing the same behavior as hyatt, so it's a success. no flashing between pages, the feel is much better even in debug builds. seeing the same crash as hyatt, launch app to about:blank, then immediately quit. no other crashes discovered yet.

Anyone wanna give the patch a spin on Linux?

hyatt: i gave it a go on linux. it was my debug build, so things were still slow, but the visual difference was a distinct improvement. no weird painting problems as far as i could see, although i didn't check for the crash you mentioned. looks good to me :)

I'm seeing bad stuff on mac, will do more testing and report back here. Zach

Here comes the final patch. This has been tested on every platform and found to work. The reported crash has been fixed (see the latest docshell patch).

Ready for r= and sr=.

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

r/sr=rpotts The DocShell/DocViewer changes look fine to me... As long as the world isn't leaking as a result of holding onto the old DocViewer :-)

Is anyone seeing problems when navigating XML documents? For example, I am having troubles viewing: http://www.mozilla.org/projects/mathml/start.xml which renders okay with the m0.9 branch. I am trying to narrow down the problem and I not sure if it might be related to this fix.

Fixed.

Hyatt, what brand of coffee do you employ? You've been totally smoking up the tree lately and I want some of the same stuff. Kudos.

rbs: i have no trouble "navigating" the mathml page, so i'm not sure what you mean. i notice the contents of radicals appear black, but i assume that's not what you're referring to.

Yep, that isn't the problem. The black rectangles is just because of missing fonts in your system. Since you are getting the mathml page without troubles, maybe my problem could then be more related to bug 77634: Many pages not rendering.

The fix does work; however, it does not implement an important part of the idea - to allow the user to interact with the page that's currently displayed. I'm using Linux build 2001050208 and while it does not erase anything until the next page loads, it does not let me interact with the existing one, either. By interacting, I mean being able to scroll and click on other links (in which case it should go there instead of whereever it was going to go).

"user can't yet interact with displayed page (while new one is loading" - Then this bug isn't fixed yet - is it? We haven't "torn down the world", but we HAVE torn down the world's *functionality* ;) suggest to reopen ***

verified fixed. File an RFE bug for the ability to interact with the previous page while the next page has not yet loaded.

never mind. davidr8 just filed two bugs: bug 78680 and bug 78681

Filed bug 78680 for Igor's comment about not being able to interact with the original page while a page is paint-suppressed. Filed bug 78681 for being able to completely cancel loading the new page while a page is paint-suppressed. Currently, pressing Escape displays the part of the partially loaded page that we have, instead of reverting to the original page (like we do when the new page hasn't started loading at all).

Filed bug 78957: Just before displaying the new page, any checkboxes appear unchecked for about 1/2 second.

I think blocker Bug 78741 (Full page plugins completely broken) may be a regression as a result of this check-in. Could anyone familiar with this patch take a look?

I'm seeing bug 60780 lately, which has been marked as a dupe of this, so I'm re-opening this one. If I click on a URL for a host that takes a real long time to reply, and then I click stop, I'm left on the same page where I started. If I go to click on any of the other links on that page, nothing happens. The Throbber doesn't even flinch, and no page comes up. If I hit the Back button on Mozilla, I am left on the same page, but all the links now work. It seems what's happening here is that mozilla gets a response from the server for the new link, but nothing is retrieved yet to draw. So no contents of the new page are drawn, but all of the links on the old page are now non-working.

Sorry for touching the TM, but this was reopened onto the 091 radar and it's not a stopper. Please reset appropriately. (Why doesn't TM automatically reset to --- on reopen anyway?)

I'm seeing this too. If you happen to be going through a web proxy and the proxy is a little slow, then you might get say the first few bytes of the page's source (enough possibly to give you the page's title), and mozilla will change the urlbar to show the new url, however the old page remains and cannot be interacted with without stopping and hitting back.

Changing summary. This broke when jst landed the XPCDOM stuff.

so shouldn't this go to jst?

No, this is mine.

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

Copying major, access from bug 81951.

I am seeing this all the time now. Extremely annoying. Did it get much worse recently or have I just become sensitive to it... ?

During the same time that keys don't work, the context menu for the page will display bogus entries for frames ("open frame in new window", "show only this frame", ... ) despite no frames in sight. IMO, the old page should work 100% until the new one pops up. In NS 4.x you could even select "open a link in new window" even after the new page was loaded. (I do this all the time and mozilla annoys me very much because it doesn't work).

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

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

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

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

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

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

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

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

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

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

I was wondering if this doing the rendering for the next page could be done in the background, much like the way you render 3d images on another page/frame in memory before displaying them to reduce flicker when animating and also to hide redraws, etc. I realise that this may increase Mozilla memory requirements, but once the HTML file for the new page has been fully retrieved, but before the graphics/objects on the page have been retrieved, you could swap to the new page and tear down the old page. I thought maybe this could be done by creating a new tab that doesn't show up in the tabs but of course still gets loaded and then do as above.

In response to Julz ... Flicker isn't the problem here. What is the problem is keystrokes and other events are getting eaten while the page is transitioning to the new one. I had a quick glance at the final patch above. It looks like the focus is on the wrong page, so you don't see anything happen.

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

Nav Triage: Marking nsbeta-. Not a common problem on the vast majority of web pages per hyatt.

This is a very common problem to me - I always run into what bug 81951 described. I've gotten into the habit of pressing Ctrl+N while a page is loading, since more often than not only one press will work.

Sorry to spam, but I just want to make sure that people understand this bug completely. I believe it affects *every* page. While it's loading, none of the keyboard shortcuts work. As soon as I type in a URL for a page, I'm very likely to do a Ctrl-T so I can do something else while the page loads. This gives for an inconsistent user experience. Just my $.02 Again, I apologize if this is not the correct place to mention this information.

I agree with WD. It affects basically every page. Another effect is that context menu doesn't work, so I can't (Back, Forward, Stop, Reload) when the page is loading.

I don't want to recommend anything related to target milestone (1.0 is too close, just reminding the erroneous "open frame in new window" etc items in context menu. See comment #55.

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

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

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

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

22 dupes would make it "a common problem on the vast majority of web pages" in my books.

Is bug 132269 a dupe of this? If so, that makes it 23 dupes =)

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

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

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

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

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

This appears to be WFM with build 2002050705 (win2k) anybody else?

Strange... It also seems working for me on 2002050708, Win2k. Needs further verification.

Could've sworn I still saw this on a recent build on my work PC at the office. Will comment again tomorrow.

This bug seems to be much less apparent for me on win98 build 2002050708. However, I still notice some problems. For example, in the original desrcription of the bug, you should be able "to interact with the old page right until the very millisecond that [mozilla] is ready to paint the next document" Try to click on a link to a site that you know will be slow to load, then try to scroll down on the site that you are currently at. I still can't scroll or truly interact if I do this.

I second that. Clicking on a link "locks" the current page where the link was clicked; it's not possible to scroll on the "zombie" page. 2002050708, Win2k

It's very easy to get on Linux. Hit ctrl+t a few times, load a few bookmarks in each tab, then go between tabs trying to use your keyboard shortcuts (like escape). De nada, even though reaching over with the mouse and clicking stop works (2002050721).

I still hit this all the time in Windows (2002050708) in the "Transferring data from <site>..." stage.

has anyone noticed another thing... if you multiple tabs open, you can't even change tabs with the keyboard (Ctrl + Pg Dn/Up on Windows) if a page is loading... Build: 2002050608 OS: WinXP

I see that on Linux/2002050809, but I think it may be a focus issue (do you have the sidebar open?). If I open a page in a new tab with several others open, I can't swtich between them with ctrl+pgup/down until I click on the page.

Just noticed it last night. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 Mozilla Debian Package 0.9.9-5pre6v1

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

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

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

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

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

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

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

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

If hyatt isn't working on this anymore, we need someone else to take over. Jst? Changing keyword to mozilla1.2, removing target

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

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

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

BTW, very bad summary text. We're likely to get a lot of duplicates as I doubt people think that the current page is a zombie, and it's not just the current page, but you can't really use keyboard shortcuts to do anything.

Suggest: Browser unresponsive while site is loading [keyboard, links, scrollbars]

"while loading a page" or something like that would be necessary for me to find this.

agree, word loading is in almost all the dupes.

Some of the "duplicates" are not duplicates of this bug. _This_ bug is what hixie originally described: "When you change the document that you are viewing, ... we tear down the entire world ... before having anything ready to replace it. ... [and] the user cannot interact with the old page anymore."

Then they shouldn't have been marked as duplicates in the first place. Would you care to review all duplicates, find out which really aren't duplicates, and re-open them? Let's start with bug 154437. Is it a duplicate?

I reopened bug 81951 to deal with the keyboard problems etc. Should this one be closed?

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

John: See comment 108 and comment 110. If bug 81951 *IS* a duplicate of this bug, then the Summary of this bug has to change in order to facilitate Bugzilla searches, and your comment 112 isn't a valid reason against doing so. There was nothing wrong with jonasj's Summary change to: "Unresponsive while loading page: Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond]".

Look. There's two issues. One is that the current page is torn down when you _initiate_ the loading of another page, and that prevent interaction with the "zombie" page. That is this bug. The other issue is that layout can hog the event queue _while_ a page is loading, and that prevents interaction with the UI. That is not this bug. A number of the bugs weave the two together so that they are "sort-of" the first bug, and "sort-of" the second bug. But they need to treated separately. But, please, don't turn this into a make-work project. Don't try and debate the subtle nuances of this bug or that bug.

I'm not trying to make work - I'm trying to get the bugs accurately entered here and make Bugzilla easily accessible and usable. If a bug is a duplicate of this, it should be so marked. If it isn't, it shouldn't. Since you yourself marked bug 81951 a duplicate of this one, you must think that it's *this* bug too. The only thing that's being argued for here is to add some more descriptive text to the existing Summary so that we don't keep getting more bugs added and marked as duplicates. A simple change to the Summary text is far less work than constantly duping new bugs because the reporters can't find this one based on their search key words... However, in order to avoid noise, I won't say any more on the subject. Others can if they wish.

Thanks for taking the time to manage bugs in bugzilla. However, adding "while loading page" to the summary would amplify, not refine, the description. This bug (as originally reported) is about when happens when you unload the current document. It's a perhaps subtle, but relevant, distinction.

Right. There is some serious confusion here, so I want to confuse you some more :) The reason we are duping "UI doesn't response on pageload" to this bug, is because in comment #52, David Hyatt did it the first time. And in comment #56, he did it once more. And this time, you VERIFIED that bug as duplicate yourself. The summary really needs to change, or a new bug has to be opened (or one of the dupes re-opened), in order to handle this correctly. Any chance of getting a nsbeta1 reconsideration and an ADT impact rating here, John ? This is a very serious UI issue.

reopened bugs 110718, 111677, 111825, 115109, 122596, 145597, 158429, 162652 due to comment 119.

With the exception of bug 158429, which I've left reopened, I've marked all of those as duplicates of bug 110718. Cleaning up remaining as duplicates of bug 110718...

So, who is currently working on this one - which is highly appreciated by the web community?

not able to reproduce with following combo: W2k 2002050708 Mac 10.1.4 2002102508 linux 2002-09-30-04-trunk/ Soeone Plz send me STEPS to reproduce the bug and on what platform you were able to get it. Please make sure you are sending me the steps for the one matching the original description of the bug.

Using today's trunk build, I'm able to reproduce this by clicking on a link to a slowly-loading page and then trying to get mozilla to STOP loading it (esc, stop button etc.) I think the original description is moot. Once you mark other bugs as dupes, at least IMO, you should inherit the descriptions of those bugs too. This is definately in my top 5 most hated bugs. Please don't close it until it's really fixed.

Moving over here, from bug 70484. Steps to reproduce: 1. try loading www.mba.com/bucks 2. Once it says "transferring", you cannot use any key, whether the key belongs to the UI or the currently visible document. 3. Also, if you click on Stop, it will put you in a blank page, instead of leaving you where you are.

* Makes it so keys for UI and content are available during "Transferring" stage of doc loading. * Fixes stop so that it keeps you in the current page if the new page hasn't finished loading. More needs to be done -- I need help finding away to delay SetNewDocument() The unload shouldn't fire until the current page is really disappearing Scripts and event handlers for the current page shouldn't stop working until the doc goes away.

Yay, someone's working on this! Excellent. :-) Please make sure that you get hyatt to review this.

Not only does Hyatt need to review, he needs to help me figure out how to make the script global object into a proxy or something, so that this fix works right. I've spoken with rpotts, jst, dbaron and alecf to name a few. Hyatt is the only person who understands this stuff. The patch isn't ready for prime time yet.

The fix for bug 110718 alleviates this problem a bit so that at least UI keys are available during this time, and make our behavior the same as IE's in this situation. It is not possible to completely fix this without doing some crazy stuff, that no one seems willing to do. We would have to somehow have 2 script global objects during the transition to a new document: 1 for the currently visible doc and 1 for the newly loading paint suppressed doc. No one seems exactly sure how to do that, or is at least afraid of the mess it would create. Let's see how things go after the fix for bug 110718. That might be enough -- I suppose it might have to be.

> We would have to somehow have 2 script global objects during the transition to a > new document: 1 for the currently visible doc and 1 for the newly loading paint > suppressed doc. I think the reason we would need 2 script global objects is, the way we load a document, it has to point to a global window. However, 2 documents cannot point to the same global window for security reasons -- otherwise they could run each other's scripts. Not sure if that's 100% correct -- Hyatt/jst/dbaron can you verify?

aaronl: you can't make new global objects that are exposed as the value of the window property of the global, or as the value of a frame property, or the return value of window.open. Those objects have identity that must not vary across doc loads. I.e., in JS you can stash a window object reference away, load a new doc in that window (or let the user load a new doc), and compare the newly-loaded window object ref to the stashed one and find they're the same. So to fix this, we'll need the script global object to be a proxy that can switch atomicly from the old doc's non-proxy window to the new doc's non-proxy window. We need separate non-proxy windows so the docs don't collide on property names, including what 'document' refers to. I'm not sure how the proxy will decide which non-proxy to forward its gets and sets to, just yet -- naive approach would key off the document (doc-shell?) being unloaded or loaded. /be

Comment on attachment 105946 [details] [diff] [review] Do some of the contentviewer initialization after the paint suppressed page is ready to display This patch is obsolete until someone undertakes the work described by Brendan in comment #132.

Along the same lines: it's very upsetting when I hit CTRL-T and the system doesn't respond by opening a new tab--seems to happen while Mozilla is waiting for a response from a site...Would love for this to be fixed!

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

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

Could we have a more descriptive and general summary for this bug than "Can't interact with zombie pages any more"? I haven't been following the bug closely enough to come up with a good one myself. Could someone who has, do so? Thanks - it will make this bug easier to search for in marking duplicate bugs.

adt: nsbeta1-

I use the Mozilla 1.4 RC1. This problem still exists. It may be related to Flash. With web sites usually with flash animation causes this problem.

The Flash plugin grabbing the keyboard is a separate issue. See: bug 78414, bug 93149, bug 140566, bug 181177

Is this still an issue? aaronl did some work on this at one point....

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

Bz, regarding your last comment see comment 130, comment 131, and comment 132 It's not on my priority list any more unless a user can point out that they're still having a problem. I think we've changed the amount of time that elapses before displaying a new page, and that also helped.

Admittedly, situation has improved a lot but the non-responsiveness is still showing in some cases. I think it depends on the connection throughput since the same transition from one page to another might show this issue or not. e.g. with both Firefox and Mozilla 1.7RC2 I see this: 1. From this page (clearing the cache first doesn't seem to affect) go to http://www.imaging-resource.com . 2. Play with vertical scrollbars while the current page is still displayed. Expected results: scrollbar can be used while the content area is still showing the old page. Actual results: sometimes, scrollbar is not responsive. In those cases, content area displays the previous page but page title shown is from the new page (www.imaging-resource.com). The progress bar is also showing. I see it with both my corporate and home (dial-up) connections. Perhaps it has something to do with the javascript on this page. If you want to reproduce, better use a dial-up connection.

(In reply to comment #141) > Is this still an issue? aaronl did some work on this at one point.... I can still reproduce this easily (using a recent Firefox nightly). Steps: 1.Visit any link-rich page, such as http://news.google.co.uk/ 2.Left-click a link 3.Begin wildly middle-clicking other links on the page (A slow computer and/or connection will probably help) Actual results: Once the new (left-clicked) page's title appears in the current tab and while the previous page (Google News) remains displayed, middle-clicking links doesn't open them, even though the cursor changes to a pointer (hand) when hovering over links. Expected results: Either the pointer shouldn't change when hovering over links; or middle-clicking links should open them.

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

I fixed a number of very similar zombie page keyboard lockup bugs for Firefox 1.5. I have not seen any reports like this recently, and I'm guessing this one is fixed. At the very least no one is looking at this old bug, and if there are still problemns new bugs will certainly be filed.

(In reply to comment #147) I'm still seeing this on the 1.8 branch, using the steps in comment 145 with a slow computer and a fast connection. So, I'm going to reopen this bug and set it to unconfirmed.

We're probably better off using bug 341730 for the new problem rather than reusing this one.

The problem I have is (or seems to be) just the same one as before, not bug 341730. No keyboard shortcuts are involved: hovering over links after the new page starts loading shows the hand cursor, but middle-clicking doesn't load links. If I were to file a new bug to describe it, it would just be an duplicate of this one.

Hm, well, this is still a nuisance in Firefox 2. On many occasions I've clicked a link at Firefox has started to open the new page, and another link has caught my eye. Middle-click all but works -- Firefox actually draws a focus ring around the new link, but the tab is not opened. There's no clear point at which this fails: if you middle-click the second link very quickly, a tab opens for it. If you wait a little too long, it won't (you only get the focus ring around the link) even though the page title in the title bar and tab have not yet changed to the new page. CSS hover effects are also active, but the tab won't open. It's the focus ring and CSS that's confusing, since the window is clearly alive and kicking, it just can't open tabs for no obvious reason.

I'm shocked to see that mozilla folks are considering closing this bug. Do you not ever use the stop button? No unusual behavior ("clicking wildly") is required to reproduce this bug (or at least the bug I reported that was marked as a dupe of this bug). Simply open any page, click a link and then hit escape (or click the stop button). Nothing happens. Some amount of time later the page you were viewing goes white and nothing new is loaded. This is especially bad when dealing with Ajax-y sites where hitting Back and Reload might not (and probably won't) get you the same visible content as was there before Firefox decided to erase it. This bug bothers me every day. I can't believe I'm alone in that. Doesn't it seem severely broken to have one of the five buttons on your application not work in any reasonable way?

(In reply to comment #152) Sam, what spec machine do you have? I only run a PII 333, so I was resigned to the belief that Firefox just doesn't have time at that speed to get around to handling the Stop button until too late. The whole program locks solid as soon as a page starts to come in, and when Stop is finally obeyed, the page draws in white. But I'm wondering if you are suggesting that even modern machines stop responding to Stop? There are two different bugs as I see it. One of them is that when a page starts loading, the UI is fully alive (throbber, cursor change etc) but middle-click is simply discarded. The other is that Firefox's event/threading model is poor (like any browser, really) and the program is very happy to lock solid at any time. For example, a page loading in an inactive tab can stop you using the active tab, as the whole app is frozen. I am guessing that part of it is thread synchronisation for resource access (history, cache, menu items, etc)?

As far as I know tabs are all on the same thread. See bug 40848.

Just to mention that I wrote a small script that can be useful while working on this bug. See bug 403565 comment 13 for instructions. What I could notice at the time is that the previous page can be interacted with until the HTTP headers of the next page are loaded. Once loaded, the previous page can not be interacted with any more.