I forgot: you have to select "cancel" on the exit prompt that appears.

Able to reproduce the issue on reported chrome version #70.0.3538.110 and latest chrome #73.0.3629.0 using Mac 10.14 by following steps as per comment#0 and comment#1.When tested the issue on M-65(#65.0.3325.181) found a bit different behavior that after the clicking cancel neither the window closed nor the music stopped.
Note: Prior to M-65 builds, the popup shows the options as "stay" and "leave".

Attached screencast for reference.
@reporter: Could you please review the attached screencast and help us by confirming whether it can be considered as bad behavior or not. So that it would be really helpful in triaging the issue further.
Thanks.!

Deleted: 910727_M65.mp4 1.1 MB

	910727_M65.mp4 1.1 MB View Download

The behavior seen on the screencast looks good to me: since it's displayed on the "beforeunload" event (which can prevent the page from unloading), music should not stop playing and window should not be closed.

Also, this is what happens on latest versions of Safari and Firefox (only difference is that Safari closes other tabs and only keep opens (and running) the Google Music one).

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ha, that's a neat bug! Thanks for filing it.

Over to avi@ - something's odd about how we handle the cmd-q prompt versus beforeunloads...

Oh boy. The confirm quit window is weird.

What's happening here is "magic" in -[ConfirmQuitPanelController runModalLoopForApplication:]. Let me quote the comment:

    // The panel tells users to Hold Cmd+Q. However, we also want to have a
    // double-tap shortcut that allows for a quick quit path. For the users who
    // tap Cmd+Q and then hold it with the window still open, this double-tap
    // logic will run and cause the quit to get committed. If the key
    // combination held down, the system will start sending the Cmd+Q event to
    // the next key application, and so on. This is bad, so instead we hide all
    // the windows (without animation) to look like we've "quit" and then wait
    // for the KeyUp event to commit the quit.

So the user taps Q, and then holds it. This code then hides all the windows to fake a quit, so that it can wait for the release and really quit. Then the user releases the Q.

Then Chrome *really* tries to close all the windows and hits the beforeunload.

Wheeeeeeee.....

I made a change in f19bb479a965dc882d5fd4debf24aaad76878930 to move the confirmation dialog much much earlier in the quit flow. I wonder if the problem about tap-and-hold quitting still is present with the new location of the code.

That behavior was added in https://codereview.chromium.org/6625025 to fix  bug 74976  on 10.6. Lemme poke on my MacBook as I can't really afford to be randomly quitting apps on my work Mac Pro.

This also bites us with a normal hold-to-quit. Even on that branch we explicitly fade out the windows to convince the user to let go of Q before we quit, and we hit the same problem.

 Issue 918971  has been merged into this issue.

cc elly; this is the confirm-to-quit bug we discussed.