The default bug view has changed. See this FAQ.

javascript:links may operate on the wrong document

VERIFIED FIXED in mozilla7

Status

()

Core
DOM
P1
normal
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: cristianlibardo, Assigned: bz)

Tracking

Trunk
mozilla7
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.
http://harthur.github.com/mozregression/
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?
(Reporter)

Comment 4

6 years ago
Yes, Firefox3 = Firefox 3.6.13
Keywords: regressionwindow-wanted

Comment 5

6 years ago
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 <bzbarsky@mit.edu>
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
Keywords: regressionwindow-wanted
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
Status: UNCONFIRMED → NEW
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
Created attachment 541593 [details] [diff] [review]
Possible fix
Attachment #541593 - Flags: review?(jst)
Whiteboard: [need review]

Updated

6 years ago
Attachment #541593 - Flags: review?(jst) → review+
Whiteboard: [need review] → [need landing]
http://hg.mozilla.org/integration/mozilla-inbound/rev/cfa057a48b48
Flags: in-testsuite?
Whiteboard: [need landing]
Target Milestone: --- → mozilla7

Comment 10

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

Do we still have a testcase around?
Merged:
http://hg.mozilla.org/mozilla-central/rev/cfa057a48b48
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 12

6 years ago
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.
Status: RESOLVED → VERIFIED

Updated

5 years ago
Depends on: 703831
You need to log in before you can comment on or make changes to this bug.