391684 - AppleScript: Closing browser window w/ multiple tabs (or onbeforeunload-triggered js) prompts user

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: OS Integration, defect)

Description

[Peter Jaros (:peeja)]

Currently, closing a browser window works exactly like choosing "Close Window" from the File menu.  That means the user is prompted to confirm closing multiple tabs.  We have three options:

1. Leave the behavior as it is;
2. Never prompt the user when closing via scripting; or
3. Expose a parameter in the close command to allow the scripter to override the prompt.

Comment 1

[Stuart Morgan]

Once my onbeforeunload fix lands we'll have another similar problem, and one where it's less clear that bypassing the prompt is something we want to do, since it means skipping the onbeforeunload (which may do something more than just prompt) entirely.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

There's "saving no", which makes more sense for windows that are documents, but could be "reasonable" here.

Also, not all users may have that pref enabled, but comment 1 will happen for everyone.

Comment 3

[Peter Jaros (:peeja)]

(In reply to comment #2)
> There's "saving no", which makes more sense for windows that are documents, but
> could be "reasonable" here.

We can (almost certainly) make our own parameter ("without prompting").  I'd have to make sure it wouldn't be a problem on branch, where we're getting the default Standard Suite also.  It shouldn't be, though, since we're using the same FourCC.

As for the onbeforeunload issue, are you saying bypassing the prompt means we have to bypass onbeforeload?  Or are they completely separate issues?  If the latter is the case, maybe we could run the onbeforeunload but auto-dismiss prompts.  I have no idea if that's possible, though.

Comment 4

[Stuart Morgan]

onbeforeunload handlers can have two effects:
1) run arbitrary JS
2) cause a prompt to be shown to cancel leaving the page

We don't currently fire them on closing tabs and windows, but we should, and I have a patch for it. Once that is in, there are more possible dialogs that could block a close than just the multiple tab warning, and (unless we want to re-implement onbeforeunload at the Camino layer, which I certainly don't) I'm not aware of any way to do 1) without getting 2)

We can certainly bypass our own warning prompt without affecting onbeforeunload, but the more general case of the problem--a prompt being triggered by an AppleScript close--will still exist. On the other hand, there's all kinds of stuff that could cause prompts (loading a page that has a JS alert), so maybe fixing the specific case of our warnings is enough, and we can punt on the larger issue of dealing with page-instigated interaction.

Comment 5

[Chris Lawson (gone)]

Aren't there scripting additions that allow a user to click the default button in a sheet after a set time period? If so, wouldn't that basically take care of any JS alerts (assuming a well-written AppleScript) in such cases?

I definitely think we should offer a way to avoid this in *our* case, but I think trying to make all the alerts bypass-able via our own AppleScript implementation is probably asking a bit much.

Comment 6

[Peter Jaros (:peeja)]

(In reply to comment #5)
> Aren't there scripting additions that allow a user to click the default button
> in a sheet after a set time period? If so, wouldn't that basically take care of
> any JS alerts (assuming a well-written AppleScript) in such cases?

No, what you're thinking of are parameters for commands which display dialog boxes.  Those can time out.  There's not way to make any sheet which might appear time out, nor do I think it would be a good idea to have system-wide. :)

Comment 7

[Peter Jaros (:peeja)]

Removing this from the SoC project since we haven't come to an agreement yet, and there are more pressing bugs to take up the rest of the project.

Comment 8

[Chris Lawson (gone)]

(In reply to comment #1)
> Once my onbeforeunload fix lands

For posterity, that's bug 370096.

Can someone whip up a quick testcase that we could play with here? That could give us an idea of how bad it might be to punt on the stuff we can't directly control.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

https://bug284596.bugzilla.mozilla.org/attachment.cgi?id=176135 is an onbeforeunload testcase.

Per discussion, we ought to confirm this, because we feel like we should do something, though it's not clear what.  If we later change our minds, we can WF.