Closed Bug 650806 Opened 13 years ago Closed 13 years ago

javascript:links may operate on the wrong document


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






(Reporter: cristianlibardo, Assigned: bzbarsky)





(1 file)

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.
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.
Version: unspecified → Trunk
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:
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
OS: Windows 7 → All
Hardware: x86_64 → All
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.
Assignee: nobody → bzbarsky
Blocks: 485643
Ever confirmed: true
Priority: -- → P2
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.
Priority: P2 → P1
Attached patch Possible fixSplinter Review
Attachment #541593 - Flags: review?(jst)
Whiteboard: [need review]
Attachment #541593 - Flags: review?(jst) → review+
Whiteboard: [need review] → [need landing]
Flags: in-testsuite?
Whiteboard: [need landing]
Target Milestone: --- → mozilla7
I get an HTTP 404 when trying to access

Do we still have a testcase around?
Closed: 13 years ago
Resolution: --- → FIXED
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.
Depends on: 703831
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.