Closed Bug 641509 Opened 13 years ago Closed 12 years ago

onbeforeunload event does not display site-supplied text, only standard message

Categories

(Toolkit :: General, defect)

defect
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: bugzilla_ben, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

In Firefox 3.x (and maybe earlier versions) you could customize the text that was displayed to the user by specifying the returnValue for the onbeforeunload event; however, in Firefox 4 the returnValue has no effect and the user is always given the following message:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."



Reproducible: Always

Steps to Reproduce:
Open the following page in Firefox 4

<html>
<head>
  <script type="text/javascript">
  function custom_prompt(event){    
    event.returnValue = 'Hello World';
  }
  </script>
</head>
<body onbeforeunload="custom_prompt(event);">
  When refreshing the page, the prompt should include "Hello World", but it doesn't.
</body>

</html>
Actual Results:  
"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

Expected Results:  
"This page is asking you to confirm that you want to leave - Hello World"
This was an intentional change and is documented here: https://developer.mozilla.org/en/DOM/window.onbeforeunload
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Resolution: INVALID → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
This bug has been re-opened following a lot of complaints being made in bug 588292 (which is about implementing this 'feature' in the first place).  Please consult the responses in that bug for more information.
I'm happy to see that you have reopened the bug and I hope that the dev team grants us the petition to revert this intentional change.
Product: Firefox → Toolkit
QA Contact: general → general
Web pages should be able to explain *why* they're bugging the user with a confirmation, not forced to show a generic message.  This is a strange UI regression that broke alignment with both WebKit and IE9.
Blocks: 588292
OS: Windows 7 → All
Hardware: x86 → All
Isn't there room for a compromise in this if the site-specified text were displayed in a way that suggests that it's not coming from Firefox itself. Just include a content section in the prompt that is offset and/or labeled as site-specific text. I think that would address both the desire for site authors (myself included) to have a custom message for the faithful dialog-reading users out there as well as a solution to the tricks the sketchy sites try to pull with their "Click OK to download a horrible virus. Click Cancel to leave." reverse logic stuff. For example:

Are you sure?

This page is asking you to confirm that you want to
leave. Data you have entered may not be saved.

    Message from http://myapp.com/page:
   +------------------------------------------------------------------------+
   | Leaving this page will end your session, and you will be logged out.   |
   +------------------------------------------------------------------------+

[ Leave this page ]  [ Stay on this page]
IE 9 does what Jason described.
+1. We should at least be able to change this preference in about:config for corporate users with web based application on their own networks.

BUT- I don't understand how this is a security issue, even as a default. If the buttons clearly state "leave this page" and "stay on this page" and the application can't change the button text, how could an unscrupulous website trick users?

Even if *only* the sites message is shown, the buttons themselves don't lie.
Strongly agree that it is wrong to suppress site-generated beforeunload messages. This breaks all my in-house code for accounts, database maintenance and so on.
The message would warn me if there were unsaved changes and list them.

There are two actions I may want to take then:
1) Say a big thank you and save the change;
2) Say no thanks, I don't want to save that one.

I have not seen the second action mentioned in these discussions, but it's just as important - the change might have been accidental or experimental. A form might have dozens or even hundreds of inputs. Without a custom message I have no way of deciding what to to.

I for one am reverting to Firefox 3 until this is reversed.
Ian has brought a VERY important point. I hadn't thought about that. Very important!

A less important reason to allow websites to display messages (at least, in the way IE 9 does it): a lot sales pages use beforeunload event to ask visitors to reconsider leaving and offer another or modified offer. However, the message that Firefox 4 displays (about unsaved data) seems ridiculous and confusing to visitors. 

The current behavior is a result of a very poorly thought out decision.
I can think of a few more reasons for custom text in this dialogue:

We have an advanced web based application (running it it's own profile) that emulates a desktop application. The program has a "master" window, that launches child windows. The master window keeps track of the children, and as the user interacts with child windows, the children notifies the master of different events. Other children need to be aware of such events. Closing the master window is the same as exiting the entire application, since without the master, the children will be unable to communicate with one another.

For example:
1. User opens Master (this is the homepage of the custom profile).
2. User chooses "create purchase order".
3. The Master opens the AddPurchaseOrder window.
4. The AddPurchaseOrder Window tells Master that it wants to know if new vendors are added.
5. The user goes to choose a vendor from the AddPurchaseOrder window's drop down.
6. The user realizes they haven't added the vendor they want yet.
7. The user opens an "AddVendor" window.
8. The user adds a new vendor.
9. The AddVendor window fires an AddVendor event to Master.
10. Master notifies AddPurchaseOrder of the event, and AddPurchaseOrder's Vendor drop down is repopulated to include the new choice.

Of course, if the user chooses to close Master, and receives a vague message saying "This page is asking you to confirm that you want to leave - data you have entered may not be saved", they won't know that closing this window will break the entire application. They'll think, "I haven't added any data to THIS window, I don't need to save anything. And besides, THIS window doesn't even have a save option". Then they call support to say that their application isn't working correctly.

What the message should really say for our application is, "Stop! If you close this window ALL windows will close and you will loose unsaved changes in any and all windows. Do not close this window unless you are done for the day."

There are also situations in web applications when a user obtains an edit lock. If they click cancel, the lock is released. If they close the window, the object they're editing stays locked and an Admin has to go and release it.


Also, couldn't the alert dialog be abused by a malicious web author too? Perhaps we should ignore user alert text and present a generic dialogue that reads:

   +------------------------------------------------------------------------+
   |            This web page is trying to tell you something!              |
   +------------------------------------------------------------------------+

                                                                     [OK]


Ultimately, the purpose of a web browser is to facilitate communication between a website (or application) and it's users. We should try to strike a balance between usability and security. When usability hurdles outweigh the security benefit they supposedly provide and impedes the communication between site and user, is it still in the best interest of the user?

Are there any documented instances where users have been confused by misleading text, since adopting the new button labels?
Hi

I have another scenario where this new behaviour causes problems:

I am the developer for a number of ecommerce sites. 

During checkout, for security, the user data is expired on the server after rendering the page so that someone using browser back & forward buttons can't access a customer's data after an order has been placed.

Instead the application requires the customer to navigate via on-page buttons which re-authenticate the customer. Attempting to access an expired page redirects to the shopping basket & requires a restart of the checkout process. Many banking applications & online stores use this type of behaviour.  

My sites do state that, for security, customers should navigate checkout via on-page buttons rather than their browser back & forward buttons.

Nevertheless, you'd be surprised (or maybe you wouldn't!) at the number of users that don't read the instructions and attempt to navigate via the browser buttons and so end up having to repeat the checkout process. Sometimes multiple times.

Many customers have accounts so they can just log back in and their checkout state is restored however most of my sites also offer the option to 'checkout without registering' - in this case I cannot preserve the checkout state. This results in calls to support, angry emails and, I'm sure, lost business.

Many customers (8%-10% on average), particularly new customers just trying a site out, prefer not to register. Conversion rate goes down on sites which don't offer the facility to 'checkout without registering'

I use(d) the message to politely inform customers that they should use the on-page buttons unless they intend not to complete the transaction at that time. 

In this case the generic text is actually worse than no text at all as there is no 'save' button on the pages leaving customers wondering what it is they should be doing. I have in fact implemented exceptions so that customers checking out with Firefox 4 see no message. At present usage of Firefox 4 across my sites is fairly low so this is not a big issue right now but it is increasing and will soon lead to frustrated customers and lost business.

Please, please consider allowing custom text again - the method suggested by Jason Mobley covers the security angle while still allowing a sensible message to be displayed to the user.
I vote for this. My web-application implements multi-document interface and wants to display the message like this:
====
The following documents are unsaved:
doc1
doc2
doc3

If you leave now, these changes will be discarded. Proceed?
====

