StructuredCloneTester objects can configured to be serializable (or not) and
deserializable (or not) by the structured clone algorithm. They can be used to
test, for example, onmessageerror event handlers, where the messageerror event
is fired when a message fails to be deserialized (but was successfully serialized).
The class is pref'ed with "dom.testing.structuredclonetester.enabled".
Differential Revision: https://phabricator.services.mozilla.com/D5207
--HG--
extra : moz-landing-system : lando
This partially backs out bug 1471165 now that we don't enforce a default value
for dictionary-typed members of dictionaries.
Differential Revision: https://phabricator.services.mozilla.com/D6876
--HG--
rename : testing/web-platform/meta/media-capabilities/decodingInfo.html.ini => testing/web-platform/meta/media-capabilities/encodingInfo.html.ini
rename : testing/web-platform/tests/media-capabilities/decodingInfo.html => testing/web-platform/tests/media-capabilities/encodingInfo.html
extra : moz-landing-system : lando
Add the first version of the IPDL-JS API, which allow chrome JS to load IPDL files and use them to communicate accross Content processes.
See IPDLProtocol.h for more information regarding how to use the API.
Differential Revision: https://phabricator.services.mozilla.com/D2116
--HG--
rename : ipc/moz.build => ipc/ipdl_new/moz.build
extra : moz-landing-system : lando
Some steps in file_fullscreen-api.html are adjusted in order to test
the behavior that the event is correctly dispatched to the document
when element is disconnected.
Depends on D5415
Differential Revision: https://phabricator.services.mozilla.com/D5416
--HG--
extra : moz-landing-system : lando
To support merchants providing the payment details with errors by
PaymentRequestUpdateEvent.updateWith() during PaymentResponse.retry(),
PaymentDetailsUpdate needs to add more two attributes in webidl.
dictionary PaymentDetailsUpdate {
...
PayerErrorFields payerErrors;
object paymentMethodErrors;
};
And transfer these error field to UI component
1. Add PaymentValidationErrors and PayerErrorFields in PaymentRequest.webidl
and PaymentResponse.retry() in PaymentResponse.webidl
2. Implement PaymentRequest.retryPayment() and
PaymentRequestManager.retryPayment() in content process.
3. Add IPCPaymentRetryActionRequest in PPaymentRequest.ipdl to transfer the
error fields to chrome process.
4. Implement PaymentResponse.retry() by reusing the code of show() and
updateWith() of PaymentRequestService in chrome process.
Streams have multiple parts that can be JS objects from different compartments.
For example, the [[reader]] internal slot of a stream can point to a reader
object in another compartment.
This patch makes the ReadableStream implementation robust against mixing and
matching stream-related objects and methods from different globals.
This also removes ReadableStreamBYOBReader and ReadableStreamBYOBRequest for
now, with a view toward enabling basic ReadableStream features by default in
bug 1389628.
Differential Revision: https://phabricator.services.mozilla.com/D8450
--HG--
extra : rebase_source : 71d73bed5bc82557efcb6b1ecb231275fd3e1189
extra : amend_source : de29f663b9929eb2858b23cc6f4e7ba97b23a28c
extra : source : f91eb962df6a06d5f51ad13caa2a4a9c2947f293
Summary:
DocumentL10n is a DOM C++ API which serves as a bridge between
nsIDocument and mozDOMLocalization APIs.
MozReview-Commit-ID: 8LfOR4Haqlu
Reviewers: smaug
Reviewed By: smaug
Subscribers: mossop, smaug
Bug #: 1455649
Differential Revision: https://phabricator.services.mozilla.com/D2904
--HG--
extra : rebase_source : f57f363532ecc3456fb9ada734bda5b63b5ba511
While trying to repro bug 1484293 I noticed that this assertion failed:
https://searchfox.org/mozilla-central/rev/ef8b3886cb173d5534b954b6fb7eb2d94a9473d0/dom/base/ShadowRoot.cpp#160
(during unlink, while unbinding the kids)
We rely on GetComposedDoc returning the right thing during unbind to cleanup
some stuff (see bug 1473637 for example), so it should probably be correct all
the time, regardless of whether something is unlinked or not.
Also this makes GetComposedDoc() much faster, which is nice too, since we call
it somewhat often.
I removed NodeHasRelevantHoverRules, since it's unused (was used by the old
style system).
I moved the SetIsConnected(false) call for the shadow root to before unbinding
the kids for consistency with what Element does with the uncomposed doc flag,
now that the children's connectedness doesn't depend on the shadow root's.
Differential Revision: https://phabricator.services.mozilla.com/D3715
--HG--
extra : moz-landing-system : lando
While trying to repro bug 1484293 I noticed that this assertion failed:
https://searchfox.org/mozilla-central/rev/ef8b3886cb173d5534b954b6fb7eb2d94a9473d0/dom/base/ShadowRoot.cpp#160
(during unlink, while unbinding the kids)
We rely on GetComposedDoc returning the right thing during unbind to cleanup
some stuff (see bug 1473637 for example), so it should probably be correct all
the time, regardless of whether something is unlinked or not.
Also this makes GetComposedDoc() much faster, which is nice too, since we call
it somewhat often.
I removed NodeHasRelevantHoverRules, since it's unused (was used by the old
style system).
I moved the SetIsConnected(false) call for the shadow root to before unbinding
the kids for consistency with what Element does with the uncomposed doc flag,
now that the children's connectedness doesn't depend on the shadow root's.
Differential Revision: https://phabricator.services.mozilla.com/D3715
--HG--
extra : moz-landing-system : lando
Summary:
Implemented the non-event handler attributes of the Visual Viewport API
according to the spec: https://wicg.github.io/visual-viewport
The 'onresize' and 'onscroll' attributes will be implemented in the bug
1478776.
MozReview-Commit-ID: G4bkIZ9VtZ2
--HG--
extra : rebase_source : f73681fa9a6b3642e4ea176b994bd168572d7f6c
These methods are only ever used in tests and no longer need to be exposed.
In test_bug445177.xul I tried to preserve more of the test, but everything
after the call to addBroadcastListenerFor is dependent on that.
MozReview-Commit-ID: C4vAxNir4O8
The DOM elements within the UA Widget Shadow DOM should have its reflectors in
the UA Widget Scope. This is done by calling nsINode::IsInUAWidget() which
would check its containing shadow and its UA Widget bit.
To prevent JS access of the DOM element before it is in the
UA Widget Shadom DOM tree, various DOM methods are set to inaccessible to
UA Widget script. It would need to use the two special methods in ShadowRoot
instead to insert the DOM directly into the shadow tree.
MozReview-Commit-ID: Jz9iCaVIoij
--HG--
extra : rebase_source : b7b17be68dcde00cfeb207cb39cf16b486f2ab02
This is the same as the non-standard 4th addEventListener argument, but in a
more standard place. Aside from being easier for readers to understand, this
makes it much easier to define a set of DOM events an IPC actor needs to
handle, without adding extra hacks to handle untrusted listeners.
MozReview-Commit-ID: H6KxjSHtQrY
--HG--
extra : rebase_source : 2d07a77f0cc22df59e19740d8ef538da06e763d3
Screen's MediaCapabilities extensions aren't fully defined yet, but we don't want this to be blocking the release of the remaining features.
As such, we place those extensions behind a new pref: media.media-capabilities.screen.enabled
Differential Revision: https://phabricator.services.mozilla.com/D3060
--HG--
extra : moz-landing-system : lando
When ignoreBOM is true, the encoding spec says to not treat leading DOM bytes
specially, which corresponds to our NewDecoderWithoutBOMHandling factory method
for the encoder.
Allows non-XUL chrome privilege documents to also use the command
dispatcher. The command dispatcher is created lazily since it will not
always be used.
Update test to reflect removal of the XUL attribute "commandDispatcher"
from content privilege XUL.
MozReview-Commit-ID: HUXMG9kx4ft
This renames the RTCRTPStreamStats partial dictionary to match the recent spec changes
Differential Revision: https://phabricator.services.mozilla.com/D2682
--HG--
extra : moz-landing-system : lando
Allows top level non-XUL documents to share this code. Three tests had to
be adjusted to account for the attributes being chrome only now and not
available to content privilege XUL. In two tests, the values attributes
are now simply undefined. The crashtest was converted to a chrome
mochitest to preserve what it was testing.
MozReview-Commit-ID: 99w9Ax4et3C
--HG--
rename : dom/base/crashtests/473284.xul => dom/base/test/chrome/test_bug473284.xul
extra : rebase_source : 924d34a88fe8a48d766f78b02e64275f6e7cdc2b
Various web authors have expressed desire to know in advance whether autoplay
will work.
They want this in order to avoid paying the price for downloading media that
won't play. Or they want to take other action such as showing a poster image
instead.
This is of particular interest to Firefox, as we're planning on showing a
prompt to ask the user whether they would like a site to play. If sites want to
determine whether they can autoplay but avoid the prompt showing, they won't be
able to just call play() in Firefox and see whether it works, as that would
likely show the prompt if the user doesn't already have a stored permission.
We've been working out a spec here:
https://github.com/whatwg/html/issues/3617#issuecomment-398613484
This implements what is the consensus to date there;
HTMLMediaElement.allowedToPlay, which returns true when a play() call would not
be blocked with NotAllowedError by autoplay blocking policies.
MozReview-Commit-ID: AkBu0G7uCJ0
--HG--
extra : rebase_source : 3f31db79aa1e570fdd9fc7062d0ddac7c96a8931
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
It's currently only accessible on XULDocument and XULElement, but that makes porting existing
JS to run in an HTML document inconvenient. We could alternatively change calling JS, but
this can be easily moved and exposed in chrome contexts.
MozReview-Commit-ID: JitYET20NSE
--HG--
extra : rebase_source : 75d823c688cba8d84dc19705e83284be383962f2
Also remove overload for XULDocument::Persist and the implementation
of XULDocument::DoPersist, since there's only one remaining caller.
MozReview-Commit-ID: CPaTdFJ4GOx
--HG--
extra : rebase_source : b0fdfbdab204f787349b3284fc8c73c4aa799d66
The CSSAnimation and CSSTransition interfaces are only needed to represent CSS
animations and CSS transitions returned by the
{Document,Element}.getAnimations() API.
Bug 1471814 introduced the dom.animations-api.getAnimations.enabled pref but
neglected to guard the CSSAnimation and CSSTransition interfaces behind this
pref, leaving them guarded by the dom.animations-api.core.enabled pref instead.
This patch updates the pref used to guard these interfaces so that when we turn
on the dom.animations-api.core.enabled pref by default we don't also end up
shipping these interfaces.
MozReview-Commit-ID: GjfvOltxlJy
--HG--
extra : rebase_source : 254cde7e9975d83b4ac94567725e6475f344e61d
At some point the type of the ssrc field changed to an unsigned long.
MozReview-Commit-ID: BmGXAaKQfim
--HG--
extra : rebase_source : b749797b5001b2ef867a239f61d22c69d5d22408
This is probably the last thing we will ship since it needs the most spec work.
MozReview-Commit-ID: LLmDBLCsCBJ
--HG--
extra : rebase_source : c06752c9201a9ede87e1ac200ab12577bf784ce6
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified.
Unlike other patches in this series, compositing is not frequently used
internally (e.g. by DevTools etc.) so there is no need to enable this by default
for system code.
Also, it turns out we have inadvertently been shipping part of this feature for
some time now. The next patch in this series will add tests for that case and
disable that part of the feature (a suitable intent to unship will follow). This
patch merely adapts and extends the existing tests without affecting the surface
area covered by the combination of the newly-added pref and the existing
dom.animations-api.core.enabled pref.
MozReview-Commit-ID: Htr6mlyCBav
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_compositing.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_compositing.html
extra : rebase_source : 7715a25e59568eb122ba3f7dbd2c2b2ffdd19954
We don't intend to ship this in the near future until the integration with
AnimationWorklet is clear (although we might ship a read-only version).
That said, we use this feature extensively internally (e.g. in DevTools etc.) so
we enable this feature for system callers.
MozReview-Commit-ID: AhB7ZmU1Xzw
--HG--
extra : rebase_source : 630d7dc56b44a9261bb34aa5417cb9b7050efba4
Link to the standard: https://webaudio.github.io/web-audio-api/#dom-audioparam-setvaluecurveattime
MozReview-Commit-ID: 8GwaIbQkfr2
--HG--
extra : rebase_source : aa8dd5e653de51768ff81d855fe1b8b398baa586
extra : intermediate-source : 9d34c85e0ec166fb7a117b2a85ca7cd4e98b1ceb
extra : source : d752fc72a9a35fdc0ce7b8bce94b29149eaf7639
The following was removed:
- the main meat of the overlays and interface in XULDocument
- all overlay observers and forward references
- the notion of a master document
- XUL overlay provider
- manifest parsing of overlay attribute
- references to "overlay" atom
- restrictions on persistence (only need because of overlays)
- unused code that the above referenced
I also attempted to update comments that referenced overlays, but there is still
some work to be done here.
MozReview-Commit-ID: 8lrirzcgSuJ
--HG--
extra : rebase_source : 25b4e1d3fb2af6f02d894887271fd345c9c2083b
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 978a3fecf87e1ac4414ec0ea93335796bc24951a
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 5852093c015844cf3cc49dcd7fe71c9ea881eef9
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 9679d42cc9df899e2208a3cb72e14fdaabbcad8c
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
Make document.domain non-nullable, to conform to the HTML spec.
MozReview-Commit-ID: B1YuQekBgZD
--HG--
extra : rebase_source : 00999e16549e62c783f06f61c62000ab7677cf1d
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : f965bd0593b512ec57ffc5268eecf3b4fe8e820a
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
Cache AccessibleNode and make it able to operate the same instance by nsINode::GetAccessibleNode
--HG--
extra : rebase_source : 063eec8658af020f5408260d7d581ee76a04bd37
These properties are unused from C++ apart from webidl bindings and the
FakeTreeBoxObject implentations in comm-central are throwing stubs. But
they're used in JS. They are safe to remove from nsITreeBoxObject but we need
to keep an implementation webidl can call into. Properties in this bucket:
selectionRegion, ensureCellIsVisible, scrollToRow, scrollByLines,
scrollByPages, getRowAt, removeImageCacheEntry.
These properties are not used from either JS or C++, and hence can be
removed from both nsITreeBoxObject and TreeBoxObject.webidl. Properties in
this bucket: scrollToCell, scrollToColumn, scrollToHorizontalPosition,
invalidateColumnRange.
Deleted the old Chrome DataTransfer constructor because it was only used
for some tests which can be easily changed. Added a new constructor that
is not Chrome Only.
MozReview-Commit-ID: HjcgafSiWfM
The last remaining user is already turned off and being removed
in bug 1444395 so that we can finally remove this unsafe code and
sleep a little better knowing that XSS through markup injections
will be impossible in chrome contexts.
MozReview-Commit-ID: KcZq8fRPiD4
--HG--
extra : rebase_source : 5def3abb50ed8f1b43e17072088e38a44394488b
I've made the returned object from .bounds not live. If that's not OK, I'll
resurrect DOMBounds (removed in a previous patch). This also forces
DOMQuad.toJSON() to only return the points.
MozReview-Commit-ID: 10TY5oJUmTN
--HG--
extra : rebase_source : ab209d584390c584aa0d0814b4dd2bbf48c6cca3
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 97e9386cfb17319242913d28117c8b1b8b6fbbbe
the id was a b2g feature only settable via chrome privd xhr and is no
longer active in the code base
MozReview-Commit-ID: 84GPNvhvjNb
--HG--
extra : rebase_source : ab5c2229b98e1407b8b74ef2ee00dcfea45e046a
This check is already done by the dictionary init method. This function just
makes us do extra non-spec get operations.
For now this introduces more failures due to bug 1419323 and the spec issue at
<https://github.com/whatwg/html/issues/3580>. The tests testing for that stuff
were passing due to exceptions getting thrown from CheckLifeCycleCallbacks.
1. Add AddressErrors in PaymentRequest.webidl.
2. IPC for passing AddressErrors.
3. Getters for AddressErrors in nsIPaymentDetails.
--HG--
extra : rebase_source : 64c57003d57e064b5284cc64447c0c0740f16121
This patch creates a chrome-only method
customElements.setElementCreationCallback() so that custom elements migrated
from XBL bindings doesn't have to be define()'d on document loading. With this
method, we will set callbacks and the platform will get back to us when it
encounters a matched custom element type -- and the callback will load the
relevant script.
It's important to note that the callback runs after construction of the first
element; it will be upgraded when it's being appended.
MozReview-Commit-ID: 80z72zwXRlf
--HG--
extra : rebase_source : 826188e56bb0b167d1e5bafb7d2a487a32bd9dfa
The aim of those changes is to be incubated in the WICG.
MozReview-Commit-ID: K93xiTod6tw
--HG--
extra : rebase_source : 788122a69b6cab96bab9c2ae6e8cdf7c61d4ed07
The aim of those changes is to be incubated in the WICG.
MozReview-Commit-ID: 5wEUnWz8i7kBug 1280613
--HG--
extra : rebase_source : 4360d2c34025bf3c87fff49f0e2aa01975fff15b
We can't remove navigator.javaEnabled() entirely because that would break any web content that tries to call the function.
MozReview-Commit-ID: KIOBrZuMu9r
--HG--
extra : rebase_source : 112ec5308d59e8d12a8ea540784ea157e575d09c
extra : intermediate-source : e9b145757c2f27440749408d9de31df7b5d60ff8
extra : source : 5fe4a7a8723bbd9cd954905cbf3937f45706d660
extra : histedit_source : a62c9571a53a834ef15778a01cb993d7e8dc3daa
I can land the removal behind a pref first if you want and all that instead.
Again, this doesn't remove the internal usage for getComputedStyle (yet).
MozReview-Commit-ID: LA157ohfLhu
It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
By doing this we will have all the KeyframeEffect* related code in
KeyframeEffectReadOnly.{h,cpp} so we can rename them to KeyframeEffect.{h,cpp}
in the next patch and make it easier to examine the history for the bulk of this
code.
The added [HeaderFile] annotation will be removed in a subsequent patch in this
series.
MozReview-Commit-ID: Fxk6fPukgAS
--HG--
extra : rebase_source : 0bb0f846aba69e2b79724adb3148948317667eae
It might seem a bit odd to move the setters to the read-only class that we are
ultimately planning to drop but the reason for doing this is that
KeyframeEffectReadOnly.cpp has a *lot* more code than KeyframeEffect.cpp.
In order to simplify code archaeology we take the following approach:
1. Move code from KeyframeEffect.{h,cpp} to KeyframeEffectReadOnly.{h,cpp}.
2. Delete KeyframeEffect.{h,cpp}.
3. Rename KeyframeEffectReadOnly.{h,cpp} to KeyframeEffect.{h,cpp}.
Note that at least steps 2 and 3 must be performed in separate patches as
mercurial does not successfully track renames when the target name already
exists.
MozReview-Commit-ID: LwJoxGJitKR
--HG--
extra : rebase_source : ae437c6e74435b983c7390df301055472fa3c4ff
None of the C++ callers of RemoveSelectionListener care about whether the
listener was already-added, and the only JS caller is in a test and knows the
listener was added. So the behavior change to no-op instead of throwing when
trying to remove a nonexistent listener is OK. Furthermore, the removal is
null-safe, so there's no point to explicitly failing if null is passed (which
it never is).
Since content can't directly add selection listeners, we can just use an
infallible append instead of returning errors callers don't check for anyway.
Also, no one passes null to AddSelectionListener, so we don't have to worry
about that part.