Last Comment Bug 588292 - Remove site-supplied text for beforeunload and onunload dialogs, and improve button text
: Remove site-supplied text for beforeunload and onunload dialogs, and improve ...
Status: VERIFIED FIXED
[strings]
: csectype-spoof, sec-want
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: All All
: -- normal with 7 votes (vote)
: mozilla2.0b7
Assigned To: Justin Dolske [:Dolske]
:
Mentors:
: 246365 369608 542229 586907 (view as bug list)
Depends on: 315415 391834 562258
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-17 22:03 PDT by Alex Faaborg [:faaborg] (Firefox UX)
Modified: 2014-01-09 06:20 PST (History)
58 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta7+


Attachments
Testcase (83 bytes, text/html)
2010-09-14 18:39 PDT, Justin Dolske [:Dolske]
no flags Details
Screenshot (current dialog) (59.04 KB, image/png)
2010-09-14 18:40 PDT, Justin Dolske [:Dolske]
no flags Details
Patch v.1 (6.24 KB, patch)
2010-09-14 22:56 PDT, Justin Dolske [:Dolske]
jst: review+
limi: ui‑review+
Details | Diff | Splinter Review
Screenshot (patch v.1 + OS X) (54.65 KB, image/png)
2010-09-14 22:58 PDT, Justin Dolske [:Dolske]
no flags Details
Screenshot (patch v.1 + Win7) (49.37 KB, image/png)
2010-09-15 00:28 PDT, Justin Dolske [:Dolske]
no flags Details
Patch v.2 (4.98 KB, patch)
2010-09-15 14:03 PDT, Justin Dolske [:Dolske]
no flags Details | Diff | Splinter Review
onunload.html (205 bytes, text/html)
2010-09-20 19:24 PDT, Biju
no flags Details

Description Alex Faaborg [:faaborg] (Firefox UX) 2010-08-17 22:03:03 PDT
Similar to bug 562258 which covers javascript dialogs, we need to make sure that beforeunload and onunload dialogs are tab modal panels as well.
Comment 1 Alex Limi (:limi) — Firefox UX Team 2010-08-30 15:33:13 PDT
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"
Comment 2 Alex Limi (:limi) — Firefox UX Team 2010-09-14 16:09:05 PDT
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.
Comment 3 Justin Dolske [:Dolske] 2010-09-14 18:39:25 PDT
Created attachment 475379 [details]
Testcase

Trivial testcase that triggers this dialog.
Comment 4 Justin Dolske [:Dolske] 2010-09-14 18:40:11 PDT
Created attachment 475380 [details]
Screenshot (current dialog)
Comment 5 Justin Dolske [:Dolske] 2010-09-14 22:56:59 PDT
Created attachment 475426 [details] [diff] [review]
Patch v.1

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).
Comment 6 Justin Dolske [:Dolske] 2010-09-14 22:58:16 PDT
Created attachment 475427 [details]
Screenshot (patch v.1 + OS X)

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.
Comment 7 Justin Dolske [:Dolske] 2010-09-15 00:28:02 PDT
Created attachment 475443 [details]
Screenshot (patch v.1 + Win7)
Comment 8 Alex Limi (:limi) — Firefox UX Team 2010-09-15 00:33:30 PDT
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!
Comment 9 Alex Faaborg [:faaborg] (Firefox UX) 2010-09-15 02:55:10 PDT
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.
Comment 10 Dean Tessman 2010-09-15 07:05:55 PDT
Also "Leave this page?" is bordering on being a fragment.
Comment 11 Justin Dolske [:Dolske] 2010-09-15 14:03:45 PDT
Created attachment 475625 [details] [diff] [review]
Patch v.2

Tweaked strings per previous comments and on IRC with Limi.
Comment 12 Justin Dolske [:Dolske] 2010-09-15 14:05:17 PDT
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).
Comment 13 Justin Dolske [:Dolske] 2010-09-15 14:41:33 PDT
Comment on attachment 475625 [details] [diff] [review]
Patch v.2

Actually, beltzner wants to take another stabs at these strings.
Comment 14 Mike Beltzner [:beltzner, not reading bugmail] 2010-09-15 21:35:36 PDT
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)
Comment 15 Justin Dolske [:Dolske] 2010-09-16 00:53:25 PDT
Pushed http://hg.mozilla.org/mozilla-central/rev/03ef56304b2d

