1401552 - (on)beforeunload empty string for returnValue ignored

Status: RESOLVED INVALID

(Core :: DOM: Events, defect)

Description

[Harald van Dijk]

Attachment: test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

Open the attached file. Close the tab or window.


Actual results:

The tab or window closes without any prompt.


Expected results:

Firefox should have shown its regular "This page is asking you to confirm that you want to leave - data you have entered may not be saved." prompt.

The docs <https://developer.mozilla.org/en-US/docs/Web/Events/beforeunload> read:

> If a string is assigned to the returnValue Event property, a dialog appears asking the user for confirmation to leave the page (see example below). [...]

The same thing happens when setting it from an onbeforeunload handler, for which the docs <https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload> read:

> When this event returns (or sets the returnValue property to) a value other than null or undefined, the user is prompted to confirm the page unload. [...]

There is no mention of any special behaviour for empty strings, and Chrome, MSIE and Edge do show a confirmation dialog for this test file, and also show a confirmation dialog when modifying it to set returnValue from an onbeforeunload handler.

Note that returning an empty string from the onbeforeunload handler *does* cause the prompt to be displayed. It's only ignored on the returnValue property.

Comment 1

[Andrew Overholt [:overholt]]

Mike, did we make recent changes to this to speed up tab closing in certain cases?

Comment 2

[Andrew Overholt [:overholt]]

https://bugzilla.mozilla.org/attachment.cgi?id=8910283 asks for confirmation in both Edge and Chrome but not in Firefox 55 or Nightly (57).

Comment 3

[Thomas Wisniewski]

I noticed that the testcase works with a non-E10S window, but otherwise doesn't work for me all the way back to a Jan.2016 nightly build, so I don't think it's something recent.

I also tried mozregression, but I'm not sure if the range it gave is useful: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2387ada864282880d3a498d643abe3d8b887ee59&tochange=e193b4da0a8c1025aa76a403c64663ff1cd41709

Comment 4

[Mike Conley (:mconley) (:⚙️)]

(In reply to Andrew Overholt [:overholt] from comment #1)
> Mike, did we make recent changes to this to speed up tab closing in certain
> cases?

I think the difference is bug 636905. The user must interact with the page before we'll consider showing the beforeunload dialog.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #4)
> (In reply to Andrew Overholt [:overholt] from comment #1)
> > Mike, did we make recent changes to this to speed up tab closing in certain
> > cases?
> 
> I think the difference is bug 636905. The user must interact with the page
> before we'll consider showing the beforeunload dialog.

(In reply to Andrew Overholt [:overholt] from comment #2)
> https://bugzilla.mozilla.org/attachment.cgi?id=8910283 asks for confirmation
> in both Edge and Chrome but not in Firefox 55 or Nightly (57).

FWIW, if I didn't interact with the page before, neither Firefox nightly 57 or chrome on OSX shows a prompt. If I interacted with the page before closing, both showed a prompt. 

Are we going to change the behaviour as the current behaviour is as expected as design in bug 636905? I guess not ...

Comment 6

[Harald van Dijk]

Attachment: test.html

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #5)
> (In reply to Andrew Overholt [:overholt] from comment #2)
> > https://bugzilla.mozilla.org/attachment.cgi?id=8910283 asks for confirmation
> > in both Edge and Chrome but not in Firefox 55 or Nightly (57).
> 
> FWIW, if I didn't interact with the page before, neither Firefox nightly 57
> or chrome on OSX shows a prompt. If I interacted with the page before
> closing, both showed a prompt. 

Apologies, I see now that I ended up attaching the wrong test case. It does not match the description of my bug report, it only partially covers the last sentence where I described the part that *was* working.

Here's the corrected test case. In Firefox, it does not prompt, regardless of whether I interact with the page before closing. In Chrome and Edge, it does prompt.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Okay, yes, I can reproduce now. This doesn't appear to be a new behaviour, fwiw - we've done this since (at least) mid-2014.

Here's the BeforeUnloadEvent spec from WHATWG:

https://html.spec.whatwg.org/multipage/browsing-the-web.html#the-beforeunloadevent-interface

(emphasis mine)

"The BeforeUnloadEvent interface is a legacy interface which allows prompting to unload to be controlled not only by canceling the event, but by setting the returnValue attribute to _a value besides the empty string_. Authors should use the preventDefault() method, or other means of canceling events, instead of using returnValue.

The returnValue attribute controls the process of prompting to unload. When the event is created, the attribute must be set to the empty string. On getting, it must return the last value it was set to. On setting, the attribute must be set to the new value."

So I _think_ we're operating according to spec here, and the other browsers aren't.

Does that sound like a proper read, hsinyi?

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #7)
> Okay, yes, I can reproduce now. This doesn't appear to be a new behaviour,
> fwiw - we've done this since (at least) mid-2014.
> 
> Here's the BeforeUnloadEvent spec from WHATWG:
> 
> https://html.spec.whatwg.org/multipage/browsing-the-web.html#the-
> beforeunloadevent-interface
> 
> (emphasis mine)
> 
> "The BeforeUnloadEvent interface is a legacy interface which allows
> prompting to unload to be controlled not only by canceling the event, but by
> setting the returnValue attribute to _a value besides the empty string_.
> Authors should use the preventDefault() method, or other means of canceling
> events, instead of using returnValue.
> 
> The returnValue attribute controls the process of prompting to unload. When
> the event is created, the attribute must be set to the empty string. On
> getting, it must return the last value it was set to. On setting, the
> attribute must be set to the new value."
> 
> So I _think_ we're operating according to spec here, and the other browsers
> aren't.
> 
> Does that sound like a proper read, hsinyi?

Yup, I read the spec and shared the same opinion with Mike that we're operating according to spec here. I tend to think we close this as invalid.

Dear reporter, thanks for reporting! I'd like to encourage you to file a spec issue for further discussion if you think the spec behaviour should be changed.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Thanks, hsinyi.

I'm going to close this as INVALID. Harald, please feel free to re-open if you feel we've missed something in our analysis.

Comment 10

[Harald van Dijk]

Agreed, the Firefox behaviour matches the spec, thanks for the explanation. I believe that does mean the MDN documentation I linked to is incorrect and should be fixed, but as I understand it, Bugzilla is the wrong place for bringing attention to that, so nothing more to do here.