These should probably block MacViews/Harmony being on by default on Mac. Which I've been calling "Phase 3" --  Issue 603386 

I think avi wired these up already for us \o/. At least under OldSpice, which is rolling out by default soon AFAIK.. See  Issue 629964  and r476000

Exceptions may be the form resubmisson or confirm close dialogs, which couldn't come under old spice since they are modal in a weird way.

Replies:

- OldSpice is on by default across all channels.
- For the alert/confirm/prompt dialogs, under MacViews those already use the Views dialogs. In fact, during OldSpice development on the Mac, I built the Views version first using MacViews, and then built the Cocoa versions.
- For the beforeunload dialog, yes, you may need to rewire the app_modal ones a bit.
- Form resubmission dialogs are stock tab-modal, and those should work once you switch to them. Their relevance to this bug is questionable; they're not "JavaScript" dialogs per se.

Okay, I confirmed that:

1) alert/confirm/prompt are all Views with --secondary-ui-md, so that wiring is done;
2) onbeforeunload is not currently Views, so some wiring is still to be done there

so I'll do the wiring for (2).

https://chromium-review.googlesource.com/533353

After a discussion with avi@, I think the best approach might be to not wire this dialog for MacViews. Here's why:

The beforeunload dialog is synchronous with respect to javascript executing in the renderer, which means it must block the renderer while it is displayed. Also, we can't auto-dismiss it like the existing auto-dismissing dialogs, because it might be protecting actual unsaved user state. The Cocoa version is kind of app-modal, in that you can't click outside of it, but you *can* use the system menu bars. avi@ thinks this is because the undocumented behavior of NSAlert that we're using to get an asynchronous alert doesn't do exactly what we thought it did. The Views version ends up being "less app-modal", in that you can click elsewhere in / interact with other browser windows with it displayed.

The root problem here is that, apart from using a synchronous NSAlert, we don't have a good way to create a system-modal or app-modal window on Mac, and creating a window-modal window means that if tabs in another window are hung (because they share a renderer with another tab which has a beforeunload dialog up) there's no way for the user to tell that that's why the tab is hung. This can happen:

1) In Window A, user navigates tab A1 to a site
2) Tab A1 creates a new window B with a new tab B1 in it
3) Tab A1 installs a beforeunload handler
4) The user navigates tab A1 away from the site
5) The beforeunload handler fires, and we create a window-modal dialog in A (and raise A)
6) The user switches away to tab B1 in window B
7) Tab B1 is unresponsive, because its renderer is hanging in the synchronous beforeunload handler inside tab A1 :(

The existing Cocoa approach is imperfect, but the Views approach would end up being even less good, we think.

There are a couple of paths forward:
1) Don't hang renderers during beforeunload - avi@ and I are unsure how feasible this is; it would probably require a bunch of work on the Blink side
2) Implement our own app-modality somehow - avi@ and I think this would be significant engineering work and probably not very faithful to the system modality behaviors
3) Understand how NSAlert does its asynchronous app modality and do that - again, probably significant engineering work

Given that the existing dialog for beforeunload is already visually inconsistent with the other JS-created dialogs, I think the right path is to just leave beforeunload alone.

We may also need path-forward (i.e. 2: "Implement our own app-modality") for Harmony Phase 2 and the consolidated modality behaviours. That's talked about a bit in Issue 679339.

I don't think we're planning to do more on these for the Harmony launch, updating blocker.

MacViews triage: assigning to avi@. Let's target these at M-68 since it sounds like it could be involved.

What's the concern here? Right now AFAIK these are NSAlerts. As per comment 7, that would be fine except for some issues raised in issue 679339, but that issue was delayed to Mstone-X.

#12: will that still work properly in a full Views browser? If so, we can mark this Fixed.

Basic beforeunload functionality seems to work fine with the NSAlert implementation we use today. If there are specific things that you need me to check I will, but if we're OK using NSAlert as we do today rather than the Views app-modal dialogs, I think we're OK here.

Alright, let's Fixed it :)