(with beltzner's strings)
Comment 16 Reed Loden [:reed] (use needinfo?) 2010-09-16 11:46:30 PDT
(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?
Comment 17 Reed Loden [:reed] (use needinfo?) 2010-09-16 11:48:27 PDT
(In reply to comment #16)
> Should use a double hyphen, no?

Em dash, I mean.
Comment 18 Mike Beltzner [:beltzner, not reading bugmail] 2010-09-17 07:38:20 PDT
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.
Comment 19 Sylvain Pasche 2010-09-17 07:43:19 PDT
*** Bug 246365 has been marked as a duplicate of this bug. ***
Comment 20 Biju 2010-09-20 19:17:45 PDT
Hi all, please see bug 315415
What should be the expected behaviour there?
Comment 21 Biju 2010-09-20 19:24:09 PDT
Created attachment 477003 [details]
onunload.html

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
Comment 22 Biju 2010-09-20 19:40:07 PDT
*** Bug 586907 has been marked as a duplicate of this bug. ***
Comment 23 Biju 2010-09-20 19:45:27 PDT
*** Bug 369608 has been marked as a duplicate of this bug. ***
Comment 24 Biju 2010-09-20 19:59:32 PDT
*** Bug 542229 has been marked as a duplicate of this bug. ***
Comment 25 Dean Tessman 2010-09-21 10:30:36 PDT
(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.
Comment 26 Benjamin Penney 2010-09-25 18:23:45 PDT
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?
Comment 27 Shelby Moore 2010-09-26 11:24:41 PDT
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.
Comment 28 Shelby Moore 2010-09-26 11:27:42 PDT
Correction:

Title Bar: Confirm Navigation
[site supplied message]
[ Leave this Page ] [ Stay on this Page ]
Comment 29 Shelby Moore 2010-09-26 16:24:21 PDT
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 - [...]".
Comment 30 Scott D 2010-12-16 20:32:30 PST
*** Bug 619857 has been marked as a duplicate of this bug. ***
Comment 31 Daniel Cater 2010-12-28 15:01:43 PST
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.
Comment 32 Biju 2010-12-29 18:33:44 PST
(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.
Comment 33 Biju 2011-01-01 14:40:44 PST
(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.
Comment 34 Daniel Cater 2011-01-02 16:41:43 PST
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).
Comment 35 Daniel Cater 2011-01-02 16:47:05 PST
(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".
Comment 36 Shelby Moore 2011-01-02 16:54:26 PST
(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.
Comment 37 Alex Limi (:limi) — Firefox UX Team 2011-01-04 12:28:18 PST
(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.
Comment 38 Shelby Moore 2011-01-07 15:52:35 PST
(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.
Comment 39 Shelby Moore 2011-01-07 15:59:59 PST
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.
Comment 40 Shelby Moore 2011-01-07 16:23:07 PST
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.
Comment 41 Justin Dolske [:Dolske] 2011-01-07 18:12:30 PST
(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.
Comment 42 Shelby Moore 2011-01-11 13:29:31 PST
(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
Comment 43 Shelby Moore 2011-01-11 15:14:53 PST
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.
Comment 44 Aldonio 2011-02-08 12:52:52 PST
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>";
}
Comment 45 Shelby Moore 2011-02-08 13:48:58 PST
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.
Comment 46 Yves Goergen 2011-02-27 06:07:48 PST
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.
Comment 47 Casper van Dijk 2011-03-10 05:04:01 PST
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..
Comment 48 Ben 2011-03-14 08:34:53 PDT
*** Bug 641509 has been marked as a duplicate of this bug. ***
Comment 49 sumeet.muju 2011-03-17 13:04:14 PDT
(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.
Comment 50 Alice0775 White 2011-03-19 09:22:18 PDT
*** Bug 643141 has been marked as a duplicate of this bug. ***
Comment 51 Biju 2011-03-19 21:06:31 PDT
(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.
Comment 52 Adrian 2011-03-22 15:52:57 PDT
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...
Comment 53 Geobio 2011-03-28 23:26:31 PDT
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).
Comment 54 Mark Clements 2011-03-30 19:18:37 PDT
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?
Comment 55 Glenn Maynard 2011-04-01 10:58:02 PDT
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.
Comment 56 Mark Clements 2011-04-01 12:05:03 PDT
> (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*.
Comment 57 Glenn Maynard 2011-04-01 14:49:52 PDT
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.
Comment 58 Aldonio 2011-04-01 15:04:27 PDT
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
Comment 59 Mark Clements 2011-04-01 15:45:12 PDT
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.
Comment 60 Glenn Maynard 2011-04-01 15:52:08 PDT
IMO, closing bug 643141 as a duplicate of this was an error.
Comment 61 Ben 2011-04-01 16:20:01 PDT
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.
Comment 62 George Carstoiu 2011-04-04 08:49:59 PDT
Verified with Mozilla/5.0 (X11; Linux i686; rv:2.2a1pre) Gecko/20110404 Firefox/4.2a1pre
Comment 63 Paul Lynch 2011-04-04 10:50:46 PDT
(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.
Comment 64 Yves Goergen 2011-04-04 11:42:40 PDT
Isn't there still the unload event for actions after beforeunload?
Comment 65 Biju 2011-04-05 22:48:59 PDT
(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.
Comment 66 Glenn Maynard 2011-04-05 23:33:12 PDT
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.
Comment 67 Biju 2011-04-06 21:46:11 PDT
(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
Comment 68 Glenn Maynard 2011-04-06 22:23:30 PDT
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.
Comment 69 Biju 2011-04-06 22:58:30 PDT
(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...
Comment 70 Glenn Maynard 2011-04-06 23:34:06 PDT
(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.)
Comment 71 Biju 2011-04-06 23:47:44 PDT
(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
Comment 72 j.j. 2011-04-22 16:20:02 PDT
(In reply to comment #54)
> Where is the bug to re-enable this functionality?
Bug 641509
Comment 73 Wim Michiels 2011-06-16 03:47:10 PDT
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?
Comment 74 Yves Goergen 2011-06-16 03:53:43 PDT
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.
Comment 75 Dean Tessman 2011-06-17 13:23:45 PDT
(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!
Comment 76 Aldonio 2011-06-22 17:58:19 PDT
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.
Comment 77 Patrick Schweiger 2011-07-12 15:12:07 PDT
(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.
Comment 78 Josh Triplett 2011-08-26 11:22:56 PDT
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.
Comment 79 Josh Triplett 2011-08-26 11:24:47 PDT
Fixing the dependencies of this bug.
Comment 80 Sam 2011-10-19 17:14:38 PDT
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.
Comment 81 Nico 2011-11-05 17:48:10 PDT
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!
Comment 82 manny 2012-02-01 01:56:52 PST
What happened to Firefox?! Can't use it for Enterprise web systems because of this bug / feature!
Comment 83 Glutexo 2012-02-06 04:28:00 PST
Just adding another one voting for returning the text message back.
Comment 84 David B. 2012-02-14 08:36:22 PST
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.
Comment 85 Dennis Mulryan 2012-03-27 13:18:29 PDT
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.
Comment 86 macs75 2012-04-18 02:34:37 PDT
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.
Comment 87 j.j. 2012-04-18 04:56:14 PDT
(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...)
Comment 88 macs75 2012-04-18 05:06:27 PDT
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.
Comment 89 sam.designe 2012-04-21 22:47:51 PDT
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.
Comment 90 Adrian 2012-04-22 01:05:21 PDT
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.
Comment 91 sam.designe 2012-04-22 02:51:42 PDT
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.
Comment 92 macs75 2012-04-22 03:17:49 PDT
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.
Comment 93 Aldonio 2012-04-22 10:20:27 PDT
Mozilla Devs have already said ""

https://bugzilla.mozilla.org/show_bug.cgi?id=641509#c86
Comment 94 Aldonio 2012-04-22 10:23:14 PDT
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.
Comment 95 David B. 2012-04-22 11:36:59 PDT
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?
Comment 96 D.Paquin 2012-05-02 12:42:10 PDT
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.
Comment 97 oyasumi 2012-05-23 13:07:38 PDT
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).
Comment 98 Andy Harrison 2012-06-14 06:14:58 PDT
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?
Comment 99 j.j. 2012-06-14 12:45:26 PDT
(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.
Comment 100 HanSolo 2012-07-17 23:41:00 PDT
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.
Comment 101 HanSolo 2012-07-17 23:52:08 PDT
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
Comment 102 Mark DeMichele 2012-07-23 15:16:38 PDT
This new feature is killing me.  I need a custom message.  Can we please put this back.
Comment 103 teixeiras 2012-08-02 03:04:50 PDT
Instead just change the text, could you give about option to ignore completely this popup? This is really scam tool.
Comment 104 Adrian 2012-08-14 06:06:19 PDT
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.
Comment 105 Russ 2012-12-13 14:09:14 PST
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.
Comment 106 Robin Winslow 2013-02-15 03:54:40 PST
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".
Comment 107 Robin Winslow 2013-02-15 04:12:14 PST
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.
Comment 108 Basti890 2013-03-04 00:45:23 PST
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?
Comment 109 brunoais 2013-03-04 01:03:12 PST
If you think that is a bug, then file it. What you are complaining is not related to this bug.
Comment 110 Abe Miessler 2013-04-26 10:40:34 PDT
Just wanted to jump in here and say that I also think this is a bad feature.  Please let us display custom messages!
Comment 111 Matt Johnston 2013-04-26 14:08:16 PDT
Add me to the to bring back this functionality.  Don't let the bad guys win, bring back custom messages.
Comment 112 Ugoku 2013-05-02 01:00:13 PDT
(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!
Comment 113 Adrian 2013-05-02 01:09:21 PDT
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).
Comment 114 Russ 2013-05-02 08:56:41 PDT
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.
Comment 115 Mike Beltzner [:beltzner, not reading bugmail] 2013-05-02 13:36:45 PDT
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. :)
Comment 116 Justin Dolske [:Dolske] 2013-05-02 16:43:35 PDT
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.]

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