1234942 - onbeforeunload dialog not shown when immediately pressing back button

Status: VERIFIED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[Matt Cosentino]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20151223030323

Steps to reproduce:

Go to a page with an onbeforeunload handler.
Without interacting with the page at all, click the back button.


Actual results:

You go back to the previous page without a confirmation dialog.


Expected results:

You should have received a confirmation dialog.

Note: If you click the page, move focus away from the window, etc. it will work as expected.

Comment 1

[Felix]

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20151224030228

I can reproduce this behavior with 
 --> Windows 7 x64
			-- Firefox Nightly 46.0a1 (last update 24.12.15)
			-- Firefox Developer Edition 44.0a2 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0)
Example tested: http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_ev_onbeforeunload

Hope this helps to resolve the bug,
Felix

Comment 2

[alex_mayorga]

¡Hola!

I can reproduce this on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20151228030213 CSet: 7c83da46ea740bc14028aca9f9a662f062de5586

Steps:
- Click http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_ev_onbeforeunload
- Press <Backspace>

Actual results:
You go back to the previous page without a confirmation dialog.


Expected results:
You should have received a confirmation dialog.

¡Gracias!

Comment 3

[Kanchan Kumari QA]

Hello Matt, Thanks for reporting this issue. I was able to reproduce this issue on latest nightly build.

Name 	Firefox
Version 	46.0a1
Build ID 	20151228030213	
Update Channel 	nightly
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0

Comment 4

[Boris Zbarsky [:bzbarsky]]

I thought we purposefully avoided firing this event if there were no state changes, to prevent pages from keeping users at the page?  Gijs, do you recall offhand?

Comment 5

[Matt Cosentino]

How could the page keep users from leaving? They can just click "leave page" when the dialog comes up.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> How could the page keep users from leaving?

There are various tricks that people have come up with over the years.  If you just look at the commit history for the code around beforeunload, it has links to many of the relevant bug reports...  

http://hg.mozilla.org/mozilla-central/filelog/0f363ae95dc9/layout/base/nsDocumentViewer.cpp and search for "beforeunload".  

In this case, what you're seeing is the result of the fix for bug 636905, so I did in fact remember correctly.

I guess technically wontfix, since the spec does require firing beforeunload in all cases.  Though I've gone ahead and raised a spec issue at https://github.com/whatwg/html/issues/491 because I doubt we're the only browser moving towards restricting the beforeunload event given how often it's abused.

Comment 7

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] (Vacation until Jan 4) from comment #6)
> > How could the page keep users from leaving?
> 
> There are various tricks that people have come up with over the years.  If
> you just look at the commit history for the code around beforeunload, it has
> links to many of the relevant bug reports...  
> 
> http://hg.mozilla.org/mozilla-central/filelog/0f363ae95dc9/layout/base/
> nsDocumentViewer.cpp and search for "beforeunload".  
> 
> In this case, what you're seeing is the result of the fix for bug 636905, so
> I did in fact remember correctly.

Yup.

> I guess technically wontfix, since the spec does require firing beforeunload
> in all cases.

Just so we're clear, we do still fire the event, I think. To the page it will look like the user just elected to leave, without showing a dialog. While I would like to also not fire the event (because, say, bug 1103323, but there are a number of other annoying things pages sometimes do from the event, independent of the dialog) we do still fire it at this point.

FWIW, I could have sworn that the language of the spec regarding whether or not a dialog had to be shown (and with what message) was more permissive than it currently seems to be (currently says "should"), but I'm not an expert.

>  Though I've gone ahead and raised a spec issue at
> https://github.com/whatwg/html/issues/491 because I doubt we're the only
> browser moving towards restricting the beforeunload event given how often
> it's abused.

Thanks!

Comment 8

[Matt Cosentino]

I see. It's unfortunate that we need to worry about it being abused like that.