321880 - window.open from onmouseover seems to make Javascript become multi-threaded

Status: UNCONFIRMED

(Core :: DOM: Events, defect)

Description

[Peter Flynn (Oracle)]

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.

Comment 1

[Peter Flynn (Oracle)]

Attachment: Testcase

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

Comment 2

[Peter Flynn (Oracle)]

Attachment: 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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Régis Caspar]

*** Bug 340399 has been marked as a duplicate of this bug. ***

Comment 5

[Ulrich Maurer]

Attachment: 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: http://code.google.com/p/google-web-toolkit/issues/detail?id=7926) I was adviced to file the issue to Mozilla.

Comment 6

[Etienne Basso]

I had the same issue with GWT code too.

In attachment something that might help : https://github.com/gwtproject/gwt/issues/7923

Comment 7

[ammorth]

Attachment: testcase stacktrace.html

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.

Comment 8

[Cody Trotter]

Attachment: same problem

Thanks from portynowmu1980.