Issue metadata
Sign in to add a comment
|
Regression: DOM manipulation not painted in ONBeforeUnload event
Reported by
kapiltan...@gmail.com,
Aug 5 2016
|
||||||||||||||||||||||
Issue description
Chrome Version : 52.0.2743.116
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari:Fail
Firefox:Ok
IE:OK
What steps will reproduce the problem?
(1)Launch The Chrome Browser With the version 52.0.2743.116 with the HTML page
(2)<!DOCTYPE html>
<html>
<body onbeforeunload="return myFunction()">
<p id="demo">This example demonstrates how to assign an "onbeforeunload" event to a body element.</p>
<p>Close this window, press F5 or click on the link below to invoke the onbeforeunload event.</p>
<a href="http://www.w3schools.com">Click here to go to w3schools.com</a>
<script>
function myFunction() {
document.getElementById("demo").innerHTML = "Hello World";
return "Write something clever here...";
}
</script>
</body>
</html>
(3)Try leaving the browser window by closing it
What is the expected result?
Expected result is that HTML: tag with Id="demo" will change its text to "Hello World"
What happens instead?
The change in the text does not happen
Please provide any additional information below. Attach a screenshot if
possible.
Additionally it was not present in the chrome version 51 , DOM manipulation was possible.
,
Aug 5 2016
Aww, confirmed in devtools with Rendering->Paint Flashing that even though the DOM is updated, the paint does not happen until the user makes the choice (Reload vs Don't Reload). not sure whether it is intentional... => somewhere graphics pipeline Not Loader-related
,
Aug 9 2016
Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for Google Chrome Stable Version - 52.0.2743.116 & Canary Version - 54.0.2823.0 This is a Non-Regression issue existing from M30 - # 30.0.1549.0 [Screen-recording is attached]
,
Aug 10 2016
Facing a similar issue in our website. Can I somehow increase priority of this issue. Confirming that this was working ok in Chrome 51 and has stopped working with Chrome 52
,
Aug 10 2016
Disagreeing to Comment 3 by rnimmagadda@chromium.org This issue can not be replicated in the M30 version of the chrome. Scenario in M30 : The DOM changes in the background before the decision is made by the user (Attached screenshot M30_issue). Scenario in M52 : The DOM does not change in the background before the decision is made by the user(Attached screenshot M52_issue).
,
Aug 12 2016
,
Aug 15 2016
Per the comments on the bug this issue arose somewhere between m51 and m52. Bisect please to narrow it down.
,
Aug 16 2016
==================================== Good Build: 52.0.2739.0 Base Position: 393996 Bad Build: 52.0.2743.0 Base Position: 394939 ===================================== Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 52.0.2743.116 This is a regression issue broken in M52, below mentioned is the bisect info: CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/f0dfab0bef147f55d6460b42878ef71d0578cc59..6ed4d4373c5ce4743850df50f94b867240472033 Suspecting Commit: f07993965cc4250d01226f5260736608957e91d8 Review URL: https://codereview.chromium.org/1990063004 @danakj: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner. Thank you.
,
Aug 16 2016
Thanks for the bisect. It's almost certainly https://chromium.googlesource.com/chromium/src/+/6ed4d4373c5ce4743850df50f94b867240472033 that is a patch messing with message loops on popups. changwan@, does that make sense? I'll see if a revert fixes that, assuming I can revert. But I don't think we want to revert. We might just call this the new normal or figure out another way to fix it, like delaying the popup a frame.
,
Aug 17 2016
This isn't something we expected. aelias@, what do you think about #9? I'll check if we can fix the popup timing.
,
Aug 17 2016
,
Aug 17 2016
FYI, console.log() is fired correctly before popup shows up.
,
Aug 17 2016
We did expect that onBeforeUnload would become synchronous. The bug isn't about a broken popular site nor otherwise impossible use case, so I think we should just call this the new normal. Looks like this matches Safari's behavior anyway.
,
Aug 17 2016
Thanks folks. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Aug 5 2016