Closed Bug 588292 Opened 14 years ago Closed 14 years ago

Remove site-supplied text for beforeunload and onunload dialogs, and improve button text

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: faaborg, Assigned: Dolske)

References

(Depends on 1 open bug)

Details

(Keywords: csectype-spoof, sec-want, Whiteboard: [strings])

Attachments

(6 files, 1 obsolete file)

Testcase
(deleted), text/html
Details
Screenshot (current dialog)
(deleted), image/png
Details
Screenshot (patch v.1 + OS X)
(deleted), image/png
Details
Screenshot (patch v.1 + Win7)
(deleted), image/png
Details
Patch v.2
(deleted), patch
Details | Diff | Splinter Review
onunload.html
(deleted), text/html
Details 
Similar to bug 562258 which covers javascript dialogs, we need to make sure that beforeunload and onunload dialogs are tab modal panels as well.
Assignee: nobody → dolske
Also possibly needs a separate bug (or has already) for removing the web site text (security issue!) + changing buttons to "Stay on Page" / "Leave Page"
Morphing this bug report a bit, since these will become tab-modal as a side effect of fixing bug 59314.

What's needed to resolve this bug:

1. Remove the site-supplied text, since this is a security issue (untrusted text in browser dialogs)

2. Change the buttons to say: "Stay on page" & "Leave page" instead of OK/Cancel

3. Change the existing text:

"""
Confirm

Are you sure you want to navigate away from this page?

{{{site-supplied text}}}

Press OK to continue, or Cancel to stay on the current page.

[OK] [Cancel]

"""

to a more concise:

"""
Leave this page?

Any data entered in forms may not have been saved.

[Stay on page] [Leave page]

"""

Leaving the page should be the default selected action, as is the current behavior, and staying should be the secondary action.

