1478326 - requestAnimationFrame anomaly when calling window.open()

Status: UNCONFIRMED

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

Description

[Alessandro Pignotti]

Attachment: ff.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704194802

Steps to reproduce:

Open the attached HTML test case in Firefox 61.0.1, the test will print the line "This is a bug" on the console if a RAF scheduling anomaly is observed.

This bug has manifested while developing our CheerpJ Java-to-JavaScript compiler ad runtime.

This is the test code, for reference
    var checker = 0;
    function handleRaf()
    {
        // If we get here while checker is 1 it means that the RAF callback has been scheduled while other code is running
        if(checker == 1)
            console.log("This is a bug");
    }
    requestAnimationFrame(handleRaf);
    // The RAF callback can only be scheduled after the current code has finished running
    // otherwise it is a breakage of the concurrency model of JS.
    checker = 1;
    // Waste some time, to force the RAF to be internally scheduled
    var s = Date.now();
    while(Date.now() - s < 1000)
    {
        // This line is just there to waste some time, anything could be here
        var x = new Uint8Array(123);
    }
    // Open a popup (by default it may be blocked)
    window.open("https://google.com");
    // Clear the condition
    checker = 0;


Actual results:

The RAF callback is called while other code is still running, the result is that "This is a bug" is logged to the console.


Expected results:

The RAF callback should only be scheduled after other code has finished running.

I realize that this use case is virtually irrelevant, but since this behaviour is highly unexpected there may be a deep underlying problem that is worth investigating.

Comment 1

[Nika Layzell [:nika] (ni? for response)]

(In reply to Alessandro Pignotti from comment #0)
>     // Open a popup (by default it may be blocked)
>     window.open("https://google.com");

This is the cause of the problem :-) - window.open spins a nested event loop while it blocks waiting for the window to open, and (apparently) RAF can fire during a nested event loop.

bz, should we be silencing RAF events while a window is suspended due to a nested event loop?

Comment 2

[Boris Zbarsky [:bzbarsky]]

We already pause them if SuppressEventHandling() is called.  But are we calling that in this case?

Arguably, we should do that on everything in the docgroup of the caller of window.open(), since those are the things that can synchronously detect the open() happening, right?

Right now there are very few places where we SuppressEventHandling: sync XHR (and only for window.top.document where "window" is the window the XHR ctor came from), nsGlobalWindowOuter::EnterModalState, and some non-web-visible use cases.