from onmouseover seems to make Javascript become multi-threaded




13 years ago
3 years ago


(Reporter: ytpete, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)


(Whiteboard: DUPEME)


(3 attachments)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

This is a strange behavior I first noticed in FF 1.0...

Normally, Javascript executing in a Web page is expected to be single-threaded. Rapid-fire DOM events stack up in a queue and are dispatched in order. Since JS offers no synchronization, this is a good thing.

However, it seems that calling "blocks" the thread running the JS event handler and lets another thread process more JS events on the same page. This can introduce all sorts of nasty race conditions for web apps.

Reproducible: Always

Steps to Reproduce:
1. Disable popup blocker
2. Open testcase
3. Mouse over the text

Actual Results:  
Two identical popup windows open.

Expected Results:  
Only one window should open.
The event handler is expected to complete synchronously -- before any other events on the page are processed. By the time it returns, "console" is non-null, and the next mousemove event to be recieved won't get inside the "if" case.

Comment 1

13 years ago
Created attachment 207160 [details]

This uses mousemove, but mouseover works just the same...

Comment 2

13 years ago
Created attachment 207162 [details]
Testcase 2

This testcase proves that the page's Javascript is becoming concurrent: a "lock" variable is added that's only true while inside "openConsole()". A 2nd JS 'thread' enters the function and sees that "lock" is already true -- indicated by the text changing to red in this test.

Also, this seems possibly related to bug 266324, so I've added a comment there to that effect.
Yeah, the problem is that the call has to spin an event loop until the window loads before returning; while it's doing that events to the page are not blocked.  They really should be.  We have existing bugs on this sort of thing.
Whiteboard: DUPEME

Comment 4

12 years ago
*** Bug 340399 has been marked as a duplicate of this bug. ***
Assignee: events → nobody
QA Contact: ian → events

Comment 5

6 years ago
Created attachment 708570 [details]
More verbose testcase

6 years later I ran over this issue with GWT code.
The attachment shows the GWT problem reduced to its essence.

In Issue 7926 (GWT issue tracker: I was adviced to file the issue to Mozilla.


6 years ago
Attachment #708570 - Attachment mime type: text/plain → text/html

Comment 6

3 years ago
I had the same issue with GWT code too.

In attachment something that might help :
You need to log in before you can comment on or make changes to this bug.