If all documents are saved, it allows to close the page without confirmation. Default message displayed by FF now without explaining exact reasons is too vague and distracts user as he might think that our application just want to annoy the user with unnecessary confirmations.

I like the way it's done in Chrome. They just renamed buttons: not "Ok" and "Cancel", but "Leave this page" and "Stay on this page". This way it's much harder to trick the user with inappropriate message.
(In reply to comment #15)
> I can think of a few more reasons for custom text in this dialogue:
> 
> We have an advanced web based application (running it it's own profile) that
> emulates a desktop application. The program has a "master" window, that
> launches child windows. The master window keeps track of the children, and
> as the user interacts with child windows, the children notifies the master
> of different events. Other children need to be aware of such events. Closing
> the master window is the same as exiting the entire application, since

I assume you are using window.open() and populating entire screen with child windows.
If so can you try some thing like
http://dev.sencha.com/deploy/ext-4.0.0/examples/desktop/desktop.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
Users of IE will get a code for a discount for a show at http://shop.ticketluck.com/ResultsTicket.php?evtid=1617560&utm_source=Content_Uploader&utm_medium=internal when they try to close the page, but users of Firefox will get screwed because Firefox doesn't display messages from webpages at this stage.
It is ridiculous that Firefox has unilaterally decided to remove this feature for "security reasons".
This "feature" renders my webapplication useless, please revert it.
There aren't even any "unsaved changes" on the page I want to use this on...

Users have to activate a button, and should be alerted if they leave the page without deactivating it again (it's a physical Sign they are deactivating for testing purposes)

And the so called "security reasons" why this was first implemented are bogus, you could still allow a more precise message to be set without any problems...
I use this feature to ask the use wether he wants to leave the page without saving the changes he made in a form or stay on the page and hit the submit button. 

It's a calculation form with a lot of inputs, so its very bad to leave the page without saving the inputs and start calculation.

Older Versions worked fine and IE 8 also.
I also use this feature in a corporate environment which has lead to lots of users asking what exactly needs to be saved when we're really telling them that they'll be logged out.

I understand that there are possible malicious side effects in some scenarios, but I don't see anything that can't be fixed with a little css to show the message depth (page message v. mozilla message).
I understand you guys had your reasoning for this change, but your reasoning was flawed. This change needs to be reverted.
I suggest adding an about:config parameter called "user.drools_on_self", set to true initially. Users who can set this to false will see site-supplied onbeforeunload text.
For people looking for a workaround feel free to take this snippet and edit it to fit your needs:

https://bugzilla.mozilla.org/show_bug.cgi?id=588292#c76

Not a real solution, but at least it will let people know that something is wrong with the browser and not with the developer.
To give a slightly different perspective here: as someone who often finds himself in the position of supporting people he knows remotely over the phone, I find the change to ignore the site-supplied message extraordinarily helpful.  Now, the dialog always looks the same, and I can always tell the user 'click the "Leave Page"' button.

Having read all the messages on this bug, I can see a few different cases, none of which justify displaying site-controlled messages in browser chrome:

- Several people commented as though the onbeforeunload has gone away entirely, which it has not.  You can still ensure that the user doesn't leave the page before saving, unless they want to do so.  ("I use this feature to ask the use wether he wants to leave the page without saving the changes he made in a form or stay on the page and hit the submit button.")

- If you want to tell the user what they need to save, do so in the page; as far as I know you can do DOM manipulation from within onbeforeunload.  You could easily display a floating message if you want, which will clearly appear to come from the site, and can contain much richer information (arbitrary HTML) than a plain-text string.

- The site which breaks the browser's back and forward buttons could easily fix that.  Take a look at the new HTML5 history API; you can completely control the back and forward process between pages in your site via Javascript, without breaking the user's back and forward buttons.  And if you want to log the user out when they navigate, for security reasons, you can do that easily enough from onbeforeunload without prompting.  Don't break the back and forward buttons, ever.

- The site displaying a discount code in the onbeforeunload dialog needs to rethink that; it certainly has nothing to do with whether the user wants to leave the page or not, and behavior like that sounds more like what you'd expect from malicious sites.

- The site wanting users to log out could simply log them out from the onbeforeunload, without prompting at all.
Summary: onbeforeunload event no longer allows customization of text in dialog box → onbeforeunload event does not display site-supplied text, only standard message
No longer blocks: 588292
(In reply to Josh Triplett from comment #28)
> To give a slightly different perspective here: as someone who often finds
> himself in the position of supporting people he knows remotely over the
> phone, I find the change to ignore the site-supplied message extraordinarily
> helpful.  Now, the dialog always looks the same, and I can always tell the
> user 'click the "Leave Page"' button.

This is uninteresting.  If you don't know the UI of something you're stepping someone through over the phone, you're always going to get headaches.  If you do know the UI, this is irrelevant.

The rest of this comment is merely workarounds, not arguments for this change.  Even if they were good workarounds (not all of them are), that's not how the Web platform works: you don't make a breaking change and expect everyone to update their pages to adapt for the change, without a very compelling reason.

This is wrong:

> If you want to tell the user what they need to save, do so in the page

You don't show information about a dialog in the window *underneath* a modal prompt; the dialog may be partially or completely obscuring the page, and typical UIs deliberately focus the user's attention away from the parent window when showing a dialog.


As an aside, another site this change breaks is http://grooveshark.com.  It plays music, and shows "Leaving now will interrupt the song you're listening to" if the tab is closed while music is playing.  The generic message Firefox shows is incorrect and confusing.
@Josh - We are proposing that the text in the dialogue be changed, not necessarily the button text. As long as the buttons always say "Leave Page" and "Stay on Page", it is impossible to trick the user by displaying a custom message. Additionally, you can still tell a user what to click over the phone since the buttons don't change. Google Chrome user's don't seem to have a problem with this approach.

What is your solution for usage cases in which there are multiple windows interconnected with javascript, and closing one window will break the others? The user must be alerted of this when attempting to close a window, but cannot be in Firefox 4 since the fixed message is completely unrelated to the problem.

At the very least, this should be changeable via about:config and not hard coded. Or perhaps a check box in javascript settings.
(In reply to Glenn Maynard from comment #29)
> (In reply to Josh Triplett from comment #28)
> > To give a slightly different perspective here: as someone who often finds
> > himself in the position of supporting people he knows remotely over the
> > phone, I find the change to ignore the site-supplied message extraordinarily
> > helpful.  Now, the dialog always looks the same, and I can always tell the
> > user 'click the "Leave Page"' button.
> 
> This is uninteresting.  If you don't know the UI of something you're
> stepping someone through over the phone, you're always going to get
> headaches.  If you do know the UI, this is irrelevant.

I do know the UI, because the site can't change it.  If the site *can* change it, then I have to get that much clearer of an explanation over the phone to make sure they haven't gotten it confused with some other dialog, for which the wrong answer would cause much greater concern.

> The rest of this comment is merely workarounds, not arguments for this
> change.  Even if they were good workarounds (not all of them are), that's
> not how the Web platform works: you don't make a breaking change and expect
> everyone to update their pages to adapt for the change, without a very
> compelling reason.

onbeforeunload still works exactly as designed: it helps make sure the user doesn't lose data.  You don't have to update your webpage; it still works fine.  You should, though, to give the user a better experience.

Firefox also "breaks" the ability to pop up new windows when not requested by the user, by design, and people love Firefox for that.

> This is wrong:
> 
> > If you want to tell the user what they need to save, do so in the page
> 
> You don't show information about a dialog in the window *underneath* a modal
> prompt; the dialog may be partially or completely obscuring the page, and
> typical UIs deliberately focus the user's attention away from the parent
> window when showing a dialog.

Granted.  The ultimate fix is to act like a web page, and make sure the user's data stays safe even when they navigate, keeping the user in control.  onbeforeunload is a workaround for not doing that.

> 
> As an aside, another site this change breaks is http://grooveshark.com.  It
> plays music, and shows "Leaving now will interrupt the song you're listening
> to" if the tab is closed while music is playing.  The generic message
> Firefox shows is incorrect and confusing.

That page should just not use onbeforeunload.  Of *course* closing a music site will stop the music.  The user won't lose any data if that happens, and they can easily go back to the site.
(In reply to Nick from comment #30)
> @Josh - We are proposing that the text in the dialogue be changed, not
> necessarily the button text. As long as the buttons always say "Leave Page"
> and "Stay on Page", it is impossible to trick the user by displaying a
> custom message.

You think so?  Ever done tech support when you can't see the user's screen, and they're concerned they'll do something wrong?  It's challenging enough even when the site can't include a message like "YOUR COMPUTER IS INSECURE, LEAVING COULD CAUSE YOU TO GET INFECTED.".  Allowing site-supplied text means I get to spend an extra few minutes explaining why the site is wrong about that and why their computer is still safe.  (Note that I'm not the type to say "just do it" without an explanation.)

> What is your solution for usage cases in which there are multiple windows
> interconnected with javascript, and closing one window will break the
> others? The user must be alerted of this when attempting to close a window,
> but cannot be in Firefox 4 since the fixed message is completely unrelated
> to the problem.

For one thing, I'd say "fix the app to not do that", but to give a more concrete suggestion I'd need to know what the site does with those multiple windows.

> At the very least, this should be changeable via about:config and not hard
> coded. Or perhaps a check box in javascript settings.

As long as the default remains "don't let sites try to trick the user", an about:config setting for advanced/intranet users seems perfectly acceptable.  I have a lot of sympathy for people dealing with legacy web apps they can't change, and they ought to have the ability to customize Firefox to make it easier for their use cases.
I don't personally use this on my public site, but I use it extensively for local code which maintains complex databases. If I edit a record then navigate away by mistake, the code doesn't just warn me to save - it lists exactly what values have been changed and what the old and new values are. 
Without this information I can't tell whether I should save or not. I might just have typed a character by mistake, or I might have made extensive changes that are wanted.
There's nothing more infuriating than software like Excel (my version anyway) that constantly asks you if you want to save without giving you a clue as to what's changed.
A config option would sort this for me, but without at least that I am stuck forever on Firefox 3.

Please, everyone who wants this horrible change reverted, make sure you have voted!
(In reply to Josh Triplett from comment #32)
> (In reply to Nick from comment #30)
> > @Josh - We are proposing that the text in the dialogue be changed, not
> > necessarily the button text. As long as the buttons always say "Leave Page"
> > and "Stay on Page", it is impossible to trick the user by displaying a
> > custom message.
> 
> You think so?  Ever done tech support when you can't see the user's screen,
> and they're concerned they'll do something wrong?  It's challenging enough
> even when the site can't include a message like "YOUR COMPUTER IS INSECURE,
> LEAVING COULD CAUSE YOU TO GET INFECTED.".  Allowing site-supplied text
> means I get to spend an extra few minutes explaining why the site is wrong
> about that and why their computer is still safe.  (Note that I'm not the
> type to say "just do it" without an explanation.)

This shouldn't be a problem as long as Firefox includes a little disclaimer and the site-supplied text is clearly identified, as suggested above and in the original bug.  See Comment 10.

There's also the point that the user has already visited a malicious site and has probably been exposed to more confusing things already, which I think was mentioned in the original bug.
b(In reply to Ian from comment #33)
> I don't personally use this on my public site, but I use it extensively for
> local code which maintains complex databases. If I edit a record then
> navigate away by mistake, the code doesn't just warn me to save - it lists
> exactly what values have been changed and what the old and new values are. 
> Without this information I can't tell whether I should save or not. I might
> just have typed a character by mistake, or I might have made extensive
> changes that are wanted.

Couldn't your code mark changed fields, and add an in-page indicator saying "data changed and not yet saved"?  The onbeforeunload will avoid the "accidental navigation" problem, and your site can handle telling the user exactly what they haven't saved.
(In reply to Josh Triplett from comment #31)
> I do know the UI, because the site can't change it.  

No, the UI *of the site itself*.  If you don't even know the site, the UI of one isolated dialog is not going to help you very much.

Anyhow, there's always the option of having boilerplate text around it ("the page is asking if you really want to close it, here's why:"), though I personally think that's unnecessary.  (It'll often lead to ugly dialogs that say things like "the page is asking if you want to close the window: Close the window?".)

> onbeforeunload still works exactly as designed: it helps make sure the user
> doesn't lose data.

onbeforeunload is designed to allow the site to explain why it's confirming being closed; that's not working.  Worse, text is being displayed which is, in some cases, wrong and confusing.

> You don't have to update your webpage; it still works
> fine.  You should, though, to give the user a better experience.

Saying "data may not be saved" when the page is trying to say "your music will stop" is not working fine.  As I said, it's outright confusing (it suggests that things like playlists aren't saved, which is not the case on Grooveshark).

> Firefox also "breaks" the ability to pop up new windows when not requested
> by the user, by design, and people love Firefox for that.

Opening unwanted popups is disruptive; in extreme cases, destructive.  Preventing pages from opening dozens of popups is a *compelling reason* to break compatibility, which is missing here.

> Granted.  The ultimate fix is to act like a web page, and make sure the
> user's data stays safe even when they navigate, keeping the user in control.
> onbeforeunload is a workaround for not doing that.

Short of saving changes continually (clearly not always an option), this isn't possible in general.  If I'm typing a mail in Gmail, and I hit control-F4, the page has no reliable opportunity to save a draft; it's too late.

> That page should just not use onbeforeunload.  Of *course* closing a music
> site will stop the music.  The user won't lose any data if that happens, and
> they can easily go back to the site.

If we were discussing the initial implementation of onbeforeload, before it was already in production and widely used, this might be an argument against supporting script-specified messages in the first place.  But we're not: this feature is already widely implemented and used in the wild, and pages already exist which make use of the standard behavior.
(In reply to Josh Triplett from comment #35)
 
> Couldn't your code mark changed fields, and add an in-page indicator saying
> "data changed and not yet saved"?  The onbeforeunload will avoid the
> "accidental navigation" problem, and your site can handle telling the user
> exactly what they haven't saved.

I could also stick postit notes on the screen by every change I make and audit them later.
But that could be tricky when a form might have hundreds of fields, and I might want to look at a different page now and then.
The point is, we already had the functionality we needed. Why should we have to rewrite everything because some anonymous programmer decides to make an arbitrary change that breaks the browser, and (afaik) has not even deigned to defend it?
Perhaps Firefox should also refuse to display colours in case a web site uses too much red and a user goes berserk.
I think we should not discuss how we can make workarounds (as we had to do it for IE). Firefox had the function we need and we just want it back.
(In reply to Glenn Maynard from comment #36)
> this feature is already widely implemented and used in the wild, and pages
> already exist which make use of the standard behavior.

Completely agree with this statement, on the other side, Josh, please stop giving vague arguments to make this bug report a big debate.

The fact is that a widely used feature must not be removed, at least not until a way to re-enable it is provided (although IMHO it should be enabled by default). The dev team took the wrong decision removing the ability to customize the text of onbeforeunload.

Personally I have started to discourage friends and relatives from using Firefox, and I'm happy to see that Firefox market share is decreasing day by day since many features broken, removed or not implemented are making it more and more annoying to use. It was a nice browser until version 3.6, I hope that Firefox devs realize they're doing things wrong before its too late.
(In reply to Aldonio from comment #39)
> (In reply to Glenn Maynard from comment #36)
> > this feature is already widely implemented and used in the wild, and pages
> > already exist which make use of the standard behavior.
> 
> Completely agree with this statement, on the other side, Josh, please stop
> giving vague arguments to make this bug report a big debate.

"Please shut up so this bug report looks unanimous"?  This change was made for a reason.  If you think something is vague about my comments, feel free to poke holes in them.  More to the point, neither the change nor reverting it is something that will occur simply because a pile of people repeat the same arguments, on either side.  If you want it reverted you should make a better case than "because it always worked that way".

> The fact is that a widely used feature must not be removed, at least not
> until a way to re-enable it is provided (although IMHO it should be enabled
> by default). The dev team took the wrong decision removing the ability to
> customize the text of onbeforeunload.

How many web apps do you suppose counted on window.open to work when not triggered by a click?  All of those web apps broke when Firefox introduced pop-up blocking.  They could work around the problem by putting the content in the same window, or by only triggering the pop-up on click, but I suspect they'd have felt happier if Firefox hadn't made their apps stop working by removing a "widely-used feature".

Similarly, Netscape Layers went away despite widespread use, because better alternatives existed.

A few other changes which affected functionality used by many apps and still remained in place:
https://developer.mozilla.org/En/Same-origin_policy_for_file%3a_URIs
https://bugzilla.mozilla.org/show_bug.cgi?id=340571

(None of that is an argument against having a preference to enable onbeforeunload messages, which seems entirely reasonable if for no other reason than legacy/intranet apps.)
"you should make a better case than "because it always worked that way"."

That is in fact, by itself, a *fantastic* reason to not change something. The reason popup blockers broke pre-existing behavior is because there was an extremely compelling counter-argument. Same with most breaking interface changes.

I put it to you, then: What is the *compelling reason* that long-standing behavior should be broken, without advance notice to users and developers, and without a equivalent-functionality workaround?

"My clients might get confused" is *not* going to cut it.
> This change was made for a reason.

Nobody has explained what that reason is, aside from some vague, nonsensical handwaving about security.

I keep asking, and you still havn't given a *compelling reason* for this change, which I take to mean you don't have one.  I've pointed out the compelling reason for changing how popups worked, but you ignore that and keep trying to use that as precedent for removing things for *no* reason.  Any in any case, I don't see any indication that anyone in UX is even reading this ticket.  So, I don't think this discussion is a good use of time, and am pulling out for now.
(In reply to Glenn Maynard from comment #42)
> > This change was made for a reason.
> 
> Nobody has explained what that reason is, aside from some vague, nonsensical
> handwaving about security.

You might not like the reason, but that was the stated reason.  Bug 588292 contains explanations of the rationale.  See, for example, bug 588292 comment 37 (from a member of the Firefox UX team).

In any case, I agree that there seems little point in any of us commenting further on this bug without anyone from Mozilla around to make a judgment call.
I believe the change to the generic dialog is fundamentally flawed, in that it does not actually address the issue it set out to solve.

IIRC, the original reason for making the change was to prevent users being confused by (for example) attack sites that reverse the meaning of the "ok" and "cancel" buttons in order to deliberately trick users to staying on the site, or by sites with poorly worded custom text.

I think the buttons on the new dialog are a great thing which does exactly that, but that the generic "data you have entered may not be saved" partially if not completely negates that advantage. Instead of confusing users as to where they will be navigating to with each option, they are instead often going to be confused by what data exactly is not going to be saved - especially in the multitude of cases where that (potential loss of data) is not the reason the dialog is being displayed.

Case in point: I'm writing a questionnaire website. I want to display a message if a user navigates away from a page and has missed a question. They can go onto a different page if they want to (no data will be lost) but I'd like to give them some warning that they'll have to come back and complete the page if they continue. The current generic dialog gives entirely the wrong impression.

I think that the current buttons solve the original issue, and allowing custom text will not impact on that solution. It would take a seriously daft user to be tricked into clicking on "stay on page", and I can't see that developing specifically for the percentage of people that are that challenged is really worth sacrificing usability for the other 99.99% of people.
What about allowing only HTTPS pages to specify a custom message?
(In reply to Adrian from comment #45)
> What about allowing only HTTPS pages to specify a custom message?

https is trivial for any site to support these days; you can get a free domain-validated certificate, and in any case malicious sites have the resources to purchase certificates.  I don't think https makes a site any more or less likely to use onbeforeunload maliciously.
Why?  What does that solve?
(In reply to Mark Clements from comment #47)
> Why?  What does that solve?

That was in response to comment 45, by the way...
(In reply to Mac.Coombe from comment #44)
> Case in point: I'm writing a questionnaire website. I want to display a
> message if a user navigates away from a page and has missed a question. They
> can go onto a different page if they want to (no data will be lost) but I'd
> like to give them some warning that they'll have to come back and complete
> the page if they continue. The current generic dialog gives entirely the
> wrong impression.

I've seen survey sites with the same problem which solved it in a much more friendly way: they already have a page indicator which points to the current page and shows all the pages (as an indication of progress), so they mark incomplete pages in that indicator, and if you hit the end without completing them you get a message saying to go back to the pages you haven't completed yet.

Visual indications aside, if your questionnaire allows the user to proceed without completing a page and come back to it later, I'd guess you already have some mechanism to check when the user gets to the end without completion, and take them back to the page(s) they haven't yet completed, since they can't submit the questionnaire otherwise.  That seems quite sufficient without annoying the user with an onbeforeunload.

Whether you agree with it or not, this change to Firefox seems to indicate that onbeforeunload *should* only get used when the message makes sense: when the user has unsaved data.  Nonetheless, the message still makes sense if the user has no unsaved data; it simply says that any unsaved data may be lost, so if you don't have any unsaved data you have nothing to lose by navigating away.

Now, on the flip side of that, I find it incredibly helpful that the dialog always looks identical, because now I can instantly identify it as the standard onbeforeunload dialog and click "leave page", rather than having to stare at yet another variation for a moment (because, button text aside, I don't dismiss dialogs without reading them).
(In reply to Josh Triplett from comment #49)
> I've seen survey sites with the same problem which solved it in a much more
> friendly way

Anyone who says they've seen this problem solved in other ways, is ignoring the fact that *this wasn't a problem before*!

The issue here is that a pointless UI change has been introduced (yes, pointless - the reasoning behind it was incorrect), and broken a bunch of stuff on the web.  The fact that there's "another way to do it" is irrelevant.

> Now, on the flip side of that, I find it incredibly helpful that the dialog
> always looks identical, because now I can instantly identify it as the
> standard onbeforeunload dialog and click "leave page", rather than having to
> stare at yet another variation for a moment (because, button text aside, I
> don't dismiss dialogs without reading them).

So, what you're saying is that you prefer to have a dialog that is always identical, but doesn't actually impart the correct meaning, than one which actually tells you why leaving the page might be a problem?  We're back to "This web page is trying to ask you something - [ok] [cancel]".
(In reply to Mark Clements from comment #50)
> > Now, on the flip side of that, I find it incredibly helpful that the dialog
> > always looks identical, because now I can instantly identify it as the
> > standard onbeforeunload dialog and click "leave page", rather than having to
> > stare at yet another variation for a moment (because, button text aside, I
> > don't dismiss dialogs without reading them).
> 
> So, what you're saying is that you prefer to have a dialog that is always
> identical, but doesn't actually impart the correct meaning, than one which
> actually tells you why leaving the page might be a problem?  We're back to
> "This web page is trying to ask you something - [ok] [cancel]".

Just FYI, I already responded to his argument:

> Anyhow, there's always the option of having boilerplate text around it ("the page is asking if you really want to close it, here's why:"), though I personally think that's unnecessary.  (It'll often lead to ugly dialogs that say things like "the page is asking if you want to close the window: Close the window?".)

Repeating debunked arguments verbatim is dishonest argument.
(In reply to Glenn Maynard from comment #51)
> Repeating debunked arguments verbatim is dishonest argument.

"verbatim" is misleading; I responded to the point in question, trying to suggest some possible rationale.  In any case, I think we can both agree that no *new* arguments seem likely to show up here, and I don't think either group seems likely to convince the other.  As mentioned previously, no argumentation about this issue will likely matter unless someone at Mozilla looks at this issue further and decides to consider an alternative to the current behavior.
(In reply to Mark Clements from comment #50)
> (In reply to Josh Triplett from comment #49)
> > I've seen survey sites with the same problem which solved it in a much more
> > friendly way
> 
> Anyone who says they've seen this problem solved in other ways, is ignoring
> the fact that *this wasn't a problem before*!

When I said "the same problem", I meant the problem of helping users fill in a survey while skipping around, which remains a problem regardless of what mechanism you'd like to use to solve it.  Perhaps "use case" would make it more clear?  Hence me mentioning a more user-friendly solution to the same problem / use case.

> The issue here is that a pointless UI change has been introduced (yes,
> pointless - the reasoning behind it was incorrect), and broken a bunch of
> stuff on the web.  The fact that there's "another way to do it" is
> irrelevant.

Your disagreement with the reasoning seems quite clear.  Your arguments seem to suggest that the people making the change didn't know that sites used onbeforeunload for purposes other than warning about unsaved data, and thus you and many other people have pointed out other uses of onbeforeunload in an attempt to say "what about this other case?".  You don't seem to consider the possibility that the people making the change *did* know about the various uses of onbeforeunload, and intentionally decided to adopt wording and behavior that steers sites away from all but the intended use.

> > Now, on the flip side of that, I find it incredibly helpful that the dialog
> > always looks identical, because now I can instantly identify it as the
> > standard onbeforeunload dialog and click "leave page", rather than having to
> > stare at yet another variation for a moment (because, button text aside, I
> > don't dismiss dialogs without reading them).
> 
> So, what you're saying is that you prefer to have a dialog that is always
> identical, but doesn't actually impart the correct meaning, than one which
> actually tells you why leaving the page might be a problem?  We're back to
> "This web page is trying to ask you something - [ok] [cancel]".

I prefer to have a dialog which handles the one case of onbeforeunload that will ever cause me to click on "Stay on Page", namely that I'll lose data if I navigate away.  If I don't have data I care about on the page (whether because I have no data on the page or because I want to intentionally discard it), I can then safely navigate away.

Even then, I tend to file bug reports about sites which cause me to lose data through navigation; those bug reports don't say "warn me before throwing away data", they say "don't lose my data".  There's no excuse for losing data in the "accidental navigation" case, for instance, when browsers remember the contents of text areas and such.  Yet ever so often I hit a site which somehow manages to completely wipe a form if I unintentionally navigate away and back.
(In reply to Josh Triplett from comment #52)
> (In reply to Glenn Maynard from comment #51)
> > Repeating debunked arguments verbatim is dishonest argument.
> 
> "verbatim" is misleading; I responded to the point in question, trying to
> suggest some possible rationale.  In any case, I think we can both agree
> that no *new* arguments seem likely to show up here, and I don't think
> either group seems likely to convince the other.  As mentioned previously,
> no argumentation about this issue will likely matter unless someone at
> Mozilla looks at this issue further and decides to consider an alternative
> to the current behavior.

This is a plainly absurd thing to say less than two hours after you yourself engaged the argument for four paragraphs.

And regardless, I'm not arguing the issue; I'm advising Mark that he's debating an argument that was already refuted.  It's trivial to make the dialog recognizable while still fixing this bug.  Despite that, you repeat the claim as if it's an argument for not including the message.

(I have no hope of this bug getting fixed, so I'll be wishing everyone a great happiness and removing myself from the CC.)
As mentioned befor: We just need this message back. 

All the argues about security reasons or stupid messages don't convince me.

I have some forms with hundreds of fields, an intelligent message is very helpfull for the users to understand what's happening when they leave the page.

Another important case is remebering the user to confirm that all data shown in the form are correct, even when no change was made.
> Another important case is remebering the user to confirm that all data shown
> in the form are correct, even when no change was made.
Using onbeforeunload for this purpose is completely wrong! You can use the onsubmit event of the form for this purpose and cancel submission and/or alert() a message.
Yeah... best of luck to everyone. I'm sticking with FF 3.6 and recommending Chrome to my relatives when they ask for tech support.
> Yeah... best of luck to everyone. I'm sticking with FF 3.6 and recommending
> Chrome to my relatives when they ask for tech support.
Recommending chrome.. ok - it's a nice browser so nothing against that.
But using an ancient version just because of a ridiculous thing like that? Well.. if you ever get malware because of that version - you'll deserve it.
(In reply to Josh Triplett from comment #49)
> I've seen survey sites with the same problem which solved it in a much more
> friendly way: they already have a page indicator which points to the current
> page and shows all the pages (as an indication of progress), so they mark
> incomplete pages in that indicator, and if you hit the end without
> completing them you get a message saying to go back to the pages you haven't
> completed yet.

I can't really say I disagree - I do believe there are better options here than using onbeforeunload. I'm using it in my project due to specification requirements for the project - ones I can't say I can agree with, but that I can't change either. However, my intent wasn't to discuss a particular case such as this, but to illustrate the fact that onbeforeunload is used for much more than handling potential data loss, and to force it to only be used for such ruins a whole variety of applications that use it for other equally valid purposes - it severely degrades the usefulness of the event.

(In reply to Josh Triplett from comment #53)
> You don't seem to consider the possibility that the people making
> the change *did* know about the various uses of onbeforeunload, and
> intentionally decided to adopt wording and behavior that steers
> sites away from all but the intended use.

Can you cite a reference, from an established standard, that onbeforeunload is intended only for protecting against loss of data? Apart from anything else, I'd love to be able to give a good argument *against* its use in my project. If it is the case, I'd also be willing to concede that FF has it right, and that it is the standard that is flawed... :)
(In reply to Mac.Coombe from comment #59)
In fact, come to think of it, what is the point of onbeforeunload returning a string if it is not meant to be displayed? I think that by not displaying the returned string, the current behaviour must be counter to specification because of that very fact alone.
(In reply to Mac Coombe from comment #59)
> (In reply to Josh Triplett from comment #49)
> > I've seen survey sites with the same problem which solved it in a much more
> > friendly way: they already have a page indicator which points to the current
> > page and shows all the pages (as an indication of progress), so they mark
> > incomplete pages in that indicator, and if you hit the end without
> > completing them you get a message saying to go back to the pages you haven't
> > completed yet.
> 
> I can't really say I disagree - I do believe there are better options here
> than using onbeforeunload. I'm using it in my project due to specification
> requirements for the project - ones I can't say I can agree with, but that I
> can't change either.

Out of curiosity, what's the spec requirement?

Note, in particular, that you can easily react to the user navigating to a different survey page via clicked links or form buttons without needing onbeforeunload.  Also note that you could choose to control the user's entire navigation of your site via the history API, and handle forward and back yourself.  So, onbeforeunload really only helps you if the user tries to leave your site entirely, not just navigate to another page on your site.

> However, my intent wasn't to discuss a particular case
> such as this, but to illustrate the fact that onbeforeunload is used for
> much more than handling potential data loss, and to force it to only be used
> for such ruins a whole variety of applications that use it for other equally
> valid purposes - it severely degrades the usefulness of the event.

See above: intra-site navigation doesn't require onbeforeunload at all, only navigation to a different site.

> (In reply to Josh Triplett from comment #53)
> > You don't seem to consider the possibility that the people making
> > the change *did* know about the various uses of onbeforeunload, and
> > intentionally decided to adopt wording and behavior that steers
> > sites away from all but the intended use.
> 
> Can you cite a reference, from an established standard, that onbeforeunload
> is intended only for protecting against loss of data? Apart from anything
> else, I'd love to be able to give a good argument *against* its use in my
> project. If it is the case, I'd also be willing to concede that FF has it
> right, and that it is the standard that is flawed... :)

The HTML5 spec talks about onbeforeunload, and mentions prompting the user and waiting for a response as a "must", but showing the returned message as a "may".  As far as I can tell, no previous HTML or DOM Events standard mentions beforeunload (just unload), so I think it falls in the category of "de-facto stuff provided by most browsers and thus documented in HTML5".  According to developer.mozilla.org, onbeforeunload originally appeared in IE4, and other browsers copied it from there; AFAICT Mozilla copied it in 2004.

For some of the original discussion, see bug 68215.  All of the original comments I see relate to preserving unsaved data / unsubmitted forms.

You might also find http://www.alistapart.com/articles/neveruseawarning useful.
(In reply to Josh Triplett from comment #40)
> How many web apps do you suppose counted on window.open to work when not
> triggered by a click?  All of those web apps broke when Firefox introduced
> pop-up blocking.
You can't compare pop-ups with onbeforeunload, since pop-ups still work the way they're meant to work; the only additional step is the user consent to display pop-ups, which is fine since it improves the user experience, whereas onbeforeunload its the opposite case, there is no way to know what the page wants to tell you, neither a way to allow the page to display it, the ability to see the text its just gone.

This is an elaborated example where the generic message doesn't help at all and just makes the user experience worse:

You already pressed "send payment" in your bank page, which is a well designed web app who works nice even with slow connections AND you are indeed under a slow connection, so the information is not being sent as fast as you are used to.
It's really likely that the web app will just cache your actions in a queue and then send the queue to the server in order to allow you to continue using the app, since the experience was good enough you completely forgot you were under a slow connection, plus you didn't watch the "Sending" text because you were in a hurry, so you proceed to close it.
Since the bank page its not ready yet to get closed it launches onbeforeunload with the following message:

"Dear customer, please wait a few moments before closing the page, your payment is still being sent to our servers."

but thanks to our beloved firefox developers the onbeforeunload dialog says:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

You as a tech savvy person, who understands that this behavior is just a whim from the firefox devs will think "OK, I have pressed close too early, I just remembered that this connection sucks and the page doesn't work as fast as I'm used to, I'll wait a few seconds and try to close the page again".

What do you think the average user will think about it? Specially if the user "already did everything he needed to do to make a payment"?

...

Regardless the answer I believe my users deserve "the best web experience regardless the browser they use" and that onbeforeunload behavior its stupid, it breaks the web experience, not only to them but to everyone. If firefox devs wanted to remove the text they must have added the option to display it in the first place.

Anyway, this is a losing battle, the time every person has dedicated to this bug report is worthless for the dev ream, they didn't even have the kindness to come here and say something like "we have read your test cases and are analyzing whether to revert the ability to customize the text or not", the last official word was at January 4th (Bug 588292/Comment 37), so I'm also removing myself from the CC list, have a nice time people.
(In reply to Adrian from comment #56)
> > Another important case is remebering the user to confirm that all data shown
> > in the form are correct, even when no change was made.
> Using onbeforeunload for this purpose is completely wrong! You can use the
> onsubmit event of the form for this purpose and cancel submission and/or
> alert() a message.

I know that, sorry, I didn't explain the complete scenario.
The form opens in a new window (window.open).
First usage is to get some information. 
Second usage is to confirm/update the data. This is required only if the last submission is older than 30 days.
So only if the the 30 days period is exceeded the rememder with onbeforeunload appears when the window is closed.
I agree with Mac Coombe, the way the function is working right now contradicts the specs.
The status says: "Nobody; OK to take it and work on it". Does that mean that we can submit a patch? Does anybody know how to make a patch or where in the code we would have to edit? It seems like it would be as simple as taking the function from the 3.6 branch and using it to patch the broken 4, 5, 6, and 7 branches. Any thoughts on that?

Also, does anyone know how to get this in front of decision makers/developers? Do they have meetings where we could put this on the agenda or something?

I'm getting tired of having to use 3.6 seemingly forever just so our company's application works correctly.
As I understand, all malicious fast-evolving sites will now implement alert() in onbeforeunload() event and still fool user, but all legitimate, unmaintained (or slowly and costly maintained) systems will loose some of it's functionality. Was that the real intention of FF developers?
This should AT LEAST be system configurable. Sometimes we rely heavily on browser behaviors especially in enterprise systems, a sudden change like this is disheartening. User needs to know why the page wants him/her to stay.

Workaround to tell your unhappy clients: Don't upgrade your Firefox, or use Chrome  or IE which has the expected behavior.
OK everyone - here's a workaround for you. 

1. You'll need to have some kind of message system in place, whether that be a js dialog or, in our case we use a span that slides down from the top of the viewport to give one line messages.

2. Capture the beforeunload event

3. Insert this:
window.onbeforeunload = function() {
    var msg = 'Some message that represents your problem';
    // mozilla has kindly killed the unload messages
    if (Ext.isGecko) {
        // this triggers your alternative message system described above
        PageMessage.show(msg);
    }
    return msg;
}


We use ExtJS, but browser detection is easy enough whether you're using a foundation library or just doing it on your own.

Make sure that you don't use any animations (timers) to show your message as the builtin unload dialog halts all timer events.

It's not perfect, but at least you can tell people what's going without Mozilla trying to block you.

Note to Mozilla: THIS STILL NEEDS TO BE FIXED! We shouldn't need creative workarounds to use perfectly valid and well established behaviours!
This is ridiculous - the "problem" that this "feature" is intended to address has a simple alternative solution that has been clearly articulated a number of times (see comments 10 and 30, my comment 44) and which doesn't break applications. The Mozilla team clearly disagree, so I'm switching to Chrome (permanently), and removing myself from this discussion - this is getting nowhere.

I wish all the rest of you arguing for the correction of this mis-feature the best of luck. I do hope this is fixed so that I don't have to force *my* users to avoid Firefox should I ever have a need to use onbeforeunload.
We just had this reported by a customer that noticed that if you use the X button on our application window in firefox the custom warning we provide to warn the end user they are about to lock a product licence no longer shows.

All other mainstream browsers support this feature it's rediculous that Firefox has forced a standard message an you can no longer provide a custom message to the end user when the accidentally click to X the window.

This is still occuring in FF 11.0 that I have just updated to.
Why is this just sitting here in limbo? This bug has been here for over a year and is still marked NEW. Mozilla should either fix this issue and put the site-supplied text back in the dialog, or come in here and tell us they don't care about what their users have to say and just close the ticket. Flat-out ignoring the complaints is far worse than admitting you won't fix the problem.

Thankfully, for our application, I'm one of the few people who will have to deal with this - we have already moved our users to Chrome. The only reason I use Firefox anymore is because I love Firebug - maybe I'll look back into Chrome's Developer Tools (Firebug Lite doesn't cut it). Regardless, I'm just gonna keep coding as if this functionality worked as expected, as it does in other major browsers.
We made an explicit decision in bug 588292 to display only the standard message to thwart social engineering and spoofing.

Displaying a prompt to prevent a user from accidentally closing a page should be self-explanatory. It's generally poorly constructed UI to have to explain to users why they should not close a page at the moment that they try to do so.

There is also bug 391834 to block alert/confirm/prompt inside onbeforeunload.
Status: NEW → RESOLVED
Closed: 13 years ago12 years ago
Resolution: --- → WONTFIX
I thought this was already WONTFIX, I guess I missed it being reopened way back in comment 3?

In any case, yes, definitely deliberate. It's been a year and a half, and it's noteworthy how few _end-user_ issues this has generated. So I think at this point it's pretty unlikely we're going to revisit the issue.
Status: RESOLVED → VERIFIED
It's a wrong decision, as has been explained above repeatedly and beyond any possible doubt.
Frank: Yes I saw that bug first, which led me here. The comments there and here completely refute the arguments for getting rid of the site-supplied text, and arguments that web apps using the site-supplied text are poorly designed seem to come solely from Mozilla developers, but thank you for stating that you're doing your best to break any workarounds as well.

Justin: I don't think it is noteworthy at all, considering that many web developers will use workarounds or avoid using this functionality for anything other than a simple static page with a single form, and users will likely blame any issues that arise on the web site rather than the browser anyway. But thanks for clarifying that this will not be fixed any time in the near future.
I'll never understand your decision, your argue "poorly constructed UI" that's definitivly wrong! Just try to understand all the explanations above - they all want to build user friendly pages.
User friendly pages may use a script to define UserAgent of the user and if ua=Firefox then do the following:
when such a prompt appears in the Firefox - it's initial position is always at the middle of the window.
So the site could actually use the rest of the space to inform the user about anything it wants.

I don't usually agree with most Mozilla's wontfix resolutions, but here - I think there is no problem for a web-master to add a proper notification.
(In reply to Sean Newman from comment #77)
> when such a prompt appears in the Firefox - it's initial position is always
> at the middle of the window.

No it's not. The positioning of the prompt is dependent on the operating system. Gnome Shell/Linux (and I believe OSX as well) displays the prompt at the top of the window, not the center. Regardless, it would be a bad idea to base your design on such transient qualities as window positioning - you have absolutely NO guarantee that the window will show up in any given location.

Besides, displaying two dialogs for the same purpose is definitely a poor UI design.
(In reply to Frank Yan (:fryn) from comment #72)
> We made an explicit decision in bug 588292 to display only the standard
> message to thwart social engineering and spoofing.

The decision made has significant negative side effects, which is why this bug was opened.  There have been good arguments made in this ticket for other solutions that would eliminate the social engineering and spoofing potential while not having these side effects.  It is extremely disappointing that this ticket got closed without any discussion about those alternate designs, or even any indication that they were considered.  This reflects extremely poorly on the Firefox team.

> Displaying a prompt to prevent a user from accidentally closing a page
> should be self-explanatory.

The problem is that in a sufficiently complex AJAX-rich application, it is not always self-evident why onbeforeload is warning the user, even in the common case that there is unsaved data.  Why should the user have to deal with a mystery-meat warning the browser has chosen to display when the application is providing the user with a much more meaningful message?

The previous comments are full of examples where the generic warning message is not sufficient.

> It's generally poorly constructed UI to have to
> explain to users why they should not close a page at the moment that they
> try to do so.

It's generally good UI to give a specific warning to users when they are about to do something potentially harmful.
Webchat: "Do you really want to leave the chatroom?" -> firefox's message = bad
Radio player: "Leaving this page will stop playback" -> firefox's message = bad

WONTFIXing this issue is just a bad idea....
...and countless other examples, a number of which have already been given.

It does seem a bit like the FF team has taken a fingers-in-ears "nah-nah-nah, I can't hear you" approach to this issue.
(In reply to Mark Clements from comment #81)

> It does seem a bit like the FF team has taken a fingers-in-ears
> "nah-nah-nah, I can't hear you" approach to this issue.

No, I think we understand the issues raised quite well and have been listening. The problem is that we simply fundamentally disagree on a number of points and the severity of not addressing them. At this point there's really no new information being raised, and so there's nothing that leads me to believe this decision needs revisited. I know it sucks to be on that end of a decision, but it's inevitable that we won't please everyone. Sorry.
I think I'd like a more detailed explanation of why we can't have a dialog that is secure AND shows site supplied text. There's really two issue here. 1. The previous version of the dialog was subject to social engineering by unscrupulous websites and 2. the new version, while fixing number 1, breaks usability for the cases described above.

I think the correct thing to do in this case is to come up with a design for this dialog that accomplishes both goals. That is, we should not revert to the old version, but we should not dismiss this issue either. Neither is a good solution since each only solves one of our two objectives.

I think both goals could be easily accomplished by displaying the site supplied text in such a way that it is visually clear to the user that the text is coming from the page. Put it in quotes, put it in italics, put it in a box that displays it like a block quote. Make the text on the buttons fixed "leave page" and "stay on page".

If the above was implemented, please explain how such a dialog could still be exploited? If the text is contained and the buttons are clearly labeled, I don't understand what a site could possibly put in that box to trick users.

If there *is* a legitimate security concern, I think it should be posted here so we can understand why the decision was made. Can those who made the decision to leave this interface as is please supply us with a string of text that would confuse users with the dialog described above? Can you also explain why it is not possible to make this an *optional* change (preferences, about:config)?
The following work-around can be implemented:

<style>
.alert {
  position: absolute; background-color: #FF2;
  width: 100%; height: 15pt; padding: 2pt; top: 0px; left: 0px;
}
.close {
  position: absolute; right: 5pt; cursor: pointer;
}
</style>
<script>
window.onbeforeunload = function (evt) {
  var message = "Document 'foo' is not saved. You will lost the changes if you leave the page.";
  if (typeof evt == "undefined") {
    evt = window.event;
  }
  if (evt) {
    evt.returnValue = message;
  }
  var div = document.createElement("div");
  div.className="alert";
  var closeButton = document.createElement("div");
  closeButton.className="close";
  closeButton.appendChild(document.createTextNode("[x]"));
  closeButton.addEventListener("click", function() {document.body.removeChild(div)});
  div.appendChild(closeButton);
  div.appendChild(document.createTextNode(message));
  document.body.appendChild(div);
  return message;
}
</script>
<body>
</body>

This is just an idea (not mine), of course you may improve it.
(In reply to Nick from comment #83)
> If there *is* a legitimate security concern, I think it should be posted
> here so we can understand why the decision was made.

And why other browsers, such as Chrome, have not felt it's a security concern if they present a well-worded dialog with both some standard text as well as the site-supplied text.
People, please stop, Mozilla won't listen unless the one requesting this change is a Google employee. See the discussion from 11 years ago for more info:

https://bugzilla.mozilla.org/show_bug.cgi?id=68215#c41

*3 years old drama about whether to implement onbeforeunload or not*
Google Employee: Hey! We use onbeforeunload in blogger and people loves it!
*Patch submitted. Implement onbeforeunload*

Even if it was a coincidence, don't loose your time trying to give valid reasons, they have already said this:

(In reply to Justin Dolske [:Dolske] from comment #82)
> No, I think we understand the issues raised quite well and have been
> listening. (...). I know it sucks to be on that end
> of a decision, but it's inevitable that we won't please everyone. Sorry.

My expectations were at least an about:config setting to re-enable onbeforeunload, not even that choice was given to us, so there's no helping it. onbeforeunload in Firefox is a lost cause.
(In reply to Justin Dolske [:Dolske] from comment #82)
> No, I think we understand the issues raised quite well and have been
> listening. The problem is that we simply fundamentally don't care enough
> to discuss the matter. I know it sucks but we're not here to please.

Paraphrased, but that's how it sounds. And now the popups ...
"Your version of Firefox will soon be vulnerable to online attacks. You will be prompted once more before being automatically updated."

We are to be terminated. Disgraceful. Why don't you just change the name to FireFascist?
I think other browser have a better solution to this problem that the one implemented here, that seems only to lower usability without real advantages in security.
I see there are over a year of comments on this feature/bug (buggy feature).  The trouble here, as I see it, is that while web pages are becoming more and more like applications, they nevertheless still operate under an ever-changing browser context.  As browsers upgrade, these web applications will often become ever more bug-riddled, or may fail entirely.

My opinion on this particular feature/bug is that Chrome and IE seem both to have a decent approach: allow a custom message to be shown, but keep standard buttons.  If some hackers decides to tease users with a faulty message, so be it.  What's the worst thing a hacker can do? Some users will find themselves clicking "Stay on page" when really they wanted to leave because the message was confusing. Don't you think eventually they'd figure it out? 

Considering this and other security features, it becomes more and more important for developers to develop better state-saving mechanisms.  This is where ajax can come in handy, if used to do an auto-save of the state of the form to the server every so often.  Or possibly local cache, now that HTML5 has more ways to save state...
(In reply to Justin Dolske [:Dolske] from comment #73)
> In any case, yes, definitely deliberate. It's been a year and a half, and
> it's noteworthy how few _end-user_ issues this has generated. So I think at
> this point it's pretty unlikely we're going to revisit the issue.

That's because no end user would figure out it's Firefox's fault that they don't get to see what page edits they did they are about to lose when leaving a page, but blame the bad UX on the site seemingly not letting them know, and file them with us web developers instead (or show up as red marks in our user tests).

As long as you don't address bug 391834, we can hand our Firefox 4+ users the same information our Chrome or IE users get, via hacks like http://jsfiddle.net/ecmanaut/hQ3AQ/ though, at just the cost of a degraded user experience compared to those browsers.
(In reply to Johan Sundström from comment #90)
If they don't worry, developers also should not worry.
Just put a big warning on the site saying FF is not supported, like in old good days with IE6. Let's see if they like it when see this online everywhere.
Obviously removing this "standard" feature has caused mass issues, especially with business web apps, such is the case for us.

Why don't they get a grip and add an option to re-enable it. How hard can it be? It is then upto the user to then switch the setting back on and allow custom error messages...where is the security risk in that?

Because the anus's removedthe custom message feature we have had to revert back to using IE and have had to mass un-install firefox from over 1000 of our desktops/laptops....you know how much f**king grief that caused us!!!! 

Seriously you have no idea the impact your irresponsible changes cause....do some proper community feedback next time you want to fiddle with standard/accepted behaviour.
it's not hard to do, it's only that they don't want to. it's so sad that a browser that it had success thanks to the community support now don't listen a thing about what anyone is saying. Such narrow minded dev thought this was a security issue and has to be fixed, without asking to the community what impact could have on existing applications, probably they thinks everybody will change their application to do things in a different way.. no, doesn't work like this in big companies and institutional organizations.
I don't know why I still write here, probably nobody will read again a bug flagged as "WONTFIX".
Hi everyone,

I was wondering if anyone on this cc list might have development experience and we could work together to create a patch? I found the place in the source code where this behaviour was changed, but wasn't sure how to reverse it.
(In reply to Nick from comment #96)
> Hi everyone,
> 
> I was wondering if anyone on this cc list might have development experience
> and we could work together to create a patch? I found the place in the
> source code where this behaviour was changed, but wasn't sure how to reverse
> it.

You understand that such a patch won't be accepted right? We've decided that this issue is a WONTFIX, not because we don't know how to patch it but because we don't think it should be patched.
Mozilla obviously isn't serious about the corporate market. We've started recommending Chrome or IE to our clients.
About the corporate users - it would be good for them to allow showing site-supplied text in the message for some sort of "trusted sites", so that intranet sites could be trusted and could show the message.

P.S: Casey, IE, you're kidding :-D
Yeh - that's how annoyed I am. :-)
Just another vote to disagree with the developers' choice to disable this custom message. The problems this choice has caused heavily outweigh any perceived improvement in security. Other browser developers seem to have found a way to address that security concern.

You say you're not here to please. Well if you don't please your "customers", you'll find yourself "out of business". End users are not your only customers, web developers are as well, and yes, if FF no longer meets our needs we won't be supporting it. You don't know better than those of us that disagree with you, you just have a different opinion, and you might just be outvoted, one way or another.
This historic decision is looking even worse with the advent of Web Apps authored in cappuccino for example.

The idea that the average user can be using a web app which runs in the browser, and fully understand the implications of the generic warning message, is quite silly.

They do not understand the difference between a tabview, a subview, an iframe or a "page" as reported by Firefox. 

Therefore they are unable to determine what the hell the firefox message means at all. Will they leave the tab they just clicked on?, the floating window they were in in the browser, or the entire application.

"Page" simply does not cut it, in this situation. The concept is beyond the user.

We need the option to replace the word "Page", with "Application" for web apps, at the very least.

This is clearly a decision made by geeks (no offense intended - we're all geeks here) without fully reviewing the implications with respect to non-geeks, and the future of web technologies.

Bad call Mozilla.
I think they explained clearly they will never look again on this decision, at this point I think for them it's only important to keep the point, even considering to review again the decision is admit they made something "wrong"(not true, only to be improved for me). Behind this there could be someone with a GIGANTIC ego :D
I'm just happy to not work with him, imagine the hell!
(In reply to HanSolo from comment #93)
> interesting....
> http://www.techspot.com/news/48404-chrome-ie-market-share-creeps-upward-
> firefox-losing-ground.html

and only 2 months later...?

http://en.wikipedia.org/w/index.php?title=File:Usage_share_of_web_browsers_(Source_StatCounter).svg&page=1

it is only a matter of time before ff users start migrating to chrome en-masse.

The most popular, non-MS browser will be the browser of choice :( 

shame cos ff is otherwise brilliant...but this is going to be a knife in the heart in the web app world.
(In reply to Richard Irwin from comment #102)
> Just another vote to disagree with the developers' choice to disable this
> custom message.

Same here. Custom exit messages are very important for web apps.

_option_

Hide the custom message by default, but show a link to "Display message provided by this page >>>".
The below workaround let us accomplish this in a different way. But really beforeunloads never lead to a better system, they just save you the work of building a better system in my experience. 

 window.addEventListener('beforeunload', function(){
                if (isFirefox){                    
                        if (confirm(dialog text)){
                            history.go();
                        } else {
                            window.setTimeout(function() {
                                window.stop();
                            }, 1);
                        }
                }
                //normal stuff for other browsers
            });
(In reply to plowman from comment #107)
> But really beforeunloads never lead to a better system, they
> just save you the work of building a better system in my
> experience. 

By that argument, alert() and confirm() should also be removed.
(In reply to plowman from comment #107)
> The below workaround let us accomplish this in a different way. But really
> beforeunloads never lead to a better system, they just save you the work of
> building a better system in my experience. 
> 
>  window.addEventListener('beforeunload', function(){
>                 if (isFirefox){                    
>                         if (confirm(dialog text)){
>                             history.go();
>                         } else {
>                             window.setTimeout(function() {
>                                 window.stop();
>                             }, 1);
>                         }
>                 }
>                 //normal stuff for other browsers
>             });


I thought having a well understood mechanism to notify the user of the consequences of navigating away from the current page, and giving the user the option to change their mind was preferable to completely hijacking the navigation process. In my naiveté I believed the browsers actually protected against such hijacking and so never tried it myself. I will have to check to see that calling window.stop() really works across all browsers to keep the user on my page.
> In my naiveté I believed the browsers actually protected against such hijacking and so never tried it myself. I will have to check to see that calling window.stop() really works across all browsers to keep the user on my page.

If it works, it's a bug that will be fixed; don't count on it.

Think about how malicious sites would abuse that if it worked.
_workaround_

http://jsfiddle.net/deathApril/YB7K2/

window.onbeforeunload = function(){
    document.getElementById("message").innerHTML="custom message";
    return true;
};

tested in:
Firefox 21.0
Firefox 22.0

of course it needs some feature detection for browsers who can display custom exit messages already...
(In reply to Josh Triplett from comment #110)
> > In my naiveté I believed the browsers actually protected against such hijacking and so never tried it myself. I will have to check to see that calling window.stop() really works across all browsers to keep the user on my page.
> 
> If it works, it's a bug that will be fixed; don't count on it.
> 
> Think about how malicious sites would abuse that if it worked.

Exactly... my comment was sarcasm. Sadly, calling window.stop() does work on the current version of FF, Safari and Chrome. It didn't work on IE 10. So, here we quibble about whether displaying a customized string is appropriate, but a "workaround" is to exploit what I would consider a much more severe security hole.
Why on earth is this a wontfix????
Having a standard message always displayed is ok, but what's the reasoning behind not allowing to _add_ a custom text?!?!?!?
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.