User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Steps to Reproduce:
1.Open the URL that demonstrate the problem
2.Click the link a couple of times
3.Observe the page posts back and forth between two documents
4.Click on the links very fast
5.Observe "NOT 2 was 1" eventually displaying
If the problem isn't easily reproduced try copying the pages to a closer location and starts something that consumes CPU on the browser machine.
The problem was observed once using Firefox5 and never using Firefox3 or IE.
Confirmed with Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110419 Firefox/6.0a1 ID:20110419030537.
Would be nice to know when this regressed.
Is this a matter of the link being clickable after the old window has stopped being the current inner window for the outer? Olli, do we still deliver mouse events to the old page at that point, while the new page is being paint-suppressed?
We do deliver mouse events to the old page, but not actually call
event listeners, but postHandleEvent is called. That is a known, old bug
(although the bug was filed recently) and was present even in 3.0, AFAIK.
This one seems to be something recent.
Reporter, when you say Firefox3, do you actually mean Firefox 3.6?
Yes, Firefox3 = Firefox 3.6.13
I've tracked down a regression range using GNU/Linux.
My gut feeling is that it may be easier to make recent versions freak out, but it's hard to find a regression range for that since now and then one has luck and makes even harder-to-reproduce versions screw up within a few clicks.
Last good nightly: 2009-04-13 First bad nightly: 2009-04-14
The first bad revision is:
user: Boris Zbarsky <email@example.com>
date: Mon Apr 13 11:33:27 2009 -0400
summary: Bug 485643. Remove some unnecessary code, r+sr=jst
Olli, I can add back a check for zombie documents here (applying it to all link urls), or we can fix the PostHandleEventThing.... Thoughts? I think it would make sense to verify in OnLinkClickSync that the document is the same as it was in OnLinkClick and is not null, in general.
Though if we're calling PostHandleEvent, then we could be zombie even by the time OnLinkClick is called...
The problem with enforcing the same document in OnLinkClick and OnLinkClickSync, by the way, is that it's not clear to me whether this would break sites. I'll need to do some experimenting on that.
In an ideal world, we'd just stash the inner window to run against in OnLinkClick or something, but there's no really good way to do that at the moment.
Created attachment 541593 [details] [diff] [review]
I get an HTTP 404 when trying to access http://libardo.com/moz/HTMLPage1.aspx.
Do we still have a testcase around?
Verified as fixed on:
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0
+ Aurora (Fx 8.0a2) & Nightly (Fx 9.0a1).
1. Loaded http://libardo.com/moz/HTMLPage1.aspx in a Fx tab.
2. Clicked the link multiple time very fast.
Everything worked fine. No "Not ... was ..." text was displayed.