76495 - Fetching a new page immediately disables user interaction with the one being viewed [keyboard, links, scrollbars become unresponsive] (zombie)

Status: VERIFIED WORKSFORME

(Core :: Layout, defect)

Description

[Hixie (not reading bugmail)]

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.

Comment 1

[James Green]

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

Comment 2

[Ben Bucksch (:BenB)]

This is a dup of the above bug.

Comment 3

[David Hyatt]

Ok, here comes the patch.

Comment 4

[David Hyatt]

Attachment: (1) Patch to docshell.

Comment 5

[David Hyatt]

Attachment: (1) Patch to content

Comment 6

[David Hyatt]

Attachment: (1) Patch to layout

Comment 7

[David Hyatt]

Attachment: (2) Patch to layout. Ignore the first layout patch. I attached the wrong file.

Comment 8

[David Hyatt]

Attachment: (2) Patch to content. Got bg images working on quasi-alive presshells. :)

Comment 9

[Blake Ross]

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

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 11

[David Hyatt]

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

Comment 12

[David Hyatt]

Attachment: (3) Patch to content

Comment 13

[David Hyatt]

Attachment: (3) Patch to docshell

Comment 14

[David Hyatt]

Attachment: (3) Patch to layout

Comment 15

[Dan Rosen]

testing on linux...

Comment 16

[David Hyatt]

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

Comment 17

[David Hyatt]

Attachment: (4) Patch to docshell.

Comment 18

[David Hyatt]

Attachment: (4) Patch to modules/plugins

Comment 19

[David Hyatt]

Attachment: (4) Patch to content

Comment 20

[David Hyatt]

Attachment: (4) Patch to layout

Comment 21

[Dan Rosen]

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

Comment 22

[David Hyatt]

Attachment: (4) Patch to DOM

Comment 23

[David Hyatt]

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

Comment 24

[Zach Lipton [:zach]]

Going to run some mac test builds of this tonight

Comment 25

[Mike Pinkerton (not reading bugmail)]

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.

Comment 26

[David Hyatt]

Anyone wanna give the patch a spin on Linux?

Comment 27

[Dan Rosen]

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 :)

Comment 28

[Zach Lipton [:zach]]

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

Zach

Comment 29

[David Hyatt]

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

Comment 30

[David Hyatt]

Attachment: *** FINAL PATCH ***

Comment 31

[David Hyatt]

Ready for r= and sr=.

Comment 32

[(not reading, please use [e-mail] instead)]

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

Comment 33

[rpotts (gone)]

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 :-)

Comment 34

[rbs]

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.

Comment 35

[David Hyatt]

Fixed.

Comment 36

[Adam D. Moss]

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.

Comment 37

[Dan Rosen]

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.

Comment 38

[rbs]

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.

Comment 39

[Igor Izyumin]

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

Comment 40

[Peter Lairo]

"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 ***

Comment 41

[John Morrison]

verified fixed. 

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

Comment 42

[John Morrison]

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

Comment 43

[Jesse Ruderman]

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

Comment 44

[Oliver Klee]

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

Comment 45

[Peter Lubczynski]

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?

Comment 46

[WD]

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.

Comment 47

[selmer (gone)]

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

Comment 48

[James Green]

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.

Comment 49

[David Hyatt]

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

Comment 50

[Mike Pinkerton (not reading bugmail)]

so shouldn't this go to jst?

Comment 51

[David Hyatt]

No, this is mine.

Comment 52

[David Hyatt]

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

Comment 53

[Jesse Ruderman]

Copying major, access from bug 81951.

Comment 54

[Marko Macek]

I am seeing this all the time now. Extremely annoying.

Did it get much worse recently or have I just become sensitive to it... ?

Comment 55

[Marko Macek]

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

Comment 56

[David Hyatt]

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

Comment 57

[R.K.Aa.]

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

Comment 58

[John Morrison]

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

Comment 59

[R.K.Aa.]

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

Comment 60

[R.K.Aa.]

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

Comment 61

[R.K.Aa.]

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

Comment 62

[Matthias Versen [:Matti]]

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

Comment 63

[WD]

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

Comment 64

[Matthias Versen [:Matti]]

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

Comment 65

[Doug Turner (:dougt)]

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

Comment 66

[Julz]

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.

Comment 67

[Stephen D Cope]

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.

Comment 68

[R.K.Aa.]

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

Comment 69

[Peter Trudelle]

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

Comment 70

[:deanis74]

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.

Comment 71

[WD]

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.

Comment 72

[Marko Macek]

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.

Comment 73

[Dimitrios]

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.

Comment 74

[Sebastian Biallas]

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

Comment 75

[Vadim Berezniker]

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

Comment 76

[Vadim Berezniker]

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

Comment 77

[Dimitrios]

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

Comment 78

[:deanis74]

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

