Open
Bug 321880
Opened 19 years ago
Updated 2 months ago
window.open from onmouseover seems to make Javascript become multi-threaded
Categories
(Core :: DOM: Events, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: ytpete, Unassigned)
References
Details
(Whiteboard: DUPEME)
Attachments
(4 files, 1 obsolete file)
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 window.open() "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.
Reporter | ||
Comment 1•19 years ago
|
||
This uses mousemove, but mouseover works just the same...
Reporter | ||
Comment 2•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
Yeah, the problem is that the window.open 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•18 years ago
|
||
*** Bug 340399 has been marked as a duplicate of this bug. ***
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Comment 5•11 years ago
|
||
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: http://code.google.com/p/google-web-toolkit/issues/detail?id=7926) I was adviced to file the issue to Mozilla.
Updated•11 years ago
|
Attachment #708570 -
Attachment mime type: text/plain → text/html
Comment 6•9 years ago
|
||
I had the same issue with GWT code too. In attachment something that might help : https://github.com/gwtproject/gwt/issues/7923
Came across this bug today in Firefox 67.0.1. Reduced the bug to this test case and found this old bug which appears to be the same issue.
I noticed that the stack trace for the second window continues from where the first window.open call happened, which suggests some sort of scheduling issue surrounding window.open and browser UI events.
Updated•2 years ago
|
Severity: normal → S3
Comment hidden (spam) |
Updated•2 months ago
|
Attachment #9385377 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•