Onbeforeunload dialogs are no longer necessary. Web sites can prevent dataloss by saving drafts with AJAX and localStorage. Users can undo closing a tab or window. Let's get rid of this confusing security dialog and unnecessary annoyance vector.

fwiw, Opera doesn't support onbeforeunload, at least by default .

Would HTML5 allow this? http://www.w3.org/TR/html5/history.html#unloading-documents

HTML5 allows imposing additional restrictions as needed for security or a better user experience, no? For example, nothing in the spec explicitly allows popup blockers last I checked. Plus, if the spec needs changing it should just get changed.

As a first step, adding a preference to disable onbeforeunload would help. Then this bug just becomes a question of the default value, which should definitely become "no" as soon as possible without breaking legitimate sites too badly.

I am strongly against removing this. It is a useful feature which should not be removed just because there are more complex ways which can partially replace it.

(In reply to comment #5) > I am strongly against removing this. It is a useful feature which should not be > removed just because there are more complex ways which can partially replace > it. It also invites widespread abuse by sites that don't want their accidental visitors to leave. Sites use it to confuse novice users, who shouldn't have to jump through hoops to leave a site. You say "more complex ways which can partially replace it", but really, you can replace *all* of the legitimate uses of onbeforeunload with either incremental saving on the server or incremental saving on the client. Even with the UI of onbeforeunload drastically improved, it still requires blocking the user from leaving the site unless they provide additional confirmation. That represents a fundamental and unfixable design bug in onbeforeunload, which the alternative solutions don't impose. All that said, I *still* think onbeforeunload deserves a transition period, starting with an off-by-default preference to turn it off, then later an on-by-default-preference that users can turn off if they have problems.

The way the dialog box is currently designed does make it too easy to abuse, but a couple of simple changes could solve that problem. All that really needs to be done is start the box off with "https://bugzilla.mozilla.org/ says:" and change the buttons to "leave page" and "cancel." What is wrong with the dialog blocking the user from leaving the site without confirmation? All of the programs on my computer block me from closing them if I have an unsaved document. This is the standard computer behaviour. Those dialogs could be replaced with incremental saving, but they haven't been replaced in order to make using the programs less error-prone. I made a basic inventory system for my dad's business. When you try to close a page with unsaved changes it pops up a warning. Without onbeforeunload my options are: 1. Remove the warning completely, and just allow the changes to disappear without warning. 2. Automatically update the site as changes are being made. This could allow mistakes to slip through very easily. 3. Automatically save changes as a draft. This would require a lot of changes to the back end, and the addition of a complicated draft feature that is otherwise unnecessary. At a later time the user then has to compare the draft version and the real version and figure out why there is two versions, and which one was actually wanted. Options 2 and 3 both require a lot more work to create and maintain than using a simple onbeforeunload, and they don't take care of all of the problems. What happens if a user has an unreliable connection? They can close the page without any warning that their information has been lost. You could add client side saving for that, but then the update is in limbo until they use that same computer to visit that site again.

Now we have totally different behaviour after fix of bug 588292 - Remove site-supplied text for beforeunload and onunload dialogs, and improve button text

(In reply to comment #0) > Onbeforeunload dialogs are no longer necessary. > Web sites can prevent dataloss > by saving drafts with AJAX and localStorage. There is case where we still need assume user is private browsing and internet connection broke, while he was filling a long Form. > Users can undo closing a tab or window. That may be the only way user may be able to get data if above situation happens.

localStorage is not always sufficient. I know of a few web applications in which, for example, data is no longer relevant if the user comes back 15 minutes later or the user holds a lock on a piece of data and needs to be unlocked for other users as soon as possible.

A lot of old, no longer developed pages (especially on intranet sites) use this to remind a user that something hasn't been saved. With the button text change from bug 588292 it is now very difficult to confuse a user about which button does what so I think that aspect of the problem has been solved. I disagree with the removal of the page-provided message because on a specific page I use, the dialogue used to tell you which of very many form sections had not been saved. It now takes longer to work out which one it is. Obviously the site could be much smarter about it all, but as it has worked for over a decade and whilst it continues to work in IE I can say for certain that money will not be spent upgrading it. This could lead to accidental dataloss. I think that this should become a preference in the "Advanced JavaScript Settings" UI and then it can be easily tested by a wider audience.

(In reply to comment #10) > minutes later or the user holds a lock on a piece of data and needs to be > unlocked for other users as soon as possible. A web application is more like CICS (http://en.wikipedia.org/wiki/CICS ) application than a client server application. By early 1970's we found we dont have to lock some thing when computer is waiting for user to edit some thing online. All we do is retrieve record to be edited with last update time stamp. Then later trying to save just compare time stamp to know whether it was changed by another user. If so ask user how to handle it. This is some thing similar to "Mid Air Collision" we do at bugzilla.

(In reply to comment #12) > (In reply to comment #10) > > minutes later or the user holds a lock on a piece of data and needs to be > > unlocked for other users as soon as possible. > A web application is more like CICS (http://en.wikipedia.org/wiki/CICS ) > application than a client server application. By early 1970's we found we dont > have to lock some thing when computer is waiting for user to edit some thing > online. All we do is retrieve record to be edited with last update time stamp. > Then later trying to save just compare time stamp to know whether it was > changed by another user. If so ask user how to handle it. This is some thing > similar to "Mid Air Collision" we do at bugzilla. There are many ways to handle this but in our particular application using mid-air collisions created a lot more headaches than the lock solution. We used the mid-air collision solution in an old version and we have seen a notable increase in user satisfaction since we implemented locking (in combination with XHR polling). A much better solution would be to implement concurrent editing like in google wave, but this would require too much effort to implement.

I agree more needs to be done to prevent such things (I run noscript, but I see what you mean by looking at the source). The return value of onbeforeunload is one of the more tame ways to trap a user or delay closing a window, it only appears once and it offers a lot of benefits. I would rather see something being done about http 204, http authentication dialogs, synchronous ajax at unload, hanging scripts at unload, popups triggered by mouse clicks, etc, etc. Luckily alert() has already been taken care of in Firefox 4 (bug 59314)

Comment 14 is a link to nobrain.dk, don't go there unless you want a porn shock site that makes itself hard to close. Marking comment private.

In bug 636905 I suggest only allowing onbeforeunload on pages that have been interacted with.

FF shouldn't remove the ability for web applications to prevent users from accidentally closing windows with unsaved data. Our company's bug tracking system (Gemini) doesn't use the onbeforeunload feature, and as a result I lose at least one partially-completed bug report every week or two. Sometimes this happens when I accidentally hit TAB (which moves focus away from a text box) and then hit backspace (which navigates to the previous page). Sometimes this happens when I accidentally click on a link on the page. Sometimes this happens when I want to free up RAM so I close all open browser windows at once, forgetting that I have a draft bug report open. But it's always infuriating because data loss is so easily preventable with a 2-line javascript (OK, 20 lines to include various downlevel browser hacks). Auto-saving of drafts is a good idea, but auto-saving done right is very complex to implement. For example, if bugzilla wanted auto-saving for all draft comments and draft bug reports, it'd need to deal with: - helping users get back to pages they accidentally closed, which probably means a new section of UI dealing with enumerating and managing drafts - versioning all drafts, since forms can change and make draft data incompatible with new forms - allowing users to delete a draft; just because you started a draft doesn't mean you want to keep it forever These are tough UI and development problems for developers to solve, and for end users to learn. Better to leave the current warning behavior but mitigate it: - make the popup tab modal - put limits on what onbeforeunload can do (e.g. only return text, kill after 100 msecs, etc.) - Jesse Ruderman's bug 636905 idea-- treat onbeforeunload like a popup, so don't allow onbeforeunload before the page has been "interacted with" (just like the popup blocker prevents popups fmom pages you haven't interacted with).

I think it's quite sensible to continue mitigation efforts (making it tab-modal, and bug 636905), and then reevaluate if that's sufficient. Additionally, we've talked about giving the browser some way to help users restore lost text inputs, since that's an unfortunately common occurrence. [EG, I almost lost a bunch of work when MediaWiki expired my login session while I was editing, so that when I went to save the page it barfed and gave me a "you can't edit this page" error.] It's a complex problem, but relevant here.

making alert/confirm tab-modal would fix the issue. Removing ability to call confirm from onbeforeunload would break the ability of web application to ask user to save his precious data changes before leaving without less tested, or not developed at all, client side and server side code trying to save partial data, then bugging user if he would like to restore it. In one of my cases user-data is not a text, but a lot of mouse interaction of user with the page. Save problem is solved with one confirm+ajax call from onbeforeunload. I'm strongly against this bug.

Part of my project was to confirm first if they accidentally closed the tab or browser. The ability to say what seems to be the issue why a onbeforeunload was called is extremely useful for usability. Strongly against this bug. Can we revert it back? Do we need to file another request?

We haven't done this ... so there's nothing to revert.

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #22) > We haven't done this ... so there's nothing to revert. But surely you HAVE done this via https://bugzilla.mozilla.org/show_bug.cgi?id=588292 That's why people like me are still on Firefox 3. You have taken us back to the days when most wordprocessors etc would just close without asking if you want to save changes. The user needs to be warned immediately about possible data loss. Asking them tomorrow via some incremental save process would be insanely complex and error-prone.

(In reply to Ian from comment #23) > (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #22) > > We haven't done this ... so there's nothing to revert. > > But surely you HAVE done this via > https://bugzilla.mozilla.org/show_bug.cgi?id=588292 Then the discussion about reverting should be taken to that bug.

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #24) > Then the discussion about reverting should be taken to that bug. Are you in a position to cross-reference the bugs? I didn't even know about 578828 until today. There is discussion at 588292 - the problem is that no one at mozilla is taking any notice.

(In reply to Ian from comment #23) > (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #22) > > We haven't done this ... so there's nothing to revert. > > But surely you HAVE done this via > https://bugzilla.mozilla.org/show_bug.cgi?id=588292 > > That's why people like me are still on Firefox 3. > You have taken us back to the days when most wordprocessors etc would just > close without asking if you want to save changes. > The user needs to be warned immediately about possible data loss. Asking > them tomorrow via some incremental save process would be insanely complex > and error-prone. No, bug 588292 does not remove onbeforeunload dialogs; sites can still prompt the user to stick around and save their data. As for this bug, requesting the removal of onbeforeunload dialogs entirely, that almost certainly won't happen without a *long* transition period to move to better mechanisms, if it even happens at all. So, don't panic. :)

(In reply to Ian from comment #25) > (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #24) > > Then the discussion about reverting should be taken to that bug. > > Are you in a position to cross-reference the bugs? I didn't even know about > 578828 until today. > There is discussion at 588292 - the problem is that no one at mozilla is > taking any notice. Mozilla already fixed bug 588292; nothing remains to take notice of. The remaining complaints in both bug 588292 and bug 641509 have already had several responses, all of which amount to "no". Further messages in Bugzilla won't do anything to change that response.

(In reply to Josh Triplett from comment #26) > No, bug 588292 does not remove onbeforeunload dialogs; sites can still > prompt the user to stick around and save their data. Ok, I see the difference now. But 588292 is almost as bad as complete removal; we still have a dialog - it's just been made unintelligent.

(In reply to Ian from comment #28) > (In reply to Josh Triplett from comment #26) > > No, bug 588292 does not remove onbeforeunload dialogs; sites can still > > prompt the user to stick around and save their data. > > Ok, I see the difference now. But 588292 is almost as bad as complete > removal; we still have a dialog - it's just been made unintelligent. You said that you wanted a warning about possible data loss. The current onbeforeunload dialog provides such a warning. What use case does this not cover for you?

(In reply to Josh Triplett from comment #29) > You said that you wanted a warning about possible data loss. The current > onbeforeunload dialog provides such a warning. What use case does this not > cover for you? I need a detailed warning message for in-house pages which might have hundreds of form fields. The detailed message can show exactly which values have changed, with previous and new values. I can then make an informed choice to save the changes - or indeed to reject them if they're not wanted. (A forced autosave behind the scenes could be almost as bad as no save at all). Many other users have similar requirements for intranet use. I personally don't use this approach on public sites, so a config option would solve the problem for me. So, should I start a new bug report to try to reverse the 'fixing' of what in many opinions was never a bug? We have the impression that perhaps just one person decided to do 588292. They have not refuted the objections. They have given no reason why the behaviour should not at least be made optional.

(In reply to Ian from comment #30) > (In reply to Josh Triplett from comment #29) > > You said that you wanted a warning about possible data loss. The current > > onbeforeunload dialog provides such a warning. What use case does this not > > cover for you? > > I need a detailed warning message for in-house pages which might have > hundreds of form fields. The detailed message can show exactly which values > have changed, with previous and new values. I can then make an informed > choice to save the changes - or indeed to reject them if they're not wanted. > (A forced autosave behind the scenes could be almost as bad as no save at > all). In that case, just use the existing onbeforeunload with the standard message, and in your onbeforeunload handler, highlight the changed fields or add a diff to the page. (For that matter, the highlights/diffs might prove sufficiently useful to show all the time, not just for the "what do I need to do before closing the page" case.) > Many other users have similar requirements for intranet use. > I personally don't use this approach on public sites, so a config option > would solve the problem for me. See below. > So, should I start a new bug report to try to reverse the 'fixing' of what > in many opinions was never a bug? No, bug 641509 already exists; a new bug would just duplicate it. > We have the impression that perhaps just one person decided to do 588292. Nothing can change in Firefox with only one person's approval. A brief look at 588292 should show you that a variety of people at Mozilla worked on it. > They have not refuted the objections. They did, several times. Repeating the same objections does not obligate a repetition of the responses. Among other things, see bug 588292 comment 37. > They have given no reason why the > behaviour should not at least be made optional. That much seems like a good idea. Feel free to open a bug requesting a non-default preference to enable site text in onbeforeunload. (Ideally such a preference would consist of a domain whitelist, rather than a blanket permission, but that seems significantly more difficult to add.) You could then suggest to your users that they enable this preference if they want more detailed information. Organizations who deploy Firefox to their users could also set this preference in their deployments. Such a bug report seems even more likely to succeed with a patch provided. :)

Highlights / diffs would be an added complexity which is not needed in Fx 3 and other browsers. They would have to be there all the time, cluttering up the page. Many of them might not be in the visible part of the page. (As many have said, why make us add complexity to get round a change that was not needed?) Comment 37 just says 'That behaviour was very useful for some, but it could be abused, so that's tough'. Why not make the default behaviour of the browser to refuse to open in the first place, removing all risk completely? (Actually, Fx IS doing this to me today with all site links from Google). Making the behaviour optional has been suggested many times before. Opening a new bug for it should not be necessary. This just reinforces the impression that mozilla's standard position is to ignore all comments and suggestions. And I am not qualified to write a patch.

First of all, all of this remains off-topic for this particular bug report. I don't plan on attempting to argue it any further here. (In reply to Ian from comment #32) > Highlights / diffs would be an added complexity which is not needed in Fx 3 > and other browsers. They would have to be there all the time, cluttering up > the page. Many of them might not be in the visible part of the page. Highlights need not clutter the page. Diffs certainly could, but various means of presenting diffs exist which would not add clutter, such as showing them on hover. In any case you could just show diffs and/or highlights after onbeforeunload. If you don't want to change your site at all, you'll get the default behavior, which works and does not cause the loss of user data. If you want to improve on the default behavior, that will require changes to your site. Simplest possible change: take the text you would have fed to onbeforeunload, stick it on the page. (As > many have said, why make us add complexity to get round a change that was > not needed?) You've pre-supposed "not needed" because the change inconveniences you, and because you disagree with the rationale. That line of argument won't help you at this point: the change has happened, and the rationale has convinced the Mozilla developers and maintainers. You need to actually make a convincing argument that the benefits of your proposal outweigh the drawbacks, rather than continuing to assert that the drawbacks don't exist as has occurred in most of the comments on the other two bugs. > Comment 37 just says 'That behaviour was very useful for some, but it could > be abused, so that's tough'. Why not make the default behaviour of the > browser to refuse to open in the first place, removing all risk completely? That kind of hyperbole doesn't help. To take it in the reverse direction: sites could do very impressive things if allowed to run arbitrary native code, so why not let them do so, despite the risk of malicious sites abusing it? Any change like this weighs the possible uses against the possible abuses. In this case, the legitimate use of onbeforeunload involved making sure user data got saved, and the current implementation does that, while improving the user experience when hitting obnoxious sites that just want to prevent the user from leaving. > (Actually, Fx IS doing this to me today with all site links from Google). Bug number? > Making the behaviour optional has been suggested many times before. Opening > a new bug for it should not be necessary. Making an alternative suggestion in a comment of a bug, as the hundredth comment after a pile of noise, where the description of the bug itself doesn't actually request that approach, seems unlikely to help you. If you'd prefer, you could attempt to retitle bug 641509 and repurpose it for the addition of an option, changing the description of the bug to point at your comment explaining your proposed solution. If you do so, you'll also get to deal with a wave of unhelpful comments complaining at you; enjoy. :) > This just reinforces the > impression that mozilla's standard position is to ignore all comments and > suggestions. So, despite the hundreds of thousands of changes, bugfixes, patches, and suggestions that Mozilla has implemented over the years, you claim that "mozilla's standard position is to ignore all comments and suggestions" because Mozilla sometimes refuses to incorporate a suggestion that it disagrees with? Please, have a little broader perspective than that. :)

(In reply to Josh Triplett from comment #33) I certainly don't want to attack you personally, and I don't mean to attack everything mozilla has done over the years - I hope you will take my comments in a spirit of debate. But that's what there has not been - debate. 588292 was just 'done', based on a rather vague assertion about security. If there was discussion within mozilla, where is it? And I see no evidence that reasoned objections to the change have been thought about. The change has not been defended; the objections have merely been rejected with suggestions for complex work-rounds. When Firefox first appeared I welcomed it and advertised in on my site. Firebug enabled the writing of code which would have been near-impossible without it. For that I will always have tremendous gratitude. But I have to say that recommending Firefox is no longer a no-brainer. You can see other contributors saying they will tell customers not to use it. And it's all so unnecessary. Why couldn't you, or someone, just put in an option to allow site-generated text? I don't imagine that would require much programming effort?

It actually does. It requires programming effort, testing effort, QA effort, user-education effort. It permanently increases the amount of complexity in the preferences and the time it takes to build the browser and run tests. Some of these effects are not that big, but they're there. Worse yet, there are literally thousands of things people have asked for preferences for that we don't have preferences for right now. Adding any one of them is not fatal, but adding all of them certainly would be. So the folks responsible for the preference dialog tend to put a pretty high bar for adding new preferences exposed in it...

(In reply to Boris Zbarsky (:bz) from comment #35) > It actually does. It requires programming effort, testing effort, QA > effort, user-education effort. In my view any work like that should have been done BEFORE the behaviour was changed by 588292. Surely you have an internal switch for the change? It merely needs to be exposed. I don't see any need for new testing or QA. Returning to the topic of this thread. I have now implemented a workround for 588292 by writing my message to the page. It's messy: - It appears at the same time as the Firefox popup, which is untidy and makes the page look as though it does not know what it is doing. - The viewport must be scrolled to ensure the message is visible, which leaves the user having to find their place again if they do not wish to leave. - There must be a means to get rid of the message again if the user stays on the page. Since there is no afterCancelUnload event that I know of, the user will have to click a close button of some kind. - I must test for specific browser versions to prevent my message appearing when not needed. What makes it all rather stupid is that any malicious site could simply do the same as I have done. So what has been achieved? The idea that the dialog might be taken away -completely- is horrific. The initial assertion in this thread that "Onbeforeunload dialogs are no longer necessary" is, to put it mildly, high-handed. You're suggesting that interactive pages should just close without any kind of confirmation. Other responders above have explained why this is a bad idea. But the inescapable impression is that just two or three people at mozilla might decide on their own to do it anyway - as has happened with 588292. Then we're blamed for creating work if we want an option to reverse the change!

> Surely you have an internal switch for the change? Surely not.

You cannot prevent website owners / designers / developers from confusing their visitors. From the moment they arrive at a website, visitors can be presented with absolutely any content, including elements marked up to look like system dialogs or official Firefox pages. There is nothing you can do to prevent phishing, and that seems to be the only thing that the removal of this feature is meant to achieve. You assume that the only reason anyone would ever want to interrupt the unload event is to save data. But this is a blinkered view. What if you want to ask the visitor why they are leaving? What if you want to tell them that they haven't completed their order yet? What if you want to remind them that they haven't renewed their subscription and this is their last chance to do so? And please when answering these questions, if you do, bear in mind that there are thousands of web designers who are quite happy with the system they designed and don't want to have to overhaul their model just to accommodate this "security fix".

Your argument is akin to the argument that a car windshields won't stop a moose, so windshields are a bad idea. This bug addresses a common exploit--a real problem, experienced by many real users--and as such, is very welcome. Navigating away from a page without interacting further is an extremely common behaviour. Users expect to be able to do so under all circumstances, without hindrance. If the solution is to allow one dialogue popup to halt closing a page/navigating away once, that might be acceptable. This would work ok, since dialogue boxes can now be closed with the tab/window. Allowing onbeforeunload to anything else is a VERY bad idea. There's too much potential for abuse. We've already seen this abused, as described above. Perhaps the solution is to restrict the behaviour of onbeforeunload?

A windshield that doesn't even stop WIND probably IS a bad idea. Can you give an example of an exploit that would be prevented by abolishing unload dialogs? In any case, this thread didn't start by claiming to address a security problem. It merely said "Onbeforeunload dialogs are no longer necessary". They may be unnecessary to the OP, but lots of people beg to differ.

This feature is useful in many cases. I'm against dismissing it. You can't always save a draft! Resources cost, and like others said, it can be a confusing matter for users as well. Why should we need to do that when it's simply preventable using one line of code?! And, in case of abuse, there should be a better solution than just removing such a feature!

(In reply to bugzilla from comment #39) Navigating away from a page without interacting further is an > extremely common behaviour. Users expect to be able to do so under all > circumstances, without hindrance. There's another situation you seem to overlook. The use may choose to close a Firefox window, or all Firefox windows, from the taskbar icon. A window they were using an hour ago may be buried invisibly on the desktop. They may have been half-way through completing a form, or noting important information. They may have been interrupted and have forgotten about the window for the moment. Don't forget that some people use browsers to do important work, not just for idle net surfing. You wouldn't dream of suggesting that a Word document, or your code writing software, should silently close in this situation, losing unsaved work. Would you?

I would like to add my voice to the need to allow customizable dialogs for onbeforeunload for two reasons: 1. All other browsers support it so now our primary app looks different in Firefox vs all other browsers (chrome, ie, safari) which confuses our users. 2. We need the dialog to explicitly provide directions on how to log out as we have many small children and non-technical people using the app. The standard Firefox dialog does not mean anything to them and they end up loosing work

(In reply to Ian from comment #30) > I need a detailed warning message for in-house pages which might have > hundreds of form fields. The detailed message can show exactly which values > have changed, with previous and new values. I can then make an informed > choice to save the changes - or indeed to reject them if they're not wanted. > (A forced autosave behind the scenes could be almost as bad as no save at > all). (In reply to Ian from comment #32) > Highlights / diffs would be an added complexity which is not needed in Fx 3 > and other browsers. They would have to be there all the time, cluttering up > the page. Many of them might not be in the visible part of the page. (As > many have said, why make us add complexity to get round a change that was > not needed?) You seem to have a lot to say. Say it in the page. You have plenty of space in the page. A JavaScript dialog box is really not the place for long stories. And putting remarks and problems and demands about the user-written content in a JavaScript dialog has a big usability woe. The user has to carefully read the text, to learn it by heart, the user cannot change anything to his/her writing in the page, sometimes the user cannot even see the related stuff s/he has written in the page (s/he cannot scroll !). Then the user clicks on a button of the dialog. And, only then, the user can do all that stuff s/he could not do before. But the user does not have the feedback text anymore. And cannot have it back. Furthermore, running JavaScript is entirely optional in a Web browser. If you really have something to say to the user, better write it in the page. (In reply to Ian from comment #36) > I have now implemented a workround for 588292 by writing my message to the > page. Better get used to it. In the Web, the page is the media. > It's messy:

(In reply to Nicolas Barbulesco from comment #44) You're free to do it your way. I and others have good reasons for doing it differently on certain pages. The point is our freedom is curtailed by developmental fanatics, when there is no need. Most of us would be happy with a simple config option. Ian Still on Firefox 3 despite all their efforts to trick me into updating.

(In reply to Nicolas Barbulesco from comment #44) I agree that we should not put a lot of information in a non-editable, non-selectable dialog. That's not the point though. The point is that we need a mechanism to interrupt the unload, so that the information can be displayed at all, whatever the format. That mechanism exists. It's the unbeforeunload dialog. I don't want to put all the info in the dialog itself, I just want it to display an "are you sure you want to quit" message. I want users to have the option to say "oh wait, I forgot to do xyz, thanks for reminding me". I then want the ability to respond appropriately when the user clicks "stay on this page" - for example, bring up a selectable / editable page element containing details on just why the "are you sure" message was displayed in the first place. I really feel Ian hit the nail on the head in comment #42: "You wouldn't dream of suggesting that a Word document, or your code writing software, should silently close in this situation, losing unsaved work. Would you?"

(In reply to Ian from comment #45) > (In reply to Nicolas Barbulesco from comment #44) > Still on Firefox 3 despite all their efforts to trick me into updating. Who's the fanatic? Seriously, update or get a free virus every day ;-) ! I don't see a problem at all with auto-saving (locally with localstorage or IndexedDB) what users entered (except privacy-sensitive data, e. g. credit card info) in a certain interval (e. g. every minute) and on certain events (form:onchange, document:visibilitychange) and providing the option to restore (for a limited amount of time, e. g. 3 days) previously entered data (maybe with an option to preview the auto-saved data). Some data (e. g. documents like Google Docs) should be stored on the remote server (synchronize with local e. g. every 1-5 minutes) but in a separate storage with a timeout. If data is synched with the remote and you know the users email address, you can also send a reminder email about unsaved data! That's a great UX and what I expect from a website/webapp. I don't want to be bugged when I want to leave the site, just restore my previous data if I want that (sometimes I don't). BTW: Apple's guidelines for their desktop apps are that the user is never prompted when closing an app (or even restarting the system), it just restores the previous state when reopening/restarting. Not everybody likes it, but I guess most do, especially "normal" users. And it would not bet the first time Apple pioneers a UX concept that gets adopted everywhere …

Does your website's privacy policy say that you store everything the user types the instant they type it? Whether it does or not, that approach is a bad ux in my book.

While auto saving coupled with offline data is great, there are plenty of cases in which it may not be appropriate. Good examples can be found in multi user environments. Suppose you have a server authoritative realtime multiplayer browser game. You can not save any state locally because the client can not be trusted, and the state would be inconsistent with the other players after a few seconds have passed. If the user accidentally closes his browser window, thanks the onbeforeunload dialog, he can prevent accidental logout. In some games an accidental logout might even mean death, a death that might undo days of work. There are also web applications that lock user editable data when the editing begins (instead of resolving concurrent editing at a later time). Navigating away means the lock would be removed by using a timeout, which is probably a worse user experience than a dialog. Of course there are other ways to prevent the window from closing, but those are a lot more unfriendly. (like abusing the 204 response, although I am not sure that still works).

> (like abusing the 204 response, although I am not sure that still works). Can you elaborate? That sounds like it could be a security problem...

(In reply to Jesse Ruderman from comment #50) > > (like abusing the 204 response, although I am not sure that still works). > > Can you elaborate? That sounds like it could be a security problem... I am not sure where I found it years ago, it was used to get around framebusting. Justed tested it in firefox 17 and it still works. This particular method does not block closing the tab or window, but it does prevent you from navigating away in the same tab (like by typing a different address, clicking a bookmark, etc). I just noticed it uses onbeforeunload ;) Here is a proof of concept: https://jorisvanderwel.com/test204.html It also works cross domain in IE but not in chrome and opera.

Nice testcase. I think that's a variant of bug 560767, so I'll add it there.

Why not: Make the onbeforeunload dialog non modal. And, the first close (ctrl-w, etc) shows the dialog, a repeated close then really closes the tab.

Alright, seems like we need a mechanism to tell the browser that the content is in a volatile state (where the browser is incapable of determining a volatile state algorithmically – it currently can detect whether forms were filled out by the user). So the proposal below is a bit more verbose than I intended. Whom should I contact to talk about spec-ing this if this has a chance for implementation and cross-browser support (I believe it's useful esp. for WebApps!)? Quick proposal: ############### ``` boolean window.requestWarnOnQuit([string displayedInfotextOnQuit]); void window.cancelRequestWarnOnQuit(); ``` If the User Agent accepts the request, the function returns `true`, otherwise `false`: 1. `true` should be returned when the request originates from a same-origin script in a user-opened, top-level website, thereby accepting the request for a `warning on close`. 2. `false` should be returned in all other cases thus denying the request, e. g. when the request is called in an (i)Frame or any non-onclick-JS-opened window. 3. No user interaction is required for granting or denying this permission (compared to e. g. navigator.location), however user-defined site-specific restrictions and defaults can apply. If the UA denies the request, the website *could* display a warning stating something like "If you accidently close your tab/window, all the data you entered / your game status will be lost". If the UA accepted the request and the user attempts to close such a window context, the browser opens a dialogue before actually closing the current window (context) and blocks/stalls the current window context (if possible). If the user did not interact with the warning dialogue within a certain time-span (e. g. 10-15 s), the default action is executed. This warning dialogue consists of a generic warning message like "You are trying to close a window which is in a non-restorable state (e. g. user-entered information or a certain game-state)." followed by either "The website did not provide information about what data will be lost." or the text-only string that was passed as an optional argument to the `requestWarnOnQuit()` function. The user is then asked if he really wants to quit resp. navigate away and provided with two options: 1. "Return to site": Closes the modal window, unblocks/unstalls the window context and returns focus back to the originating window. 2. "Leave and quit" (user-overridable default action): The modal is closed and the window context destroyed (closing the tab/window resp. navigating away). A possible extension to this request could be to provide a Worker URL (passed as an optional second string argument) that will receive read-only access (especially the DOM – this may lead to huge implementation issues) to the window context of the just closed window (possibly with write-access to IndexedDB and the like, and of course the XHR and maybe WebSocket APIs) to allow for a way to save the last window state. The Worker should be destroyed by the browser after a timeout of e. g. 5 seconds, not counting any outstanding XHR requests (that ensures that network latency will not be responsible for losing your data). In the warning modal, there could also be a checkbox for "allowing" such a worker, e. g. with the label "Save the last state of the document". Please note that it should not be guaranteed that the Worker is executed or that it actually finishes in time.

(In reply to Florian Bender from comment #54) > Alright, seems like we need a mechanism With respect, we already had what we need in Fx 3. Why add unfamiliar complexity? I and other users are not worrying about losing a game state, or even so much about losing one web site customer, but about vital data. I use the browser to maintain my own business databases. It does happen at the end of a long day that a browser (or indeed an editor) will warn me of unsaved data I may have typed hours ago. Without a detailed beforeunload message it may be impossible for me to know what I changed back then, or whether I want to keep it. I may have been experimenting and definitely would not want to save this, so autosave is not an answer. But if I intended to save important changes, and did not, I need to know this right now; otherwise my databases will be wrong when I do other work tomorrow. So some sort of restoration of the unsaved page, perhaps days later, is not the answer either. I would be quite happy for this Fx3 behaviour to be the non-default case, controlled by a config option. But the fanatics have decreed that they can't be bothered to allow even this. It seems one or two people decided at the start that users just don't need beforeunload messages. They apparently never deal with user-typed data that matter. But the change is ineffective anyway - I can supply flashing red in-page messages instead if I want. They're ugly, inconvenient and confusing to a visitor. But that's what I'll have to do for my in-house purposes if I ever migrate to Firefox 93.

You are missing the reason for disallowing dialogues: They can (and will) be abused and cannot be analyzed heuristically by the browser. I agree that my proposal is a new, maybe complex and unneeded addition to current mechanisms (especially considering that onbeforeunload is not going away). On the other hand, it is a clean, fresh approach that allows the browser to have far better control over what is happening (and to act with good performance) while also giving developers the ability to handle a shutdown well. Maybe we can alter the current onbeforeunload handling to behave similarly to my proposal: So when closing, the current window context is described as "accepting a warn-on-close-request" in my proposal above and there are registered onbeforeunload events, execute them and look for an alert() or prompt() call, display a prompt with a generic text followed by the string supplied to alert() or prompt(), have an automatic timeout (10-15 sec) to this dialogue and act according to the action the user chooses. Executing onbeforeunload should not take longer than 3 sec to call either prompt() or alert() otherwise execution is stopped. Abort, or proceed with a shutdown (according to the chosen action) by tearing down the layout (-> making it "invisible" and free the memory), ignoring any consecutive user-interaction function calls (i. e. alert(), prompt(), …) or "frontend write calls" (i. e. altering the DOM or doc.location but NOT e. g. IndexedDB or XHR) and let the teardown run for max. 10 sec before execution is stopped (apart form ongoing XHRs), then proceed with actually destroying the window context etc. The problem with this proposal (compared to my original proposal) is that it may contradict W3C specs and there is no feedback to the website whether a warning prompt is/will be displayed on closing or not. The plus side: It works with existing solutions (in most legitimate cases) while still catering to the browser vendors' needs. Is that something you can agree on?

Further to this comment of mine: > I use the browser to maintain my own business databases. It does happen at > the end of a long day that a browser (or indeed an editor) will warn me of > unsaved data I may have typed hours ago. > Without a detailed beforeunload message it may be impossible for me to know > what I changed back then ... I've just had a concrete example. On going to shut down Firefox (3), I was warned that I hadn't finished saving a bank reconciliation I started on my accounts page 12 hours ago. But I noticed something else. The default message wording DOES NOT TELL YOU WHICH PAGE IT IS TALKING ABOUT. It only talks about 'this page' or 'the current page'. Only my own code's list of changed fields allowed me to know which of at least a dozen open pages had the problem. This situation arises if you shut down all Firefox pages at once by clicking File | Exit. A dubious behaviour itself, but safe if you use the old beforeunload.

Instead of ranting you could just cooperate and actually write what should be changed. Allowing "normal" prompts in onbeforeunload is no option any longer – deal with it. Instead, please propose enhancements to the current situation. So, if it is possible in any way, when closing Firefox and there are unsent user-filled forms, add a list of currently opened tabs to the current warning (this is not the "Are you sure to close xx tabs?" prompt!). That's actually a great and much-needed UX enhancement. Any comments from a Fx coder/MoCo?

My off-the-cuff thought is that a single "the following tabs have unsaved data" kind of shutdown prompt _could_ work. But I suspect it would be hard to get the UX right, and the overall cost-benefit isn't very appealing. OTOH, it's actually similar to how I've been thinking about refactoring our currently-complicated shutdown code. Briefly; the current code can result in multiple prompts for various conditions, which can result in unexpected states if you click 1 or more prompts, and then cancel another. It would simpler to have a single quit-confirmation prompt which could display multiple warnings.

Can you please contact some UX people on that? I think this should be fixed in time for the next ESR (22, 23?)! Also, check with Snappy if this somehow intertwines with their shutdown efforts. If we can't get a great UX for Fx 22, can we at least have a sufficient one?

I'd like to see this Bug marked as duplicate of Bug 636905 – I think that idea (with timeout) is a better middle ground than this Bug's one. If we really want to remove the prompt altogether in the future, we can revisit this decision again. However, the refactoring part with handling of multiple tabs at once on shutdown should be mentioned (summarized) in the other Bug.

After reading a lot of comments, i feel really shameful. The modal popup before page unload is really a annoying behavior, no matter who says it can prevent users from accidentally closing the tab. I need a config option to decide on myself!

(In reply to Chen Zhixiang from comment #62) > After reading a lot of comments, i feel really shameful. > The modal popup before page unload is really a annoying behavior, no matter > who says it can prevent users from accidentally closing the tab. > I need a config option to decide on myself! There is now a config option, which was implemented in bug 950336. There is no UI for the option. I do not believe such UI should be created. If and when we think the web is ready, we can toggle the default value for the option (and if we do that, maybe UI should be created... but not while it defaults to true, I think). Note that we also no longer show the reasons web pages return as to why no unload should take place. There are bugs on file to (a) reduce the number of dialogs per-page to 1 (bug 636374), and (b) make the dialog tabmodal (bug 616853). These should help significantly with the annoyance factor as long as we don't feel confident about turning this "API" off altogether.

(In reply to Josh Triplett from comment #6) > You say "more complex ways which can partially replace it", but really, you > can replace *all* of the legitimate uses of onbeforeunload with either > incremental saving on the server or incremental saving on the client. > No, we can't. There are several cases not related to saving documents. Please imagine a long-running process (estimated in hours) which uses an usb device and specialized plugin/applet. User should be precisely notified (or even blocked, as onbeforeunload currently does) while he's accidentally leaving module/application. We're talking about applications, not about simple web pages about cats or dogs. This is a BUSINESS requirement, not personal. Readability/UX was destroyed in #588292 - please do not go too far by removing onbeforeunload. Thanks a lot!

(In reply to marcin.j.nowak from comment #64) > No, we can't. There are several cases not related to saving documents. > Please imagine a long-running process (estimated in hours) which uses an usb > device and specialized plugin/applet. This sounds like a poorly designed system with bad UX. "Non-interruptable" things are prone to all sorts of uncontrollable failures -- the user might unplug the USB device, suspend their laptop by closing the lid, run out of battery, the OS or Browser could crash, the network could fail, etc etc. And mobile adds an interesting twist, where it's SOP for the OS to kill an app when it thinks the cpu/memory/battery could better be used elsewhere. Prompts do not, and can not, help with such situations. In any case, I think this bug may be mostly WONTFIX at this point. We've already made it tab-modal, and there are a number of other possible ideas (some noted above) for reducing it's irritation and temptation for use. I think we're more likely to continue to incrementally ratchet down ways this prompt can be used as a user-annoyance, and not outright remove it. (At least for the forseeable future.) OTOH (and why I'm not actually closing it)... As noted previously, Opera didn't support onbeforeunload until recently (due to switching to Blink). Mobile Safari also doesn't support it. Mobile Chrome and Firefox both support it for navigation, but ignore it for closing a tab. So there are some reasons to remove/adjust support, in order to be consistent with the rise of mobile browsers.

What about the UX of firefox? I am typing this comment in a text editor (to be copy pasted when I am done) because I have made so many mistakes related to losing my input. If I am switching tabs and I misclick, I lose my work. If I am not careful and submit while my wifi is gone I often lose my work. Google Mail is one of the few web applications that handles these kinds of problems in a good way. But so many web applications do not, nor do I believe all of them should put in that amount of effort to workaround issues of the webbrowser. Also, there will always be use cases for wanting a dialog that prevents accidental closure. Realtime interaction as I previously commented is a good example. One example that I played many years ago, is runescape, a multiplayer game. If you are fighting an enemy and disconnect, the game does not instantly remove you from the game (otherwise fights would be meaningless). Accidentally closing your tab in firefox would have the same effect. If I were still playing this game I would really want this warning, I would even install/code an extension to bring the warning back.

(In reply to Justin Dolske [:Dolske] from comment #65) > This sounds like a poorly designed system with bad UX. It is well designed system with good UX, which helps users to do specific business things in a batch. > "Non-interruptable" things are prone to all sorts of uncontrollable failures -- the user might > unplug the USB device, suspend their laptop by closing the lid, run out of > battery, the OS or Browser could crash, the network could fail, etc etc. We're aware about that and system is resistant to them - negative effects are minimized, process can be continued (user can lost only current job and reschedule it if needed). But we still want to *remind* them about currently running jobs in background, mostly to block accidentall quits. Nothing less, nothing more.

There's no good reason to leave this misfeature in the web platform. Most of its uses are by fraudulent ads, and most of its "legitimate" uses are unnecessary as well. If browser developers are REALLY WORRIED about dataloss, we can: * Let pages request being frozen (bfcache-style) when closed * If the user hits ⌘⇧T within 10 seconds, restore it with its entire DOM intact. * After 10 seconds pass, tear it down normally, including calling onclose. * Treat onbeforeunload as a [legacy] way to request such cryonics If web-app developers are REALLY WORRIED about dataloss, they can: * Save drafts, both periodically and from onclose, either on the server (XHR) or on the client (localStorage) * Prevent link-click navigation in another way (e.g. use target="_blank") * Suggest that users enable desktop notifications, and fire them from onclose or pagehide or whatever * Suggest that users "pin" the tab, which prevents accidentally closing the tab (but not the window)

It is not all about dataloss. IMHO, a fix should also address accidentally closing applications that are realtime, there is nothing to temporarily store. Two examples: - You are hosting a virtual conference (webcam), instead of clicking on the next tab to google something you hit the tab's close button - You are playing a multiplayer game wherein the world always continues

I fail to understand why this is even up for debate. How on Earth anyone can describe this cornerstone of good UI as a "misfeature" is beyond me. Regardless of saving drafts or the ability to "undo" closing a tab or window (Really? Have you tried "undoing" the closure of your last window? Please let me know how you can get it to resume your previous session, thanks), every sensible application IN THE WORLD prompts the user with an "are you sure" dialog if they try to quit without having manually saved their changes, or if an active connection would be closed. Try it in MS Office, Open Office, Photoshop, any text editor, GoToMeeting etc etc etc... People need this and want this. Accidentally closing any process or application can cause frustrating, embarrassing and even dangerous problems. The supporters of this "bug" are all proposing extremely complex workarounds to support their arguments: - "Who needs an 'are you sure' dialog when you can implement periodic AJAX calls as an autosave?" Perhaps those who don't want to submit several megabytes of data to the web server every 30 seconds or so, consuming their bandwidth and their usage allowance. And, as pointed out by multiple people above, it's nice having autosave but it's also nice to avoid accidentally closing the page in the first place. Plus, instead of having the browser take responsibility for the event, you are asking every single website to take responsibility for it instead. Which might be fair enough if it was the website owners who lost out by failing to comply, but it's the end user who loses out. The browser should be looking after the end user. - "We can add a feature to the browser to remember the session for 10 seconds and restore it if the user hits ctrl-command-alt-F12." Great, that's so much more user-friendly, and I'm sure it'd be a doddle to develop. Not to mention this would require Windows to allow the application to continue to run after its exit command had been executed (or to change the close box to do something other than exit - possibly the worst UI suggestion of them all). I appreciate that this "bug" is not calling to completely remove the onbeforeunload, just to disable it by default, but for many users it's almost the same thing (how many of them understand the browser well enough to even suspect it's an option they can enable?). Why not make it something that is enabled by default but can be disabled in the settings? It seems to be only "advanced" users who want it gone (i.e. those who think that autosave / cryonics are acceptable alternatives) so let's let them do so without punishing the average user.

(In reply to Doug from comment #71) > I fail to understand why this is even up for debate. How on Earth anyone can > describe this cornerstone of good UI as a "misfeature" is beyond me. Really? "cornerstone of good UI"? It seems you are forgetting we are talking about a WEB BROWSER! Ok, some "webapps" can/should use this feature, but for the most part, a web browser is used to browse sites, not host web apps. Although I do agree, "misfeature" is not the correct name. The correct name is attack vector. Years after this bug was created some websites/banners continue to use onbeforeunload to scare / scam some users. Just last night I had to calm my 60 year old Dad, because some f###ing site was saying it was the police, and if he didn't pay some "fine" he would be arrested! This particular site was using the onbeforeunload event to prevent the tab to close, and open a new one each time we tried to close the current tab. > > Regardless of saving drafts or the ability to "undo" closing a tab or window > (Really? Have you tried "undoing" the closure of your last window? Please > let me know how you can get it to resume your previous session, thanks), > every sensible application IN THE WORLD prompts the user with an "are you > sure" dialog if they try to quit without having manually saved their > changes, or if an active connection would be closed. Try it in MS Office, > Open Office, Photoshop, any text editor, GoToMeeting etc etc etc... Again, you are forgetting we are talking about a web browser. If you check, all those programs have one thing in common. They are local/fat clients, not sites. > > People need this and want this. Accidentally closing any process or > application can cause frustrating, embarrassing and even dangerous problems. And being unable to close the window because some site thinks I don't know what I'm doing is unacceptable. It is my computer, it MUST honor my will, not the web designers. > > The supporters of this "bug" are all proposing extremely complex workarounds > to support their arguments: > - "Who needs an 'are you sure' dialog when you can implement periodic AJAX > calls as an autosave?" Perhaps those who don't want to submit several > megabytes of data to the web server every 30 seconds or so, consuming their > bandwidth and their usage allowance. And, as pointed out by multiple people > above, it's nice having autosave but it's also nice to avoid accidentally > closing the page in the first place. Plus, instead of having the browser > take responsibility for the event, you are asking every single website to > take responsibility for it instead. Which might be fair enough if it was the > website owners who lost out by failing to comply, but it's the end user who > loses out. The browser should be looking after the end user. Several Megabytes? You must be the fastest typist in the world. I cannot even imagine how long I wold have to type in order to reach a single megabyte. Again, you must be forgetting we are talking about a web browser. > - "We can add a feature to the browser to remember the session for 10 > seconds and restore it if the user hits ctrl-command-alt-F12." Great, that's > so much more user-friendly, and I'm sure it'd be a doddle to develop. Not to > mention this would require Windows to allow the application to continue to > run after its exit command had been executed (or to change the close box to > do something other than exit - possibly the worst UI suggestion of them all). > > I appreciate that this "bug" is not calling to completely remove the > onbeforeunload, just to disable it by default, but for many users it's > almost the same thing (how many of them understand the browser well enough > to even suspect it's an option they can enable?). > Why not make it something that is enabled by default but can be disabled in > the settings? It seems to be only "advanced" users who want it gone (i.e. > those who think that autosave / cryonics are acceptable alternatives) so > let's let them do so without punishing the average user. Can we reach a compromise? There are other possibly problematic features in FF that have been solved sanely. I can think of "network.automatic-ntlm-auth.trusted-uris". My oppinion, there should be a white list of sites allowed to use this event. It would solve every issue with it. Your internal(or not) bug traker/ web app can be whitelisted, but no random banner can use it. Thanks, Marco

(In reply to marco.marujo from comment #72) > Several Megabytes? You must be the fastest typist in the world. I cannot > even imagine how long I wold have to type in order to reach a single > megabyte. > Again, you must be forgetting we are talking about a web browser. Not all web apps manipulate text and the percentage that don't is only growing over time.

I am also very much AGAINST making this switched-off by default or completely removing it. A HUGE number of web applications are written nowadays to be run in the browser and most of them use this as a protection against data loss. It is silly to think that the browser is nowadays only/mostly used for browsing websites. No, the browser is now also a generic runtime environment for executing complex applications. It would be very unfriendly behaviour from Mozilla to push the responsibility of implementing workarounds to this (they are not trivial to say the least) and even the "whitelist" solution is bad, since it would put a lot of unwanted administration to the shoulders of the application support teams. Maybe, this could be part of the permission system in Firefox for the websites/web-apps like the permission for using the camera. The site requests this (with explanation) when browsed for the first time. The user may or may not allow it. This way, for example, an internal webapp could require this permission its users would naturally grant it. When a website requests it, users may deny this particular permission from the site.

I would suggest that onUnload alert functionality is malicious and should be removed from the javascript browser standard completely, and it should be DEFINITELY TURNED OFF BY DEFAULT, if not completely removed from being supported at all by browsers. When I click the little "x" button on a tab, the tab should CLOSE! End of story. I'm so tired of sites begging and pleading with me not to leave, like scammers.

It is unfortunate to remove beforeunload dialogs before *reliable* auto-saving becomes possible. To understand why reliable auto-saving is not possible to date and how it can be improved, you can take a look at my proposal: "Introduce Promise type BeforeUnloadEvent.prototype.returnValue to allow auto-saving on unloading a page" https://github.com/whatwg/html/issues/963

(In reply to Duan Yao from comment #77) > It is unfortunate to remove beforeunload dialogs before *reliable* > auto-saving becomes possible. > > To understand why reliable auto-saving is not possible to date and how it > can be improved, you can take a look at my proposal: > > "Introduce Promise type BeforeUnloadEvent.prototype.returnValue to allow > auto-saving on unloading a page" > https://github.com/whatwg/html/issues/963 Even with that, it still seems like killing off something simple and reliable over a very limited potential for abuse in exchange for a complex, easy-to-screw up alternative. ...and I still haven't seen a good answer for how to handle auto-save with a single-page application that handles large data (eg. a browser-delivered image editor using WebAssembly to do the heavy lifting). Seems like a bunch of bad options: 1. Save the data to the disk. (So... do I have to allow/deny local storage permission before I have the information to make an informed decision or is it just going to clutter up my hard drive without asking me and hope that there's a good workflow for evicting old data? My local storage is included in my nightly backups and I don't have room to store my entire hard drive worth of data twice!) 2. Save the data to the server and take the hit for transferring it and storing it... keeping in mind that the user may not have an unlimited data plan or fast upstream connectivity. (The fastest I can get around here without paying exhorbitant Canadian cellular data rates is 800kbit upstream and I get DSL resets every few hours which they've tried to mitigate by dropping me to 512kbit.) 3. Discard the data (clearly the worst option) I know that, in this situation, my answer would be "try harder to find a native application which serves the same purpose since, obviously, the browser has demographic'd its way out of servicing people who actually have to get work done."

For what it's worth, the annoyance or attack vector is easily mitigated by adding a UI checkbox to forbid a website or domain to spawn further dialogs of any nature (forever).