650806 - javascript:links may operate on the wrong document

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[cristianlibardo]

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

The problem was discovered when using an ASP.NET calendar control. When repetedly clicking on next month the server page crashes due to event validation failures. It seems that the javascript:__doPostBack sometimes operates on the loading document rather than the one displaying the link.

Reproducible: Always

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

Actual Results:  
The javascript link is programmed to expect a certain form value (to minimally mimic the calendar control). When the link is clicked while a document is loading the javascript action is ran the loading document rather than the current document.

Expected Results:  
The javascript should have run with the calling document in scope and the form should have been re-submitted.

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.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

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.
http://harthur.github.com/mozregression/

Comment 2

[Boris Zbarsky [:bzbarsky]]

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?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

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?

Comment 4

[cristianlibardo]

Yes, Firefox3 = Firefox 3.6.13

Comment 5

[Thomas Ahlblom]

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

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68cfe7fb9f31&tochange=398bc50386b7

The first bad revision is:
changeset:   27266:cf28ca744768
user:        Boris Zbarsky <[e-mail]>
date:        Mon Apr 13 11:33:27 2009 -0400
summary:     Bug 485643.  Remove some unnecessary code,  r+sr=jst

http://hg.mozilla.org/mozilla-central/rev/cf28ca744768

Comment 6

[Boris Zbarsky [:bzbarsky]]

Ah, interesting.  So in this case by the time the OnLinkClickSync runs the document is a zombie.  We used to do loads of non-javascript: in that situation; the patch in bug 485643 just made this work the same way for all loads.

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Possible fix

Comment 9

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/cfa057a48b48

Comment 10

[Thomas Ahlblom]

I get an HTTP 404 when trying to access http://libardo.com/moz/HTMLPage1.aspx.

Do we still have a testcase around?

Comment 11

[Mounir Lamouri (:mounir)]

Merged:
http://hg.mozilla.org/mozilla-central/rev/cfa057a48b48

Comment 12

[Ioana (away)]

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

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