Event listeners are invoked in a nested message loop |
||||
Issue description
Currently event listeners are invoked without checking whether the page is paused or not. Consequently event listeners may be invoked in a nested message loop.
This means that any arbitrary script from cross origin may run during a nested message loop, which is bad.
Here is a proof-of-concept. Type the following lines in JS console:
w = window.open()
d = w.document; input = d.createElement('input'); input.type = 'button'; input.value = 'button'; input.addEventListener('click', function(){ w.alert(123); }); d.body.appendChild(input);
window.print()
and click the button in the opened window. The event listener runs and window.alert() is invoked...
,
Feb 8 2018
If we were to behave as if window.print() was truly modal, we ought to block interaction with the opened window. That doesn't really seem practical though. Another alternative would be to simply queue JS events triggered in a nested message loop and only dispatch them when returning to the top level loop. I wonder what happens if window.print() is called from the click event handler...?
,
Feb 8 2018
Re#2: calling window.print from the event handler silently fails. window.open also fails when called from the event handler. Queueing seems like it would work, but there will be a lot of corner cases. Part of the problem is that another page is synchronously scripting the paused page, and queuing by itself doesn't address that. I think auto-dismissing may be better/simpler here. Of course auto-dismissing won't work if we are running a nested message loop for cooperative scheduling (which I'm assuming the intent of this bug is also targeting). In any case, I'll leave this bug as Available for now, in case anyone wants to own it, feel free to pick it up.
,
Feb 8 2018
window.print() spawns a dialog, which *should* be blocking the page from input. This should be blocked from the UI side, though the underlying issue is no less problematic.
,
Feb 8 2018
Re#4: This isn't interaction with the page directly, this is interaction with another page (in another tab) that can synchronously script the original page.
,
Feb 9 2018
,
Dec 7
I think that this issue got fixed by yukiy@ at least for common cases. The repro case at #0 no longer works. Event listeners now check the callback's realm's pause as well as the incumbent realm's pause. If it's not enough, feel free to file an new issue or reopen this issue. |
||||
►
Sign in to add a comment |
||||
Comment 1 by lfg@chromium.org
, Feb 8 2018Components: Blink>HTML>Dialog
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows