+++ This bug was initially created as a clone of Bug #950336 +++ bug 950336 disabled sending a beforeunload event - we shouldn't do that, we should just assume that the result of the dialog is "yes, I really want to leave" without showing that dialog.

Comment on attachment 8532583 [details] [diff] [review] disabling beforeunload should only disable the dialog, not the event, r=me

Since this is a hidden pref, I presume this does not fit for the release notes. user-doc-needed though. dev-doc-needed for onbeforeunload et al. docs to indicate that users can disable the Confirmation dialogue whithout the website being able to distinguish this from user confirming the dialogue.

This just gets worse. As has been discussed elsewhere, some users have very important uses for beforeunload. At the very least, displaying dialogs should be an easily configurable option. They should not be hidden unless the user has agreed to that. But now you plan to impersonate the user. You will pretend to answer a dialog on his/her behalf, so that he/she will not even know they were being asked a question. That's deception. What if the question is "By clicking this button you agree to us charging your credit card $1000"?

(In reply to Ian from comment #6) > This just gets worse. > As has been discussed elsewhere, some users have very important uses for > beforeunload. > At the very least, displaying dialogs should be an easily configurable > option. > They should not be hidden unless the user has agreed to that. It sounds like you don't really understand this change. Nothing has changed by default - the user would need to go and change this pref manually in about:config - we don't currently plan to make it visible in the preferences UI. I repeat, we've made an option available, and we've not changed the default in any way. If a website wants to do something evil when you leave, they can already do that - why wait until you leave? The behaviour that this pref enables is already implemented on several mobile browsers, I believe - they never show a dialog to the user (I think Firefox on Android still does, by default - this patch doesn't change that, either). I actually don't think that user- or dev-doc'ing this is necessary - the previous behaviour of the pref was implemented for Firefox 29, and we didn't do any documentation then. It's unclear to me why that need suddenly change. Florian, I'm removing those keywords, feel free to convince me otherwise.

(In reply to :Gijs Kruitbosch from comment #7) > I actually don't think that user- or dev-doc'ing this is necessary - the > previous behaviour of the pref was implemented for Firefox 29, and we didn't > do any documentation then. It's unclear to me why that need suddenly change. > Florian, I'm removing those keywords, feel free to convince me otherwise. I believe there is a doc for the beforeunload prompt. A doc should mention that this dialogue can be disabled and in this case the prompt will return immediately as if the user confirmed the dialogue.

(In reply to Florian Bender from comment #8) > (In reply to :Gijs Kruitbosch from comment #7) > > I actually don't think that user- or dev-doc'ing this is necessary - the > > previous behaviour of the pref was implemented for Firefox 29, and we didn't > > do any documentation then. It's unclear to me why that need suddenly change. > > Florian, I'm removing those keywords, feel free to convince me otherwise. > > I believe there is a doc for the beforeunload prompt. A doc should mention > that this dialogue can be disabled and in this case the prompt will return > immediately as if the user confirmed the dialogue. I've updated https://developer.mozilla.org/en-US/docs/Web/Events/beforeunload and https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers.onbeforeunload (I don't really know why we have both, but whatever)

Hi all, I don't seam to understand this change, can someone shed some light? What is the purpose of firing the trigger without displaying the alert? I ask because some sites / banners are able to launch a new tab when this event is triggered. Thanks, Marco

> What is the purpose of firing the trigger without displaying the alert? Pages commonly use beforeunload for various things like saving data, analytics, etc, that should be performed no matter what. > I ask because some sites / banners are able to launch a new tab If you have a link to such a site, please file a bug on it and cc me. It should not be possible to open a new tab from beforeunload, and if there is a way to do that we should fix it.

I will see if I can figure it out tonight, It happened with my dad last night. Some f###ing banner, I suppose, opened a new tab with a "police warning" advising to pay a "fine" or face jail. It scared the **** of him, he called me, and when I got there had to close several tabs. One thing I noticed was if I used ctrl+f4 to close the tab it would ask me before closing, but didnd't open a new tab, but if I clicked the "x" to close the tab, it would remain open, asking to save, and open a new tab. When I got to the computer there where some 10 different tabs with the same thing.

That really doesn't sound related to this bug in any way, unless your dad has the "dom.disable_beforeunload" preference set to the non-default value "true". That's the situation this bug was about. If your dad was seeing the "asking to save" prompt at all, that means he didn't have that preference setting. Please do file a separate bug as needed!

Marco: the description of that page and its behaviour (related to focus, ie clicking the close button will trigger a blur event, but ctrl-f4 won't) sounds like bug 1116977, which we fixed for Firefox 37.

Thank you for your help. I will try to bookmark (pen + paper :) the site tonight and see if it is fixed when 37 comes out. If it doesn't, I will submit a new bug. Thank you, Marco

(In reply to Marco Marujo from comment #15) > Thank you for your help. > > I will try to bookmark (pen + paper :) the site tonight and see if it is > fixed when 37 comes out. > > If it doesn't, I will submit a new bug. Thank you! You can even "just" test the latest beta builds: https://beta.mozilla.org/ . Might be easier than "bookmarking" manually. All this is assuming the site is still up, IME (from fixing the issue and needing testcases...) they find new places to hide every so often...