mac triage: changwan@, can you take a look? you recently touched some of the BeforeUnload code in chrome/browser/ui/browser.cc.

This is an intended change since M52: https://www.chromestatus.com/features/5683408571203584

An excerpt from  issue 639150 :

The root cause is that alert() is an odd duck in the web platform to begin with. The rationale is the portion of the spec about event loops: https://html.spec.whatwg.org/multipage/webappapis.html#event-loop .

When you modify the DOM, although the change to the DOM itself is instantaneous, actually painting it to the screen is posted as a task/microtask on the loop to be run after your JS yields.  This is an essential optimization to avoid multiple paint passes when JS touches a lot of DOM at once, shared among all browsers.

What changed in Chrome M52 is that alert(), which is a immediately run "paused task", now better conforms to the spec text: "While a user agent has a paused task, the corresponding event loop must not run further tasks, and any script in the currently running task must block."  On Firefox, IE and Chrome <=51, there is a special "nested event loop" that runs more tasks inside paused tasks, which we removed.  This conforms with Safari's behavior and other browser vendors may eventually also follow.

BTW, does it happen on bugs.chromium.org? Why do you need to repaint before onbeforeunload?

Yes, it's similar, but I don't think it should be duped with  http://crbug.com/639150 .  I think the problem has some substantive differences than the general alert() case.

> Why do you need to repaint before onbeforeunload?

I think it might be because at a browser level, the graphics have been evicted to save memory.

On 2012 Retina Macbook Pro with 54.0.2840.27, I mostly haven't been able to reproduce, except one time when I saw black instead of white (perhaps a second bug?).  elawrence@, can you repro 100%, if so on what PC?

> Why do you need to repaint before onbeforeunload?

Because in a recent CL, the code for OnBeforeUnload's prompt was changed to remove the server's message about what data would be lost if the tab was closed. The saving grace was that the user could probably just look at the page and see their form data and say "Oh, I care about that" or "Oh, no, I don't care about that." By omitting painting of the tab, the user no longer has any clue about how to answer the question we're asking them in the prompt.

More generally, it seems like a bad UX that we could ever switch to a tab and have it fail to paint, regardless of what dialog boxes may be modal.

> elawrence@, can you repro 100%, if so on what PC?

No, I haven't repro'd at 100%; I have repro'd on a 2015 Retina Macbook Pro and on HP Z440 running Windows 7.

Yeah, I agree it's a bug.  I suspect it's a race condition in painting/visibility that we can probably correct while maintaining the blocking semantic model that changwan@ intentionally introduced.

> No, I haven't repro'd at 100%

OK, what percent roughly of the time do you see this?  Are there any tricks to reproduce it more often like opening a hundred tabs or something?

I have 15 tabs freshly opened in Chrome right now (I just restarted). 

I edited this comment so that CrBug.com will prompt me before closing without saving. I then CTRL+tabbed through my other tabs (CNN, a PDF file, a few cs.chromium.org tabs, a Chrome Web Store tab) and then clicked the "X" for this backgrounded CrBug tab. 

I can repro this bug using these steps at ~100%.

Thanks.  I can repro 100% with these steps as well on Chrome for Linux/54.0.2840.27.

This bug has already been happening for at least 2 stable releases (given the likely assumption that changwan@'s change is indeed responsible) and the raciness also lowers the impact in practice, so let's target the fix for 56.  (We don't have the cycles in 55 timeframe, but we'll get to it when we have some breathing room.)

yabinh@, do you have a cycle for this?

Assigned back to changwan@ because I don't have a cycle.