Issue metadata
Sign in to add a comment
|
The second dialog from a page fails to fire while the page is in the background |
||||||||||||||||||||
Issue descriptionWhat steps will reproduce the problem? (1) Go to http://output.jsbin.com/mijefe (2) Click in the page. >> This will open a new tab. (3) Wait. >> After 2 seconds, the original tab will spawn a dialog. The original tab will come to the front, and a dialog will appear. Close the dialog. (4) Click in the jsbin page again. >> This will open a new tab. (5) Wait. >> After 2 seconds, the original jsbin tab *should* spawn a dialog. It doesn't. Bisection yields: You are probably looking for a change made after 435480 (known good), but no later than 435503 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/b407b0e9899c1567d683f2d5f003558195a40cc7..e7592f02242026970af0a6425928e5271a52f79d
,
Dec 6 2016
This is https://codereview.chromium.org/2532183002 . When I reverted locally, my local debug build started behaving correctly. Please address this regression.
,
Dec 6 2016
,
Dec 6 2016
,
Dec 7 2016
Thank you for reporting this. The problem is that window.open takes ~2 seconds of wall time and aggressive background tab throttling throttles tab for a long time. The proposed fix is to stop all throttling for first 10 seconds after backgrounding. It will help to deal with blocking IPCs around page transitions.
,
Dec 8 2016
,
Dec 8 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c1fe2cb61120dcfc2eead782a96649f3e22b28c3 commit c1fe2cb61120dcfc2eead782a96649f3e22b28c3 Author: altimin <altimin@chromium.org> Date: Thu Dec 08 16:38:10 2016 [scheduler] Delay budget-based throttling for 10s after backgrounded. Delay the start of background budget-based timer throttling for 10s after page is backgrounded to deal with long navigation-related blocking IPCs. R=alexclarke@chromium.org,skyostil@chromium.org BUG= 671814 Review-Url: https://codereview.chromium.org/2557713007 Cr-Commit-Position: refs/heads/master@{#437262} [modify] https://crrev.com/c1fe2cb61120dcfc2eead782a96649f3e22b28c3/third_party/WebKit/Source/platform/scheduler/renderer/web_view_scheduler_impl.cc [modify] https://crrev.com/c1fe2cb61120dcfc2eead782a96649f3e22b28c3/third_party/WebKit/Source/platform/scheduler/renderer/web_view_scheduler_impl.h [modify] https://crrev.com/c1fe2cb61120dcfc2eead782a96649f3e22b28c3/third_party/WebKit/Source/platform/scheduler/renderer/web_view_scheduler_impl_unittest.cc
,
Dec 9 2016
,
Dec 9 2016
Your change meets the bar and is auto-approved for M56 (branch: 2924)
,
Dec 12 2016
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 12 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bb76a3b420c908334c3e926804a354045bc845ba commit bb76a3b420c908334c3e926804a354045bc845ba Author: Alexander Timin <altimin@chromium.org> Date: Mon Dec 12 19:22:46 2016 [scheduler] Delay budget-based throttling for 10s after backgrounded. Delay the start of background budget-based timer throttling for 10s after page is backgrounded to deal with long navigation-related blocking IPCs. R=alexclarke@chromium.org,skyostil@chromium.org BUG= 671814 Review-Url: https://codereview.chromium.org/2557713007 Cr-Commit-Position: refs/heads/master@{#437262} (cherry picked from commit c1fe2cb61120dcfc2eead782a96649f3e22b28c3) Review-Url: https://codereview.chromium.org/2567983003 . Cr-Commit-Position: refs/branch-heads/2924@{#464} Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059} [modify] https://crrev.com/bb76a3b420c908334c3e926804a354045bc845ba/third_party/WebKit/Source/platform/scheduler/renderer/web_view_scheduler_impl.cc [modify] https://crrev.com/bb76a3b420c908334c3e926804a354045bc845ba/third_party/WebKit/Source/platform/scheduler/renderer/web_view_scheduler_impl.h [modify] https://crrev.com/bb76a3b420c908334c3e926804a354045bc845ba/third_party/WebKit/Source/platform/scheduler/renderer/web_view_scheduler_impl_unittest.cc
,
Dec 14 2016
Tested the issue on Windows-10.0, Ubuntu 14.04 and Mac OS 10.11.6 using chrome latest Beta M56-56.0.2924.28 by following steps mentioned in the original comment. Observed that the original jsbin tab display a dialog as expected. Hence adding TE-Verified label. Thank You!
,
Jan 20 2017
I'm a little confused. This page should be well below the 1% throttling. Why is it getting throttled? Also, is there a real site that broke here? I'd prefer we be extremely judicious in adding any special cases. Special cases tend not to generalize well and we end up with a complex mess of interventions that developers can't reason about and that browsers are less likely to be consistent on. I've been thinking recently that we should probably throttle more aggressively the longer a tab is backgrounded. So, maybe we can get the same benefit by doing something a bit more general here. To be clear: This is fine as a short-term solution so we can continue to ship throttling in m56. So, I'm not asking for a revert or anything.
,
Jan 20 2017
,
Jan 24 2017
Given comment #5 I guess the throttling here is expected, right? > The problem is that window.open takes ~2 seconds of wall time and aggressive background tab throttling throttles tab for a long time. Maybe the bug is that we are extrapolating a lot from a short burst of CPU activity? |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by a...@chromium.org
, Dec 6 2016