Open Bug 76495 (zombie) Opened 21 years ago Updated 6 months ago

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

Categories

(Core :: Layout, defect)

defect
Not set
major

Tracking

()

REOPENED

People

(Reporter: ian, Unassigned)

References

Details

(Keywords: access, arch, Whiteboard: [Hixie-P0] bad user experience [whitebox])

Attachments

(1 file, 15 obsolete files)

2 bytes, text/plain
Details
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.
Whiteboard: [Hixie-P4] bad user experience
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Plat/OS All/All... See also bug 60780.
OS: Windows 2000 → All
Hardware: PC → All
This is a dup of the above bug.
Ok, here comes the patch.
Target Milestone: mozilla1.0 → mozilla0.9.1
Attached patch (1) Patch to docshell. (obsolete) — Splinter Review
Attached patch (1) Patch to content (obsolete) — Splinter Review
Attached patch (1) Patch to layout (obsolete) — Splinter Review
*** 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).
 
Attached patch (3) Patch to content (obsolete) — Splinter Review
Attached patch (3) Patch to docshell (obsolete) — Splinter Review
Attached patch (3) Patch to layout (obsolete) — Splinter Review
testing on linux...
Here comes version 4 of the patch.  I forgot that I had to patch the plugin dir 
since it implemented nsiContentViewer.
Attached patch (4) Patch to docshell. (obsolete) — Splinter Review
Attached patch (4) Patch to modules/plugins (obsolete) — Splinter Review
Attached patch (4) Patch to content (obsolete) — Splinter Review
Attached patch (4) Patch to layout (obsolete) — Splinter Review
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
Attached patch (4) Patch to DOM (obsolete) — Splinter Review
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).

Attached patch *** FINAL PATCH *** (obsolete) — Splinter Review
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → 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.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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?)
Target Milestone: mozilla0.9.1 → ---
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.
Status: REOPENED → ASSIGNED
Summary: We tear down the world before having anything to replace it with → Can't interact with zombie pages any more
so shouldn't this go to jst?
Assignee: hyatt → jst
Status: ASSIGNED → NEW
No, this is mine.
Assignee: jst → hyatt
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
*** Bug 81951 has been marked as a duplicate of this bug. ***
Copying major, access from bug 81951.
Severity: normal → major
Keywords: access
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. ***
Blocks: 104166
Target Milestone: mozilla1.0 → mozilla1.0.1
*** 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. ***
Whiteboard: [Hixie-P4] bad user experience → [Hixie-P0] bad user experience
*** Bug 118797 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Summary: Can't interact with zombie pages any more → Can't interact with zombie pages any more [keyboard, scrollbars don't respond]
*** 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.
Keywords: nsbeta1nsbeta1-
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.
Summary: Can't interact with zombie pages any more [keyboard, scrollbars don't respond] → Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond]
*** 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. ***
Attached file
Attachment #32273 - Attachment is obsolete: true
Attachment #32275 - Attachment is obsolete: true
Attachment #32276 - Attachment is obsolete: true
Attachment #32277 - Attachment is obsolete: true
Attachment #32278 - Attachment is obsolete: true
Attachment #32351 - Attachment is obsolete: true
Attachment #32352 - Attachment is obsolete: true
Attachment #32353 - Attachment is obsolete: true
Attachment #32366 - Attachment is obsolete: true
Attachment #32367 - Attachment is obsolete: true
Attachment #32368 - Attachment is obsolete: true
Attachment #32369 - Attachment is obsolete: true
Attachment #32381 - Attachment is obsolete: true
Attachment #32502 - Attachment is obsolete: true
*** 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
Keywords: mozilla1.0mozilla1.2
Target Milestone: mozilla1.0.1 → ---
*** 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]
Summary: Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond] → Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond / unresponsive]
"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.
Summary: Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond / unresponsive] → Unresponsive while loading page: Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond]
Summary: Unresponsive while loading page: Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond] → Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond]
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...
Alias: zombie
So, who is currently working on this one - which is highly appreciated by the 
web community?
Keywords: nsbeta1-nsbeta1
QA Contact: petersen → praveenqa
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.
Assignee: hyatt → aaronl
Status: ASSIGNED → NEW
* 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
Keywords: patch
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.
Attachment #105946 - Attachment is obsolete: true
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!
Blocks: 114461
Keywords: mozilla1.2mozilla1.3
Whiteboard: [Hixie-P0] bad user experience → [Hixie-P0] bad user experience [whitebox]
*** Bug 185971 has been marked as a duplicate of this bug. ***
Blocks: 177030
*** 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.
Summary: Can't interact with zombie pages any more [keyboard, links, scrollbars don't respond] → Fetching a new page immediately disables user interaction with the one being viewed [keyboard, links, scrollbars become unresponsive]
QA Contact: praveenqa → dsirnapalli
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
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
Assignee: aaronlev5 → other
QA Contact: dsirnapalli → ian
Summary: Fetching a new page immediately disables user interaction with the one being viewed [keyboard, links, scrollbars become unresponsive] → Fetching a new page immediately disables user interaction with the one being viewed [keyboard, links, scrollbars become unresponsive] (zombie)
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. ***
Flags: blocking1.9a1?
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. 
Status: NEW → RESOLVED
Closed: 21 years ago15 years ago
Resolution: --- → WORKSFORME
(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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [Hixie-P0] bad user experience [whitebox] → [Hixie-P0] bad user experience [whitebox] wanted-1.9
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.
Flags: wanted1.9+
Whiteboard: [Hixie-P0] bad user experience [whitebox] wanted-1.9 → [Hixie-P0] bad user experience [whitebox]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
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.
Assignee: layout → nobody
QA Contact: ian → layout
Depends on: 595574
You need to log in before you can comment on or make changes to this bug.