Requesting blocking because of the (simple) string changes.
blocking2.0: --- → ?
Summary: Convert beforeunload and onunload dialogs to tab modal panels → Remove site-supplied text for beforeunload and onunload dialogs, and improve button text
Whiteboard: [strings]
Attached file Testcase (deleted) — 
Trivial testcase that triggers this dialog.
Attached image Screenshot (current dialog) (deleted) — 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v.1 (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  
Note that aPermitUnload is initialized to PR_TRUE at the top of this function, so if any of the early-return-on-error cases happen, it's equivalent to clicking Leave Page (it already works this way).

        Attachment #475426 -
        Flags: ui-review?(limi)

        Attachment #475426 -
        Flags: review?(jst)

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot (patch v.1 + OS X) (deleted)
        — 
      

    


  
Note that the first line of text in the OS X dialog is really the "window title" as Windows/Linux see it. I'll attach a screenshot of that next.

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot (patch v.1 + Win7) (deleted)
        — 
      

    


  

    
    

    
  
Comment on attachment 475426 [details] [diff] [review]
Patch v.1

I believe the proper spelling is "Whoa there"? …and I'm not sure if this is OK tone-wise — although I personally think it's cute and appropriately whimsical.

Looks great, let's get this in!

        Attachment #475426 -
        Flags: ui-review?(limi) → ui-review+

    
    

    
  
Seriously, I'm off bugmail for a few hours and you get a "Whoa" landed?  aw, snap :p

I think this takes us too far towards en-us-ca.

    
    

    
  
Also "Leave this page?" is bordering on being a fragment.

        Attachment #475426 -
        Flags: review?(jst) → review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v.2 (deleted)
        — 
          — Splinter Review
      

    


  
Tweaked strings per previous comments and on IRC with Limi.

        Attachment #475426 -
        Attachment is obsolete: true

    
    

    
  
Let's call this blocking+, since it's changing strings and arguably how the site interacts with the dialog (by us no longer showing the site's text).
blocking2.0: ? → beta7+

    
    

    
  
Comment on attachment 475625 [details] [diff] [review]
Patch v.2

Actually, beltzner wants to take another stabs at these strings.

        Attachment #475625 -
        Flags: ui-review?(beltzner)

    
    

    
  
Note to self: it would be super-awesome if we started a catalog of "how the web uses this feature" so we could be more sure of ourselves, here ;)

I'm *slightly* uncomfortable with the presumption that we know what all sites use onBeforeUnload to do - yes, most use it as a way of saying that navigating away from a place will lose your data, but I do also know of a couple of cases where the site wants to destroy connections or cookies on shutdown so they want the user to click "logout."

While I agree, pretty vehemently, that we should be masking the website's text, I do think that it's important to indicate that it is the website which is asking us to get the user's confirmation.

As for "Whoa there" - while I like fun UI, and while it's an improvement over "Confirm", I don't know if it actually communicates the right concept.

My suggestion would be:

Are you sure?

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

      [ Leave Page ] [ Stay on Page ]

(leave page / stay on page still sounds awkward, but I guess it works)

    
    

    
  
Pushed http://hg.mozilla.org/mozilla-central/rev/03ef56304b2d

(with beltzner's strings)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7

    
  

        Attachment #475625 -
        Flags: ui-review?(beltzner)

    
    

    
  
(In reply to comment #14)
> This page is asking you to confirm that you want to
> leave - data you have entered may not be saved.

Should use a double hyphen, no?

    
    

    
  
(In reply to comment #16)
> Should use a double hyphen, no?

Em dash, I mean.

    
    

    
  
Yeah, emdash would be better. also, should probably put the word "any" back in there.

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

I can whip up a patch if needs be, once I get off this flight.

    
    

    
  
Hi all, please see bug 315415
What should be the expected behaviour there?
Depends on: 315415

    
    

    
  

      
      
      
      

        Attached file
          
        onunload.html (deleted)
        — 
      

    


  
I feel now after fixing this we will more sites abusing 
Bug 391834 - Don't allow alert/confirm/prompt in onbeforeunload and onunload 

See test at onunload.html

    
  
Depends on: 391834

    
    

    
  
(In reply to comment #14)
> My suggestion would be:
> 
> Are you sure?
> 
> This page is asking you to confirm that you want to
> leave - data you have entered may not be saved.
> 
>       [ Leave Page ] [ Stay on Page ]

A little late, I know.  Why have a dash when this is two separate sentences?

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

Also, I thought questions in the title bar were frowned on.

    
    

    
  
The new button captions make this dialogue box less clear. As a user, I find myself asking: which page is meant by "Page" in each of the captions?

    
    

    
  
Google Chrome does:

Title Bar: Confirm Navigation
[site supplied message]
[ Leave Page ] [ Stay on Page ]

Chrome is winning on K.I.S.S. points.

What I have found is that users ignore most alerts and just hit the Enter key.  And the more verbage you add, the less likely they are to read it.

Please realize that the attention span of the average web user is 1000 times less than your considered deep analysis here.  And realize they are in hurry to go look at something that interests them and they want the annoying alerts out-of-the-way.

My 2 cents.

    
    

    
  
Correction:

Title Bar: Confirm Navigation
[site supplied message]
[ Leave this Page ] [ Stay on this Page ]

    
    

    
  
You could make the title bar more context sensitive:

1. If closing browser or tab, change "Confirm Navigation" to "Confirm Close".

2. If the page title will be changing, i.e. the navigation is not a frame, then "Confirm Leave".

3. Put a portion of the page title in the title bar, e.g. "Confirm Navigation - [...]".

    
    

    
  
I definitely appreciate the change from "OK"/"Cancel" to "Leave Page"/"Stay on Page" but removing the custom text has confused me on more than one occasion. This is because when a legitimate site pops up the confirmation dialogue with "Leave Page"/"Stay on Page" options, I'm left wondering why it is asking me that, rather than just navigating to the next page. Is there something I've forgotten to do? I choose to stay on the page, and look to see if there's something I haven't saved, but there are lots of sections to the form which can each be saved separately. It turns out that the site is trying to helpfully tell me which section I haven't saved but that information is thrown away.

Now that the button text has been changed, can't the site text be included and still not pose a security risk? Old sites used to be able to say "Press OK to stay on this page" (a lie) but you can hardly convince people to "Press Leave this Page to stay on this page". If the text is sanitised (limited in length and dangerous characters stripped out) and a label saying "The page provides the following information:" can this be brought back?

The button text change was a usability win but the lack of site-provided text is a usability loss. There are many sites that use this in a useful way and many intranet sites that use this too.

    
    

    
  
(In reply to comment #31)

See bug 578828, Jesse's suggestion is by default not to allow onbeforeunload.
This is because modern sites with Ajax dont need that facility. They can save data as DRAFT in background, in fact gmail already use it. If a session got disconnected with out user implicitly saving it web application can prompt user what to do when user visit it next.

    
    

    
  
(In reply to comment #31)

Such a example is the message you get when closing "POP-UP-ed" chat window in gmail. That is when you close gmail main window the onbeforeunload pup-up comes with a message listing all userids you where chatting in in popup windows.
Again I dont know why GMail had to do that.

    
    

    
  
I also just saw this on eBay's live chat. After the agent ended the chat (which disables any interaction but leaves the window open with the conversation still visible), I went to close the window and got the "Leave Page / Stay on Page" question. It wasn't clear why and it then takes a bit of time to look around, before deciding that it probably isn't an important reason. Looking at the code I can see that the message would have made it more obvious that it was just a confirmation question, rather than anything important. They don't even need the message in this case, but having it there without the text leaves me wondering what the reason for it's appearance is.

In this case I would actually prefer bug 578828 over the current behaviour, but I would prefer Chromium's behaviour over both of them (display the message and have unambiguous buttons).

I think the current behaviour just leaves people confused. Why are you asking me if I want to leave the page? This doesn't normally happen when I close a tab. Why should I choose "Stay on Page" as you've suggested (with the default button)? This is where the site-supplied text would help.

I won't say any more, there are enough use cases that people can find or imagine where the text is useful. This bug should have been split into 2 parts: improve the button text (good) and remove the site-supplied text (bad).

    
    

    
  
(In reply to comment #34)
> Why should I choose "Stay on Page" as you've suggested (with the default
> button)? This is where the site-supplied text would help.

Sorry, I made a mistake, the default is "Leave Page".

    
    

    
  
(In reply to comment #34)
> In this case I would actually prefer bug 578828 over the current behaviour, but
> I would prefer Chromium's behaviour over both of them (display the message and
> have unambiguous buttons).
> I think the current behaviour just leaves people confused.
[snip]
> I won't say any more, there are enough use cases that people can find or
> imagine where the text is useful. This bug should have been split into 2 parts:
> improve the button text (good) and remove the site-supplied text (bad).

That is what I had suggested before this change was made in my Bug 586907, and Comment 27 to Comment 29.

    
    

    
  
(In reply to comment #31)
> The button text change was a usability win but the lack of site-provided text
> is a usability loss. There are many sites that use this in a useful way and
> many intranet sites that use this too.

The security downsides of allowing site-provided text for this dialog outweighed the usefulness of the custom text. Most of the sites we tested use this to warn you that you'll lose your edits on the page if you navigate away or similar, so it wasn't seen as adding much compared to the confusion of the "OMG YOUR COMPUTER IS INFECTED BY A VIRUS" messages were causing.

    
    

    
  
(In reply to comment #37)
> The security downsides of allowing site-provided text for this dialog

There is no security (i.e. secure perimeter) violated by displaying ascii text.

You conflating phishing vulnerability with secured perimeters.

If you are concerned about phishing, then just turn off the browser, because the web page the user is closing could very well be displaying phishing before they attempt to close it.

As for the tsuris of being lied to, the user eventually figures it out, after a few clicks.  There set of possible phishing threats is not increased by displaying some ascii text.

But for damn sure, you have created more tsuris for the good sites, and there is no solution for the user.

And I happen to believe that users spend 95+% of their time on good sites.

So you applied the {Pareto principle}^3 backwards.  Congrats :(

> outweighed the usefulness of the custom text. Most of the sites we tested use
> this to warn you that you'll lose your edits on the page if you navigate away
> or similar, so it wasn't seen as adding much compared to the confusion of the
> "OMG YOUR COMPUTER IS INFECTED BY A VIRUS" messages were causing.

Not losing your edits is not worth anything?

Then why does Firebox ask me if I want to save my tabs when I choose Quit?  And why does Yahoo Messenger and Skype ask me if I really want to close?  And pretty much every program in the universe ask me to save my data before I leave.

Have you ever heard of accidentally clicking the wrong button?

Geez the IQ here is stifling.

    
    

    
  
Just wait until the complaints come flooding in from users and web page developers.  Release this in into the wild.  You will learn how to lose market share to Chrome.

    
    

    
  
I understand you still display a message, so the user still has an opportunity to cancel.  The problem is that the user is given no information as to why they might need to cancel.  They don't know why the page is warning them.

If you want to get anal about, you can put the site supplied text in a tiny font, and put inside of a another box that is clearly labeled with normal size font, on top "The page you are closing <i>claims</i>:", and on bottom "Firefox did not verify that claim.".

I would also put in the title bar:

"Close this page? url or title of the page"

Come on guys, don't obfuscate necessary functionality in the void impossibility of eliminating all phishing possibilities.  The proper display of the site supplied text with sufficient disclaimers, is adequate defense against phishing.

Sorry I should have been more forceful earlier in this bug report, but I had confidence in your Firefox developers to make the most rational decision. Unfortunately you did not.  Please undo and fix.

    
    

    
  
(In reply to comment #38)

> You conflating phishing vulnerability with secured perimeters.

The terminology here isn't important.

> Not losing your edits is not worth anything?

The dialog hasn't been removed, and in fact explicitly includes a warning about unsaved data. I have to wonder if you've actually looked at the current implementation, or are just lashing out irrationally.

> Then why does Firebox ask me if I want to save my tabs when I choose Quit?

Bug 592822. But there's a world of difference between what the browser is allowed to do and what arbitrary content can.

> Geez the IQ here is stifling.

These kinds of comments are not welcome. If you can't discuss a change without name calling, feel free to not comment at all.

    
    

    
  
(In reply to comment #41)
> > You conflating phishing vulnerability with secured perimeters.
> 
> The terminology here isn't important.

Nonsense. Phishing vulnerability has a different risk level than a security perimeter vulnerability.

Phishing means the user might be able to fooled into doing something.  A security perimeter means that a secure data channel might be violated.

If you are going to make decisions about risk, at least get some education about security science first.

My point is that the phishing vulnerability of displaying the site supplied text is ZERO (as in 0), because the web page that is supplying the text was being view by the user, so if the web page wanted to trick the user, it could have done it already.

The only additional vulnerability from displaying the site supplied text is the possible mis-association of the popup dialog with the browser or computer, rather than with the page that supplied the text.  And the resultant potential tsuris and confusion.

This is why I suggested that you embed the site supplied text in a grooved box with a scroll bars, and prepend with the warnings above and below the box per Comment #40.

> > Not losing your edits is not worth anything?
> 
> The dialog hasn't been removed, and in fact explicitly includes a warning about
> unsaved data. I have to wonder if you've actually looked at the current
> implementation, or are just lashing out irrationally.

But that may make no sense to the user in the context of what they were doing on that web page. And thus they may lose their data.  The user needs the context of the site supplied text to know what is going on, e.g.

"your last game play was not finished, if you quit in the middle of it, you will be thrown back to the start level next time you return".

How is a generic message going to explain that?  Geez isn't it SOBO.

> > Then why does Firebox ask me if I want to save my tabs when I choose Quit?
> 
> Bug 592822. But there's a world of difference between what the browser is
> allowed to do and what arbitrary content can.
> 
> > Geez the IQ here is stifling.
> 
> These kinds of comments are not welcome. If you can't discuss a change without
> name calling, feel free to not comment at all.

It is a reflection of the frustration of have to explain SOBO concepts.

SOBO = statement of the blatantly obvious

    
    

    
  
Additionally it is actually worse to remove the bad site-supplied text, because now the bad sites are obfuscated from me, so I am unable to know that I should not return to them.

This assumes you adequately demarcate the site-supplied text, per my suggestion in Comment #40.

The reason for my lashing out is because you have removed a long-standing feature of browsers.  When removing features that break the web, you had better be sure you know what you are doing, and you had better see the SOBO concepts, otherwise you don't deserve to be in a position of authority to make that change.  My frustration is deeper in the nonsense I see out there of conflating protecting secure channels with issues that have nothing to do with security, e.g. thank God for the <script> tag otherwise the boneheads would have prevented us from doing cross-site scripting, because they conflate cross-site script injection with secure channels.  They attack the wrong vectors, and they don't even understand what I am talking about.  Nevertheless, sometimes it is just better to shut myself up and compete in the market with a better solution.  Enough said.  Fix it if you wish.

    
    

    
  
Easy people, if firefox developers doesn't have to fix it if they don't want to do it, there are always a way to warn your users.

if ( /Firefox[\/\s](\d+)/.test(navigator.userAgent) && new Number(RegExp.$1) >= 4 )
{
	document.getElementById("form-header").innerHTML = "<h1 class=\"warning\">You are using Firefox 4 or above, which is not capable of displaying enough information about the data you might loose if you dont save before leaving. Proceed with caution or install another browser if you don't want to see this message.</h1>";
}

    
    

    
  
It is not just the issue of potentially losing the last state, because in theory a site could always save the state and ask on next visit, "Do you wish to restore to the state when you last departed this site, or do you wish to go back to the earlier state that you explicitly saved?".

The issue also includes phenomena that can not be saved. For example, if in the middle of a videochat, or monitoring a live lab experiment, or any other real-time process. If one closes the site window and loses that connection, then it is lost. User may have forgotten they had such a real-time connection open and the reminder might be helpful-- versus realizing it much later or never, that it been silently discarded.

    
    

    
  
What exactly is the problem of displaying the site-provided message in this dialogue? I still don't understand that. Every other browser does it. Is Firefox the super-most-secure one of all now? And I was probably lucky enough to add this event handler into my site while still using Firefox 3.6 to see that it works at all.

If you're so afraid about letting the site display anything as chrome-like windows, then you should also disallow the alert() function, which can very well still be called right before the beforeunload question. It's an ugly solution because it will trigger two windows in sequence, but if that's the only way to make the point... "If you're leaving it will cause this and that. Please decide in the *next* window that pops up."

Unfortunately if has been the case more often than not that browser insufficiencies have been misinterpreted as webmaster incapabilities. And that's where I begin to feel personally offended.

After all, my site is actually recommending Firefox for IE < 9 users.

Saving all changed data as draft via AJAX may be possible if you add enough complexity to your web app, but even that is actually the wrong behaviour. My page already features a "save as draft" button. The user may expect that anything is saved only when he presses that button and not otherwise. It is still perfectly okay to leave a page and intentionally discard changes. You never know what the user means in this situation unless you *tell* and ask him. I wouldn't want to have those changes applied to my draft if I didn't explicitly request it.

    
    

    
  
Please re-enable the site specified message.

I work on a rather complex web application (RIA, Ajax, the works), where a user is not losing form data, but the entire state of the application: open tabs and dialogs, loaded data etc.
So, my site specified message warns the user 'if you continue, the application will close'. The message is in the users language, which is an application setting, and can be different from the installed browser language.

I could live with the decision not to show the message, if it was a real security issue (XSS, CSRF, even infinite alerts). But one line of text that some people find confusing? They just saw an entire webpage from the same site..

    
    

    
  
(In reply to comment #14)
> Note to self: it would be super-awesome if we started a catalog of "how the web
> uses this feature" so we could be more sure of ourselves, here ;)
> 
> I'm *slightly* uncomfortable with the presumption that we know what all sites
> use onBeforeUnload to do - yes, most use it as a way of saying that navigating
> away from a place will lose your data, but I do also know of a couple of cases
> where the site wants to destroy connections or cookies on shutdown so they want
> the user to click "logout."
> 
> While I agree, pretty vehemently, that we should be masking the website's text,
> I do think that it's important to indicate that it is the website which is
> asking us to get the user's confirmation.
> 
> As for "Whoa there" - while I like fun UI, and while it's an improvement over
> "Confirm", I don't know if it actually communicates the right concept.
> 
> My suggestion would be:
> 
> Are you sure?
> 
> This page is asking you to confirm that you want to
> leave - data you have entered may not be saved.
> 
>       [ Leave Page ] [ Stay on Page ]
> 
> (leave page / stay on page still sounds awkward, but I guess it works)

We use onbeforeunload to tell users to logout from the session for security reasons. This change would leave us(and presumably others using this feature similarly) no good way when user leaves the site or just closes the browser/tab. maybe allowing alternate text ot having a browser close event cioming from browser would solve this.

    
    

    
  
(In reply to comment #49)
> We use onbeforeunload to tell users to logout from the session for security
> reasons.

On onbeforeunload/onunload event is still there, you can write code to automatically logout when there is tab/window close. The usecase you mentioned really dont need an additional user interaction to logout.

    
    

    
  
So the ability to show a custom message got removed just because some not so smart users might be confused by bad sites? I think browser developers need to stop catering brain-dead people and those who give a **** about how stupid a question in a dialog sounds and believe every ****. They are likely to do bad thing with their PC anyway. If it happens often enough they might finally decide to get at least some knowledge...

    
    

    
  
I think we should have the standard prompt (similar to what we have now), and then a section that allows the website to add whatever it wants. Maybe head it with: "The website says:" and then the actual content will be in a section/paragraph that's shifted to the right (similar to long quotes in books).

    
    

    
  
I've just found this new behaviour and am utterly gob-smacked!

Firefox has now effectively broken a huge number of web applications which use this feature (as already discussed by many people), leaving users confused and increasing the likelihood of data loss.

Our company will have to drop support for Firefox 4, as it damages the user experience in an unacceptable way.  I hope that this change is reverted so that we are able to support 4.1.

(In reply to comment #31)
> The button text change was a usability win but the lack of site-provided text
> is a usability loss. There are many sites that use this in a useful way and
> many intranet sites that use this too.

Exactly correct.

Where is the bug to re-enable this functionality?

    
    

    
  
I just hit this today, too.  This is an unfortunate change and a step back; sites can no longer explain the reason they're confirming a page exit.


(In reply to comment #54)
> Our company will have to drop support for Firefox 4, as it damages the user
> experience in an unacceptable way.  I hope that this change is reverted so that
> we are able to support 4.1.

Yeah, right.  Exaggerating the problem and waving "we won't support Firefox" around like a stick at everything you don't like isn't a winning strategy.

    
    

    
  
> (In reply to comment #54)
> > Our company will have to drop support for Firefox 4, as it damages the user
> > experience in an unacceptable way.  I hope that this change is reverted so 
> > that we are able to support 4.1.
> 
> Yeah, right.  Exaggerating the problem and waving "we won't support Firefox"
> around like a stick at everything you don't like isn't a winning strategy.

It's not a strategy, and it's not an exaggeration.  It's a bald statement of fact.  I run a small IT company, creating web applications, normally hosted on private intranets, and we have just alerted our clients, warning them not to upgrade to Firefox 4 for this and a couple of other reasons.  

We will need to do a proper assessment, of course, but I don't see any advantages to FF4 that directly affect us, so it is likely we will stick with FF3.6 - or else switch to another browser altogether - rather than accept a reduced user experience.  Luckily for us, we mostly operate in controlled environments where we are able to do this.

As I said, this change isn't much of a problem for web *sites*, but is a big Ux regression for web *applications*.

    
    

    
  
This wasn't a very good change, and it should be fixed, but blowing issues out of proportion doesn't convince people.  The sky isn't falling.

    
    

    
  
I think voting to increase the importance of the bug helps more than just argue why or why not use FF4

https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=588292#vote_588292

    
    

    
  
The issue is to revert the change this bug implements, therefore voting doesn't make any sense - unless there were a way to anti-vote.

I would log a bug about reverting the change, which would be a much better place to discuss things, but that has already happened and it was duped to this.

    
    

    
  
IMO, closing bug 643141 as a duplicate of this was an error.

    
    

    
  
I'm glad to see this issue is getting some attention. I've unresolved bug 641509 I created back on March 14. It does a good job of describing what functionality we want back.

    
    

    
  
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Status: RESOLVED → VERIFIED

    
    

    
  
(In reply to comment #51)
> (In reply to comment #49)
> > We use onbeforeunload to tell users to logout from the session for security
> > reasons.
> 
> On onbeforeunload/onunload event is still there, you can write code to
> automatically logout when there is tab/window close. The usecase you mentioned
> really dont need an additional user interaction to logout.

This does not work in situations where you don't know why the window is going away.  In a web application, the user might just be hitting the back button to return to a previous page.  (Not a good thing, but you don't want to force a logout).  Worse, I'm not sure it would work in any situation where you are giving the user an option to remain on the page.  My understanding of onbeforeunload is that once the message is returned that used to be shown to the user, there is no longer an opportunity for code to log the user out if they choose to continue with the attempt to leave/close the page.  You could log them out before showing the message, but then if they choose "Stay on page" their session would be dead.

    
    

    
  
Isn't there still the unload event for actions after beforeunload?

    
    

    
  
(In reply to comment #64)
> Isn't there still the unload event for actions after beforeunload?

window.onunload, window.onpagehide, window.onpageshow all are there 
see attachment 477003 [details]
For more details see https://developer.mozilla.org/en/DOM/window and https://developer.mozilla.org/en/Using_Firefox_1.5_caching
https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history

(In reply to comment #63) and (In reply to comment #49)
If you can provide current code, we can recommend alternative way.
Case where user do history back/forward javascript variable on page are kept old values, that can be used along with onpageshow event to detect history back/forward. Additionally document.referrer and sessionStorage to keep track how user arrived at a page
https://developer.mozilla.org/en/dom/storage#sessionStorage


AS AN END USER, I really wished, we even removed onbeforeunload prompt.
onbeforeunload prompt really traps user at http://tinyurl.com/trap-user
(preview above URL http://preview.tinyurl.com/trap-user )
User unable to do history back to come out of that trap.
He/she has to type about:blank (or other link) at location bar to escape the trap.

    
    

    
  
I have no problems on that page.  (Navigating back redirects right back in, of course, but that's unrelated to beforeunload.)

People shouldn't have to look for alternatives to work around this issue; the issue itself should be fixed.

    
    

    
  
(In reply to comment #66)
> I have no problems on that page.
looks like you went to that URL, when they we not forwarding to problem page. other wise you will hit onbeforeunload dialog.

When you got http://tinyurl.com/trap-user make sure you have automatically forwarded to http://antispyware-pack.co.cc/fast-scan/ and seeing 
"Fast Windows Antivirus 2011" on window title. Then you should see the issue I am talking about

    
    

    
  
No, it went there.  I hit control-F4 to close the tab, it showed a beforeunload dialog, I clicked "leave page" and the tab closed.  I opened it again, pressed back this time, it showed beforeunload, I clicked "leave page" and it went back.  (The page then re-redirected back in, but again, that's unrelated to onbeforeunload.)

In both cases, it behaved correctly.  It would be nicer if the beforeunload prompt was tab-modal (the original report in this ticket, and bug 616853), though.

    
    

    
  
(In reply to comment #68)
> No, it went there.  I hit control-F4 to close the tab
That make me loose Tab history. 
I reached the above URL from google search, 
I really dont want to loose my google search result as well as my cursor position and window scroll position, also normal user action at point is to hit back button than tab close.

> In both cases, it behaved correctly.  It would be nicer if the beforeunload
> prompt was tab-modal (the original report in this ticket, and bug 616853),
> though.

Agree...

    
    

    
  
(In reply to comment #69)
> I really dont want to loose my google search result as well as my cursor
> position and window scroll position, also normal user action at point is to hit
> back button than tab close.

It sounds like you're getting stuck because the previous page is redirecting you.  That has nothing to do with beforeunload.  The page redirection would happen with or without it.  (You can skip back two steps in history, though that was made hard to find in FF4--you have to right-click the back button.)

    
    

    
  
(In reply to comment #70)
> It sounds like you're getting stuck because the previous page is redirecting
> you.  That has nothing to do with beforeunload.  The page redirection would

Yes the previous page is created by same people at http://gvknnfev.cw.cm/
which redirect to http://antispyware-*****.co.cc/fast-scan/

see Bug 648203 comment 2

    
    

    
  
(In reply to comment #54)
> Where is the bug to re-enable this functionality?
Bug 641509

    
  
Depends on: 641509

    
    

    
  
This is an unfortunate change and a step back; sites can no longer explain the reason they're confirming a page exit.
How can we re-enable this function?

    
    

    
  
You should still be able to display a separate alert() before returning from your beforeunload handler. It's not a nice solution but at least it is possible at all.

Other than that, I doubt there's any chance of having that annoyance reverted unless the Mozilla devs decide to do so in a future version.

    
    

    
  
(In reply to comment #74)
> You should still be able to display a separate alert() before returning from
> your beforeunload handler. It's not a nice solution but at least it is
> possible at all.

The problem is, all these people asking for the dialog text to come back aren't the people maintaining the web sites.  They're users.  I'm still dumbfounded by this, as well as the really poor grammar in the replacement dialog!

    
    

    
  
Actually you can alter the DOM before displaying the onbeforeunload dialog, so you can do something like this:

window.onbeforeunload = function()
{
	if ( /Firefox[\/\s](\d+)/.test(navigator.userAgent) && new Number(RegExp.$1) >= 4 )
	{
		var div_unload = document.createElement("div");
		div_unload.innerHTML = "<h1 style='text-align:center'>DON'T LEAVE BEFORE SAVING YOUR WORK!!!</h1><p>You may loose the changes to the following documents:<ul><li>Document 1</li><li>Important document 2</li><li>REALLY important document 3</li></ul></p>";
		div_unload.innerHTML += "<p><small>Unfortunately you are using a recent version of Firefox which disables customizing the text of the unbeforeunlaod dialog, so we suggest you using another browser with this web app.<br />[Chrome Link] [IE9 Link] [Safari Link] [Opera Link]</small></p>";
		document.body.appendChild(div_unload, document.body.firstChild);
	}
	return "You have not saved Document 1, Important document 2 and REALLY important document 3, do you want to leave?";
}

Its not a real solution, but it works.

    
    

    
  
(In reply to comment #44)
> if ( /Firefox[\/\s](\d+)/.test(navigator.userAgent) && new Number(RegExp.$1)
> >= 4 )

Thanks for this little nugget!

Definitely the expression to be used in the event handler itself - to determine whether to display a useful message - along with an apology about the upcoming dialog containing a message that doesn't actually apply but is the place where the decision will have to be made.

Just keeping my fingers crossed that FF doesn't close the gaping alert() security hole as well.   Cluttering up the page markup itself with pre-emptive warnings that aren't necessary in the typical use case (user committing unit of work before ditching) will be even uglier.

(In reply to comment #44)
> if ( /Firefox[\/\s](\d+)/.test(navigator.userAgent) && new Number(RegExp.$1)
> >= 4 )

This is is sick on at least two levels:

*) testing for FF for working around contrived limitations - until recently it was M$ exploder's job to require us to write this kind of code

*) the test is using reverse polarity - should FF developers decide to make it compatible with other browsers and even prior versions once again, it'll be time to push code that bounds the version check, or more likely forget about it an keep apologizing to FF4+ users for the remainder of application's life cycle.

*) it will be a work around in all kinds of applications because someone decided to call it a 'security issue!' (with the exclamation mark, and without an explanation as to why it would be deemed one even after repeated requests for such an explanation following informed rebuttals to the contrary)

Oh well ... time to get my first ever FF workaround off the ground ... probably the first of many given recent security insights.

    
    

    
  
The idea mentioned in comment 76 seems like the right answer for *all* browsers: modify the page DOM if you want to display site messages.  Drop the test for Firefox, and use that to display arbitrary rich content in all browsers, rather than displaying a plain-text string in some of them.

    
    

    
  
Fixing the dependencies of this bug.
No longer depends on: 641509

    
    

    
  
This "fix" is still frustrating for many legitimate sites and webapps when "data you have entered may not be saved" doesn't make sense. Can it be better solved by including the site's message as well as a standard message from firefox? For example:

--------------
This page is asking you to confirm that you want to
leave.

Message from site: [site supplied message]

If you are unsure, click "Leave Page" to safely ignore the site's message and leave.

[ Leave Page ] [ Stay on Page ]
--------------

I'm sure the wording can be improved but you get the idea.

    
    

    
  
I just came around this bug today. It's really a bad decision i think - it lowers the usability of the browser. The web site has to have an opportunity to give the user more then just a generic message.

First of all, if the site is malicious, it already had the chance to fool the user  20 times before coming to the onbeforeupload dialog.

What about sites that need to say something like: "You uploaded your logo but you didnt publish it. Are you sure you want to leave?"

Since the onbeforeunload dialog has the [Leave Page] [Stay on Page] there is no way the malicious app can fool the user to hit the wrong button. If you also add something like:

The site claims: <website text here> then it will be clear for the user that the text provided is not safe.

Please bring the ability to add website message to the dialog!

    
    

    
  
What happened to Firefox?! Can't use it for Enterprise web systems because of this bug / feature!

    
    

    
  
Just adding another one voting for returning the text message back.

    
    

    
  
Assuming that everyone should just use AJAX is a dangerous suggestion. In my case, in any professional projects I do, sure that works fine. But often times I'm required to make tools for in-office use, and they specifically request that I 'dumb down' the code to make it easy for them to make changes in the future without being dependent on one guy who knows the technology.

At the same time, what do you do in cases where the user doesn't want to warn about losing saved data? What if you are warning about a session ending or any other number of things not related to save data?

If we're worried about someone using this feature to confuse users by announcing some sort of virus or some other silly warning, then we might as well shut down the internet - Because that's going to happen regardless of this sort of 'fix'. All you're doing is hampering legitimate usage of this feature because some people might say misleading bad words. This isn't the 90's anymore - We don't need to baby-proof the internet.

    
    

    
  
Would like to add request to fix this "bug" as all other browsers are supporting custom text message.  Other browsers wrap the custom text in the dialog such that it minimizes fooling the user. We develop a popular SaaS service and the custom text is important to our users.

    
    

    
  
I work in the European Commission and due to this issue we will have to remove FF from the supported browsers, it's a pity.

    
    

    
  
(In reply to macs75 from comment #86)
> I work in the European Commission and due to this issue we will have to
> remove FF from the supported browsers, it's a pity.

This is impossible because there is nobody *working* in the European Comission.
(ok, yes, my joke isn't better than your's...)

    
    

    
  
wow, so they are paying me to do nothing? awesome! No wait, this could be the reason they hired me from abroad...
Well if they do not belive me they can check my IP and see I'm just writing from my office there.

    
    

    
  
Neither all sites are in English nor all users understand English! There we need a language specific message.
And there are different cases of usage. Pending AJAX requests, Unsaved forms, or other activities.
So, if you can, at least, provide a language specific message using a new parameter or something, that's alright. Otherwise, let us customize it.

And don't forget that with custom messages, buttons (Stay on page, Leave page) tell the user that what the dialogue will do.

    
    

    
  
This argument doesn't make sense at all. People who do not speak/understand english are very unlikely to use an english browser - and in the localized versions the messages is localized, too.

    
    

    
  
People can use an English browser with basic knowledge. (These GUIs ...) :)

But the point is that, let alone the browser language, the website is based on it's own language; And this is a message from the Web Application, not the browser!
If the browser could handle it automatically, you would be right.

    
    

    
  
As alweys people have short views and think that only about their home environment. 
Not always you have control of the browser installed on the machine you are using, there are a lot of places with international requirenments where you have to support every language available. There are public locations (as turist information centers) where there will be more than one language to be supported...
in these cases this addon could help:
https://addons.mozilla.org/en-US/firefox/addon/quick-locale-switcher/
but I don't know if a site can switch the browser language messages, if this is the requirements maybe is better to look elsewhere where they cares about these problems.

    
    

    
  
Mozilla Devs have already said ""

https://bugzilla.mozilla.org/show_bug.cgi?id=641509#c86

    
    

    
  
Oh great, didn't know the entire page was wrapped in a <form>, I removed me from the CC list while leaving the incomplete message.

Anyway, Mozilla devs have already said:

https://bugzilla.mozilla.org/show_bug.cgi?id=641509#c82

(In reply to Justin Dolske [:Dolske] from comment #82)
> (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 look forward to the day when a developer/company that has enough influence and authority brings attention to this issue. Only then will the devs actually spend some time critically thinking about what they're doing here. The Mozilla devs are wrong on this issue and are sharing the mentality and nearsightedness that Microsoft had in the mid-90's - That is, trying to baby-proof a feature because someone might try to do something bad with it.

I am curious why we are stopping this this particular prompt window though. Why is this one especially chosen?

    
    

    
  
I would like to had my voice to those who want this feature back with site specific messages. 

I work on an application that deals with file uploads and would like to warn the user that a file transfer is still in progress and the generic message is unfortunately and obviously not specific enough to warn my users on why they should stay on the page.

    
    

    
  
To address the UX problem this bug creates for Firefox 4+, you can employ the solution in http://jsfiddle.net/ecmanaut/hQ3AQ/

I will be happy to update that snippet's userAgent regexp with an end-of-range if this bug gets reverted from Firefox again in a future version, which I hope (as Firefox has generally cared for keeping users informed in the past).

    
    

    
  
Adding another vote for returning the custom text, at least in some wrapper like "the web page said...". I really don't understand your reasoning at all; how does this protect the user from anything that can't be done with an alert?

    
    

    
  
(In reply to Andy Harrison from comment #98)
> Adding another vote

1. Please read all comments and read
     https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
   before commenting.

=>

2. You are in the wrong bug here, see comment 72.

3. Voting for a bug in bugzilla means click the 
   "vote" link in the bug's header and add your vote.

    
    

    
  
You firefox devs are a bunch of knobs. You have no concept of how organisations use web applications. Anyone with an once of common sense would have allowed the custom message feature to be switched back on via settings.

It seems now that every time i upgrade firefox some useful functionality has been buggered in some way. Just slowdown and think and get decent community feedback before implementing such destructive changes.

It has to be said IE supersedes firefox in terms of maintaining functional behaviour. I cannot wait for them to address the performance issues.

    
    

    
  
Btw it is because of these retarded changes that this is happening:- 

http://www.techspot.com/news/48404-chrome-ie-market-share-creeps-upward-firefox-losing-ground.html

    
    

    
  
This new feature is killing me.  I need a custom message.  Can we please put this back.

    
    

    
  
Instead just change the text, could you give about option to ignore completely this popup? This is really scam tool.

    
    

    
  
I don't believe why it's so hard to add an about:config option for this. NO scam site could enable it but companies who (think that they) need it can simply enable this when deploying firefox globally.

    
    

    
  
Other browsers provide a much better experience w/ the site-message feature in combination w/ background file uploads. Please revert the exclusion of the site-message.

    
    

    
  
Are there specific examples of where the Chrome / IE / Safari approach has been exploited?

I personally only find it useful to have some context for why the site thinks I should maybe not leave it. It's really quite annoying to have a site popup a "you may lose data" dialog on exit without me having a clue what it's trying to tell me.

+1 for reverting the "fix".

    
    

    
  
As per oyasumi@gmail.com's comment, the fix for this is to create an alert just before showing the unload message - resulting in a double alert:
http://jsfiddle.net/ecmanaut/hQ3AQ/

This is what I'm going to have to do, but in what world is that not more annoying?

Please please please *disable* displaying alerts before the unload message - and INSTEAD allow us to show a message on unload.

    
    

    
  
HEY WTF are u doing? when I  call:
indow.onbeforeunload = onEditorClose;
 function onEditorClose() {
   <xsl:value-of select="concat('var msg = &quot;', i18n:translate('component.mets.editor.close'), '&quot;;')" />
   return confirm(msg);
}

It shows me still 2 **** confirmation-dialogs, Opera, Chrome and even IE are clever enough not to show this **** 2. Dialog, when i leave the Page.

Why u not behaive like ur say on ur pages?

    
    

    
  
If you think that is a bug, then file it. What you are complaining is not related to this bug.

    
    

    
  
Just wanted to jump in here and say that I also think this is a bad feature.  Please let us display custom messages!

    
    

    
  
Add me to the to bring back this functionality.  Don't let the bad guys win, bring back custom messages.

    
    

    
  
(In reply to Dean Tessman from comment #75)
> 
> The problem is, all these people asking for the dialog text to come back
> aren't the people maintaining the web sites.  They're users.  I'm still
> dumbfounded by this, as well as the really poor grammar in the replacement
> dialog!

Web developer here, aka someone "maintaining the web sites". I too want this dialog text to return. I seriously don't understand why having this custom message is considered a bug, it's quite the opposite!

    
    

    
  
Actually the main problem here is that Mozilla devs refuse to add an about:config option for this. There are tons of dom.disable* settings - why not add another one for this?

Then e.g. corporate users could enable it globally and users who prefer to see the text (because they are not stupid and thus won't be tricked by a malicious site) could do so, too.

However, I have the feeling someone's ego is a little bit hurt because people dislike his decision and now he doesn't want to admit it and thus is not willing to revert it (partially).

    
    

    
  
I'd rather this not be a flag. I just wished it would work like other browsers. 

I agree it's an ego / control thing. My favorite Firefox bizarro refusal to do something (drag event mouse coords not being set):

>> The current HTML5 spec describes that all DragEvent properties should be
>> available during all the events - according to editor Ian Hickson.

>Note though that it doesn't specify what the properties should be set to, just 
>that they should be set and we currently set them to 0.

    
    

    
  
I assure you that it has very little to do with ego, and that ad hominem accusations of that nature will get you basically nowhere. :)

    
    

    
  
The last 2.5 years and 100 comments haven't really added any compelling arguments for reverting this, or even just extra useful info. So I'm restricting further comments to this bug, because Bugzilla isn't a forum for complaining -- see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

[Comments are restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]
Restrict Comments: true

    
  
Keywords: csec-spoof, 
          
            sec-want

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: