[Bug 25002] Event.returnValue

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25002

Boris Zbarsky <bzbarsky@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bzbarsky@mit.edu

--- Comment #2 from Boris Zbarsky <bzbarsky@mit.edu> ---
> 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 11 March 2014 03:42:38 UTC