I was thinking about how sUserInputEventDepth (http://searchfox.org/mozilla-central/rev/24c443a440104dabd9447608bd41b8766e8fc2f5/dom/events/EventStateManager.cpp#282) was going to be problematic for Quantum DOM, as with preemption we could allow another page to run code while it was set, despite no user input events being fired for that page. Then I remembered that we already allow that today, with nested event loops. I was able to reproduce allowing a background page to trigger a user input only event without having the user interact with their page, but rather a foreground page which opens an alert() dialog inside of a onclick handler. STR: 1. Open the attached example page in two different windows. Make sure that they are loaded in the same process. 2. In one window, click on the button, an alert will appear. 3. The text "Successfully triggered a copy" will appear 1 or more times in the other window. Expected Result: The other window should not be able to copy to the clipboard while I am not interacting with it. I'm inclined to think we should replace sUserInputEventDepth with something completely different, but I'm not sure how we would implement it right now. It could potentially be something attached to the document the user input event is associated with?

How would you want sUserInputEventDepth to be implemented olli?

The seems similar to TimeoutManager's firing depth to me.

sUserInputEventDepth should possibly be in top level docshell or TabGroup or DocGroup.

Test case doesn't seem to work for me in Nightly, but that may be because bug https://bugzilla.mozilla.org/show_bug.cgi?id=1365032 is resolved, and the duplicate window is opening in a different process.

Nika, can you still reproduce this?

This is still a problem. To reproduce it you just need to press that button to open multiple windows repeatedly until 2 of the windows end up in the same process. If you do it 4 times it should create at least 2 windows in the same process.