Comment 79

[Mark Slater]

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

Comment 80

[Mark Slater]

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

Comment 81

[Jesse Ruderman]

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

Comment 82

[Dimitrios]

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

Comment 83

[John Levon]

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

Comment 84

[John Levon]

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

Comment 85

[WD]

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

Comment 86

[Dimitrios]

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

Comment 87

[Mark Slater]

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

Comment 88

[Stephen McCarthy]

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.

Comment 89

[Mark Slater]

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

Comment 90

[dylang]

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

Comment 91

[:deanis74]

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

Comment 92

[Manoj]

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

Comment 93

[Dave]

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.

Comment 94

[Stephen D Cope]

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

Comment 95

[R.K.Aa.]

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

Comment 96

[R.K.Aa.]

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

Comment 97

[WD]

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

Comment 99

[John Levon]

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

Comment 100

[Jesse Ruderman]

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

Comment 101

[Jonas Jørgensen]

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

Comment 102

[R.K.Aa.]

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

Comment 103

[Dimitrios]

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

Comment 104

[Randell Jesup [:jesup] (needinfo me)]

If hyatt isn't working on this anymore, we need someone else to take over.  Jst?

Changing keyword to mozilla1.2, removing target

Comment 105

[Vidar Haarr (not reading bugmail)]

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

Comment 106

[Vidar Haarr (not reading bugmail)]

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

Comment 107

[R.K.Aa.]

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

Comment 108

[Ere Maijala (slow)]

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.

Comment 109

[Jason Bassford]

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

Comment 110

[Ere Maijala (slow)]

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

Comment 111

[José Jeria]

agree, word loading is in almost all the dupes.

Comment 112

[John Morrison]

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

Comment 113

[Jason Bassford]

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?

Comment 114

[Ere Maijala (slow)]

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

Comment 115

[John Morrison]

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

Comment 116

[Jason Bassford]

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]".

Comment 117

[John Morrison]

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.

Comment 118

[Jason Bassford]

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.

Comment 119

[John Morrison]

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.

Comment 120

[Vidar Haarr (not reading bugmail)]

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.

Comment 121

[R.K.Aa.]

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

Comment 122

[Jason Bassford]

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

Comment 123

[Markus Hübner]

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

Comment 124

[praveen tummala]

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.

Comment 125

[Sam Rowe]

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.

Comment 126

[Aaron Leventhal]

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.

Comment 127

[Aaron Leventhal]

Attachment: Do some of the contentviewer initialization after the paint suppressed page is ready to display

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

Comment 128

[Hixie (not reading bugmail)]

Yay, someone's working on this! Excellent. :-)

Please make sure that you get hyatt to review this.

Comment 129

[Aaron Leventhal]

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.

Comment 130

[Aaron Leventhal]

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.

Comment 131

[Aaron Leventhal]

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

Comment 132

[Brendan Eich [:brendan]]

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 133

[Aaron Leventhal]

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.

Comment 134

[Aaron Green, MD]

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!

Comment 135

[Matthias Versen [:Matti]]

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

Comment 136

[Johnny Stenback (:jst)]

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

Comment 137

[Phil Schwartau]

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.

Comment 138

[Samir Gehani]

adt: nsbeta1-

Comment 139

[JongAm Park]

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.

Comment 140

[Stephen D Cope]

The Flash plugin grabbing the keyboard is a separate issue.

See: bug 78414, bug 93149, bug 140566, bug 181177

Comment 141

[Boris Zbarsky [:bzbarsky]]

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

Comment 142

[Jesse Ruderman]

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

Comment 143

[Aaron Leventhal]

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.

Comment 144

[Dimitrios]

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.

Comment 145

[Grey Nicholson (they/them)]

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

Comment 146

[Robin Monks]

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

Comment 147

[Aaron Leventhal]

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. 

Comment 148

[Grey Nicholson (they/them)]

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

Comment 149

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 150

[Grey Nicholson (they/them)]

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.

Comment 151

[Daniel Beardsmore]

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.

Comment 152

[Sam Rowe]

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?

Comment 153

[Daniel Beardsmore]

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

Comment 154

[Justin Kerk]

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

Comment 155

[Sylvain Pasche]

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.

Comment 156

[Clara Guerrero ( Need Info Brindusa Tot Please)]

I tried reproducing this on my end as per steps mentioned in comment 144 and comment 145 and https://www.imaging-resource.com/ and https://news.google.com/topstories?hl=en-GB&gl=GB&ceid=GB:en, and I cannot reproduce on win 10 pro, latest nightly, beta and release builds.
I will close as WFM , but please feel free to reopen if this is still an issue on your end.
Best,
Clara

Comment 157

[Ben Bucksch (:BenB)]

VERIFIED WORKSFORME

I cannot reproduce, either. It might have been fixed in bug 72230.