Last Comment Bug 650806 - javascript:links may operate on the wrong document
: javascript:links may operate on the wrong document
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
P1 normal (vote)
: mozilla7
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Andrew Overholt [:overholt]
Depends on: 703831
Blocks: 485643
  Show dependency treegraph
Reported: 2011-04-18 08:39 PDT by cristianlibardo
Modified: 2011-11-19 05:28 PST (History)
7 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Possible fix (1.80 KB, patch)
2011-06-23 21:08 PDT, Boris Zbarsky [:bz] (still a bit busy)
jst: review+
Details | Diff | Splinter Review

Description User image cristianlibardo 2011-04-18 08:39:07 PDT
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 User image (mostly gone) XtC4UaLL [:xtc4uall] 2011-04-19 14:51:11 PDT
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.
Comment 2 User image Boris Zbarsky [:bz] (still a bit busy) 2011-04-29 20:17:58 PDT
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 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2011-04-30 04:44:16 PDT
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 User image cristianlibardo 2011-05-02 00:06:55 PDT
Yes, Firefox3 = Firefox 3.6.13
Comment 5 User image Thomas Ahlblom 2011-05-23 04:15:02 PDT
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:
changeset:   27266:cf28ca744768
user:        Boris Zbarsky <>
date:        Mon Apr 13 11:33:27 2009 -0400
summary:     Bug 485643.  Remove some unnecessary code,  r+sr=jst
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2011-05-23 11:16:39 PDT
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 User image Boris Zbarsky [:bz] (still a bit busy) 2011-06-17 22:20:43 PDT
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 User image Boris Zbarsky [:bz] (still a bit busy) 2011-06-23 21:08:51 PDT
Created attachment 541593 [details] [diff] [review]
Possible fix
Comment 9 User image Boris Zbarsky [:bz] (still a bit busy) 2011-06-26 10:16:40 PDT
Comment 10 User image Thomas Ahlblom 2011-06-26 10:58:30 PDT
I get an HTTP 404 when trying to access

Do we still have a testcase around?
Comment 11 User image Mounir Lamouri (:mounir) 2011-06-27 02:18:41 PDT
Comment 12 User image Ioana (away) 2011-09-16 03:04:55 PDT
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 in a Fx tab.
2. Clicked the link multiple time very fast.
Everything worked fine. No "Not ... was ..." text was displayed.

Note You need to log in before you can comment on or make changes to this bug.