This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
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.
> 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.
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.
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.
Looks like MS Edge has re-added support for returnValue.
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.
> 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.
jrossi, any idea why Edge added the support back?
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...
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)
Now discussing this here together with other Microsoft extensions as requested: https://github.com/whatwg/dom/issues/334.