So far, we don't have a type to test anamations of a pair of length.
Since border-spacing consists two absolute lengths, we shall add this
new type.
MozReview-Commit-ID: Bo8VMWPLDHc
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
Some bits taken from a patch by Cameron McCormack. This follows a
change to the DOM spec that has already been implemented by WebKit.
We do no checks for duplicates on initial attribute parsing, only when
the DOMTokenList is accessed. We re-check for duplicates on every
DOMTokenList access, but optimized with a bloom filter, so it should be
fast. It would be possible to add a flag to check if we've already
removed duplicates from the atom list, but it would require the
nsAttrValue to talk to the nsDOMTokenList somehow, and a spare bit would
be needed in nsAttrValue, and it would only help cases where
DOMTokenList is repeatedly accessed without the content attribute being
modified in between (e.g., .length) where the token list is extremely
long.
This patch assumes that no one other than nsDOMTokenList cares if
duplicates are removed from the nsAttrValue's atom array. If anything
does, they will see inconsistent behavior depending on whether
nsDOMTokenList has removed duplicates yet. Since we don't want to
check for duplicates on parse for performance reasons, the correct fix
is to update the code elsewhere to also remove duplicates.
MozReview-Commit-ID: 97KRVhPGwm8
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
Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus.
If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host.
For consistency with the other browsers, this patch doesn't move focus to other focusable element.
MozReview-Commit-ID: 6sNsuzwqECX
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