Issue metadata
Sign in to add a comment
|
Print dialog in a child window block timers in parent window
Reported by
i...@dropbox.com,
Apr 27 2018
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Steps to reproduce the problem:
1. from window A, setInterval() and then window.open() window B
2. in window B do window.print() (or use the UI to open the print dialog) and leave the dialog open
3. in window A observe that no timers fire while the print dialog is open in window B
Duplicating the tab is an alternative way or repro-ing (bug maybe related to render process reuse?). For example try opening the repro.html and then duplicating the tab, timers stop again.
What is the expected behavior?
Timers continue to fire in window A
What went wrong?
Timers stopped triggering, causing hard to track down pandemonium.
Single file repro attached, though it repros even if the print dialog is user triggered in B.
<script>
setInterval(function(){console.log("tick")}, 1000);
w = window.open();
w.print();
</script>
Did this work before? N/A
Chrome version: 65.0.3325.181 Channel: n/a
OS Version: OS X 10.13.4
Flash Version:
https://bugs.chromium.org/p/chromium/issues/detail?id=359627 seems related
,
May 14 2018
,
May 22 2018
Tested this issue on Mac 10.13.3 using chrome reported version-65.0.3325.181 & latest stable-66.0.3359.181 as per repro.html in C#0 with below steps: 1. Launch chrome 2. Open repro.html in one tab (tab 1) (always allow plugin) and press enter 3. Now Print dialog windows gets opened in another tab (Tab 2) and still repro.html in tab 1 process inprogress 4. Now right click on tab1 & select 'Duplicate' 5. Observed another tab (Tab 3) which is also inprogress (process is running) Please find the attached screencast for reference & let us know if we miss anything to reproduce the issue form our end & confirm on the exact issue. Thanks in advance!!
,
Jul 4
,
Jul 19
,
Aug 20
Isn't this by design? i.e., tab modals block JS for other tabs on that origin, because something something web workers something? over to avi@ who I bet knows the real answer :)
,
Aug 20
That's not entirely by design (e.g. we don't pause out-of-process iframes, but pause in-process ones), but it will be rather hard to implement otherwise (e.g. we enter a nested message loop to process internal tasks during alert() and print() dialogs, and if we were to allow javascript from other frames there we could end up with nested runloops within nested runloops, which we don't really want). We also don't pause web workers during these dialogs.
,
Aug 20
Still, perhaps we can do better. Duping to a bug pondering how to do so. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Apr 30 2018