This is the more important part, and support for 'passive' can be added later.

In this patch I'm not implementing "passive" nor "once".

Comment on attachment 8745144 [details] [diff] [review] event.patch Not enough information about this bug in comment 0. Redirecting this review to smaug...

yeah, I can take a look given that I was fighting against this syntax, but failed :/

Or maybe you prefer to have the dictionary propagated up to the EventListenerManager...

Comment on attachment 8745144 [details] [diff] [review] event.patch >+dictionary EventListenerOptions { >+ boolean capture = false; >+}; >+ >+dictionary AddEventListenerOptions : EventListenerOptions { >+ boolean passive = false; >+ boolean once = false; Could you actually comment the properties we don't support out. That way one can do feature testing by having a getter for the property and making it to throw. If exception is thrown, property is supported in the dictionary. To ease future patches we can still leave AddEventListenerOptions, even though it becomes just empty dictionary inheriting EventListenerOptions

Comment on attachment 8745164 [details] [diff] [review] event2.patch >+EventListenerManager::RemoveEventListener( >+ const nsAString& aType, >+ const EventListenerHolder& aListenerHolder, >+ const dom::EventListenerOptionsOrBoolean& aOptions) >+{ >+ EventListenerFlags flags; >+ flags.mCapture = >+ aOptions.IsBoolean() ? aOptions.GetAsBoolean() >+ : aOptions.GetAsEventListenerOptions().mCapture; >+ RemoveEventListenerByType(aListenerHolder, aType, flags); >+} I guess this is better than calling the RemoveEventListener above, since we'll need to set other flags once we support passive and once. So, we need some tests too, wpt tests hopefully.

> So, we need some tests too, wpt tests hopefully. I and smaug tested it locally.

and wpt tests are coming from blink folks hopefully later this week.

[Tracking Requested - why for this release]: We should backport this to ESR so that once websites start to use this API, they will still work fine on ESR even if they don't feature detect it properly.

[Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: User impact if declined: If this optional parameter is used, ESR45 will not be able to handle it. This patch is for web compat. Fix Landed on Version: 49. Risk to taking this patch (and alternatives if risky): not really. The patch is quite simple. String or UUID changes made by this patch: none. See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Sylvestre, do you know who handles ESR approvals? This has been waiting for a month now... Thanks!

Comment on attachment 8745881 [details] [diff] [review] esr-45 Improve the ESR status. Sorry about the delay, we start dealing with esr uplifts usually at this time in the beta cycle.

I guess 47 & 48 are fixed somewhere else, right?

Updated: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener and https://developer.mozilla.org/en-US/Firefox/Releases/49#DOM_HTML_DOM