This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25002 - Event.returnValue
Summary: Event.returnValue
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-11 03:13 UTC by Philip Jägenstedt
Modified: 2016-09-27 13:35 UTC (History)
12 users (show)

See Also:
bugs: needinfo? (jrossi)


Attachments

Description Philip Jägenstedt 2014-03-11 03:13:01 UTC
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2878

Implemented in WebKit/Blink, documented as an IE extension, although IE11 no longer supports it.

Usage is ridiculously high:
http://www.chromestatus.com/metrics/feature/timeline/popularity/137

Cost of support is low:
bool legacyReturnValue() const { return !defaultPrevented(); }
void setLegacyReturnValue(bool returnValue) { setDefaultPrevented(!returnValue); }

Consider spec'ing this?
Comment 1 Jonas Sicking (Not reading bugmail) 2014-03-11 03:19:50 UTC
I think the cost in terms of developer mindshare is higher. I.e. it's yet another API that developers will come across when looking at other's code, and that they'll have to figure out how it works. And it's yet another thing to grep for when looking for usage of particular APIs in your own code.

Seems strange that IE is dropping it if usage is so high? Do developers fallback to the currently standardized API?

That said, I don't feel terribly strongly.
Comment 2 Boris Zbarsky 2014-03-11 03:42:37 UTC
> Do developers fallback to the currently standardized API?

Yes.  

For example, here's jQuery:

 this.isDefaultPrevented = (src.defaultPrevented || 
                            src.returnValue === false ||
                            src.getPreventDefault && src.getPreventDefault() ) ?
     returnTrue : returnFalse;

Note that any event coming through here that has not had preventDefault() called on it will trigger a use counter for "Event.returnValue", which would on its own explain the use counter values Chrome is seeing.  But of course this code works just fine in a browser which has no returnValue support.

I would be a lot more interested in a use counter that only counted returnValue accesses when the event has in fact had preventDefault() called on it.  That is, when the attribute would return false.  That would at bare minimum exclude jQuery from completely swamping all other data.

Also note that BeforeUnloadEvent has a returnValue property with somewhat different semantics (it's a string for one thing), which makes actual use of returnValue a bit complicated (e.g. really do need to use !== and === on it, unless you know you have some other event type).

> That said, I don't feel terribly strongly.

I do.  Gecko and IE not supporting it shows it's not needed for web compat, and I think the confusion from having returnValue on different events mean different things is pretty significant.
Comment 3 Philip Jägenstedt 2014-03-11 07:40:19 UTC
OK, we need to figure out a better way of measuring this in Blink to determine if it can be removed or not. It seems likely that there would be old IE-specific content or newish WebKit-specific content that depends on it, but we'll see.

Anne, I'll leave it to you to close this bug after you've read this.
Comment 4 Anne 2014-03-17 18:10:29 UTC
Philip, note that HTML defines BeforeUnloadEvent which does have a returnValue and which Gecko does implement. Given that only Chrome and WebKit do this I'm going with WONTFIX for now.
Comment 5 Chris Rebert 2016-04-09 21:00:10 UTC
Looks like MS Edge has re-added support for returnValue.
Comment 6 Anne 2016-04-11 16:35:38 UTC
Olli, this seems like another Event extension everyone else implements. I'm inclined to just define it given that Edge added it per the definition given in comment 0. And I guess BeforeUnloadEvent can just define its own version as it already does.
Comment 7 Domenic Denicola 2016-04-11 16:59:41 UTC
> And I guess BeforeUnloadEvent can just define its own version as it already does.

Hmm, I wonder if we could just remove BeforeUnloadEvent? The difference would be that currently `unloadEv.returnValue = { toString() { return ""; } }` does not prevent default, but if we removed BeforeUnloadEvent, it would. But `unloadEv.returnValue = "any non empty string"` and `unloadEv.returnValue = ""` would have the same behavior.

I guess reading `unloadEv.returnValue` after setting it would change behavior.

---

Re-reading the thread though, it seems nicer not to spec this. Did Edge encounter pages that were depending on it, on the mobile web? +Travis and Mike Taylor for compat questions.
Comment 8 Olli Pettay 2016-04-11 17:04:26 UTC
jrossi, any idea why Edge added the support back?
Comment 9 Anne 2016-08-17 12:14:24 UTC
Olli, does it matter why they added back support? It's all browsers versus Firefox at this point. Unless Philip can be convinced to remove it from Chrome but that seems highly unlikely given the usage chart...
Comment 10 Olli Pettay 2016-08-17 12:19:33 UTC
If we add return value, we probably should add rest of the event handling's IEisms.
(sad that browser vendors aren't interested in cleaning up the messy platform)
Comment 11 Anne 2016-09-27 13:35:14 UTC
Now discussing this here together with other Microsoft extensions as requested: https://github.com/whatwg/dom/issues/334.