Previously, replace() and toggle() would not always remove duplicates
and whitespace from the DOM attribute in the case where they were no-ops
(replacing a nonexistent token, force-toggling a token to its current
state). Now they do. This matches the behavior of add() and remove(),
and also replace() in one case (replacing an existing token with
itself).
This follows a spec change: https://github.com/whatwg/dom/pull/444
MozReview-Commit-ID: 7lDEQxOGxPV
Because it tests some Gecko-specific things as well, I'm making two
copies, as advised by bz and jgraham. One is to be submitted upstream,
and a second one has local changes. This means most of the test is run
twice.
This overwrites the preexisting Element-classlist.html test upstream. I
think I took the useful bits out of it (particularly replace() testing),
but there are some things that it had that I didn't think were
necessary, including: things that belong in idlharness; .className
testing; testing .contains() and stringification and hasAttribute() and
such after add/remove/etc. (instead of just testing getAttribute()); CSS
class selector matching.
MozReview-Commit-ID: JxPK7OyVLXa
Adding automated tests as web platform tests (only for mozilla) for focus move at using Selection API.
Although, there is no standards of relation between Selection API and focus, we should move focus when Selection API moves selections into only an editing host or outside of focused editing host.
Chrome moves focus as this rules, therefore, user can modify contenteditable editor immediately after web app moves selection.
Edge does NOT move focus at using Selection API. However, user can modify contenteditable editor similar to Chrome. We can guess that Edge doesn't need to move focus in its design because perhaps, Edge decides if it's editable only with primary selected range.
We cannot take the Edge behavior due to our editor design. So, we can take only Chrome's approach for improving the compatibility.
MozReview-Commit-ID: JuLiSMgqODm
If the mathml.disabled preference is true, treat <math> and other MathML
elements as generic XML elements.
This patch disables the rendering code of MathML however preserves the
namespace so to reduce the breakage.
Original patch by: Kathy Brade <brade@pearlcrescent.com>
MozReview-Commit-ID: A2f2Q2b4eqR
Without this patch, the presence of a service worker that doesn't
respond to the FetchEvent that we dispatch for the handshake request
causes an internal redirect, which is unacceptable to the handshake
channel, therefore all WebSocket channels break on such pages.
Moreover, the integration of Web Sockets and Service Workers is unclear
yet, so these channels should bypass service workers completely.
In the non-e10s case, this is done by simply avoiding to set the
LOAD_BYPASS_SERVICE_WORKER flag when we detect a non-internal redirect
in the manual redirect mode.
The e10s solution is a bit more complicated. Only the child process
knows whether a URI needs to be intercepted, so we piggy back on the
code written to support the |event.respondWith(Response.redirect())|
case where we know in the child that the target of the redirect needs to
be intercepted.
This means that we need to check the same condition as in the non-e10s
case, but we also need to check whether the target of the redirection
needs to be intercepted, which means we need to properly take secure
upgrades into account as well. This is done by computing both whether
we should intercept and whether we should do a secure upgrade in
HttpChannelChild::SetupRedirect() and saving the information on the
HttpChannelChild for later usage in HttpChannelChild::AsyncOpen().
Doing this work in StartRedirectChannelToURI() was causing us to not set
the bypass service worker flag properly in the case of real HTTP redirects.
This patch also fixes the incorrect test expectation value.
