Make all UA widgets also NAC.
Keep the UA widget flag but break at anonymous subtree boundaries, so
that only nodes inside the UA widget directly (and not NAC from those)
get the flag.
This is important because two callers depend on this difference:
* The style system, since we still want to match content rules from
stylesheets in the UA widget. We also match user rules, which is a
bit sketchy, but that was the previous behavior, will file a
follow-up for that.
* The reflector code, since we want the scope for UA widgets to not
include the NAC nodes inside that UA widget. nsINode::IsInUAWidget
got it wrong.
After this patch, ChromeOnlyAccess is equivalent to
IsInNativeAnonymousSubtree, so we should probably unify the naming.
That's left for a follow-up patch because I don't have a strong
preference.
Differential Revision: https://phabricator.services.mozilla.com/D174310
This change is necessary to support the [CSS Highlight API](https://drafts.csswg.org/css-highlight-api-1/),
which uses `Selection` internally.
To replace `nsRange` with `AbstractRange`, some sections needed to be
adapted since `nsRange`-specific features were used.
Therefore, some methods (such as `GetRangeAt()`) may only be called if
the `Selection` is *not* of type `SelectionType::eHighlight`,
as it (per spec) returns an `nsRange`.
These methods will now `MOZ_ASSERT` if called for a highlight selection.
Additional methods are implemented which return `AbstractRange`
instead and are safe to be called for every selection type.
This commit also improves support of highlight features:
- Invalidation of highlight ranges: adding/removing Ranges in-place instead of
removing and re-adding the Selection object associated with the highlight.
- Ranges are only associated with the Selection that shares the same Document
- Fixed minor IDL issue
Differential Revision: https://phabricator.services.mozilla.com/D170582
The Custom Highlight API allows a use case where a `Range` of a `Highlight`
is also used as `Selection`. Due to the decision to use the `Selection` mechanism
to display `Highlight`s, a `Range` can be part of several `Selection`s.
Since the `Range` has a pointer to its associated `Selection`
to notify about changes, this must be adapted to allow several `Selections`.
As a tradeoff of performance and memory usage, the `Selection`s are stored
as `mozilla::LinkedList`. A helper class `mozilla::SelectionListWrapper`
was implemented to allow `Selection`s to be in multiple of these lists
and without having to be derived from `LinkedListElement<T>`.
To simplify usage of the list, the use case "does this range belong to Selection x?"
is wrapped into the convenience method`IsInSelection(Selection&)`;
The method previously named like this was renamed to `IsInAnySelection()`
to be named more precisely.
Registering and unregistering of the closest common inclusive ancestor
of the `Range` is done when the first `Selection` is registered and
the last `Selection` is unregistered.
Differential Revision: https://phabricator.services.mozilla.com/D169597
This should both be faster and simpler. Also will allow us in the future
to animate more pseudos without having to add a gazillion properties.
I think we should try to clear more stuff (maybe the whole animation
data) on unbind, but that's a bit tangential.
Differential Revision: https://phabricator.services.mozilla.com/D169860
Deletion of mutation observers from a list resulted in O(n^2) behavior and could lead to massive freezes.
This is resolved by using a LinkedList instead, reducing complexity to O(n).
A safely iterable doubly linked list was implemented based on `mozilla::DoublyLinkedList`,
allowing to insert and remove elements while iterating the list.
Due to the nature of `mozilla::DoublyLinkedList`, every Mutation Observer now inherits `mozilla::DoublyLinkedListElement<T>`.
This implies that a Mutation Observer can only be part of one DoublyLinkedList.
This conflicts with some Mutation Observers, which are being added to multiple `nsINode`s.
To continue supporting this, new MutationObserver base classes `nsMultiMutationObserver` and `nsStubMultiMutationObserver` are introduced,
which create `MutationObserverWrapper` objects each time they are added to a `nsINode`.
The wrapper objects forward every call to the actual observer.
Differential Revision: https://phabricator.services.mozilla.com/D157031
We'll probably want to do something more accurate in the future with a
custom clang static analysis pass which validates that XPIDL interfaces
have the expected vtable and struct layout, however doing so would be
more involved than the string matching done in this patch.
In addition to checking for extra virtual methods, we'll likely also
want to check for data members on interfaces, and reject them unless the
class is marked as `[builtinclass]` in addition to some other attribute
which we'll need to add to prevent them from being implemented in Rust
(as c++ data members will not be reflected by the rust macro).
There were 2 instances of a comment which contained the word 'virtual'
within a CDATA block. These comments were moved out of the CDATA block
to avoid triggering the error.
Differential Revision: https://phabricator.services.mozilla.com/D151068
Some callers of `nsINode::ComputeIndexOf()` do not use its parent node except
calling it. These tiny methods make such callers simpler.
Differential Revision: https://phabricator.services.mozilla.com/D131337
This patch fixes only the cases if the result of `ComputeIndexOf_Deprecated()`
is used as unsigned integer with implicit or explicit cast.
Differential Revision: https://phabricator.services.mozilla.com/D131336
Offset in a node is declared as "unsigned long" by the standards and we don't
limit node can have less than `INT32_MAX`. So it should return `uint32_t`, but
it also needs to represent the case of "not found". For consistency with some
other APIs like `nsContentUtils::ComparePoints`, using `Maybe` must be a good
style rather than `Result<uint32_t, bool>`.
This patch fixes the callers in assertions for example.
Differential Revision: https://phabricator.services.mozilla.com/D131335
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
They are defined as "unsigned long" by the standards. So we should use
`uint32_t` rather than `int32_t` with the methods. However, layout code
uses `int32_t` a lot for representing the offset. Therefore, this patch
adds `*_FixOffset1` etc for the cases which cannot fix easily in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D131110
`select` event on text controls now dispatched immediately before
`selectionchange`. However, it needs to create `AsyncEventDispatcher` for
each. This cost may not be expensive, but they are called really a lot even
if there is no corresponding event listener.
Therefore, this patch makes `nsPIDOMWindow` and `EventListenerManager` have
`MayHave*EventListeners` flag separately for each, and makes
`SelectionChangeEventDispatcher` does not try to do create
`AsyncEventDispatcher` when there is no corresponding event listener.
Differential Revision: https://phabricator.services.mozilla.com/D131750
It does the following things when caret is collapsed in a text node in a `<p>`
or `<div>` element.
1. Split the text node containing caret to insert `<br>` element
2. Insert `<br>` element after it
3. Split ancestor elements which inclusive descendants of the `<p>` or `<div>`
4. Delete the `<br>` element if unnecessary from the left paragraph
#3 and #4 are performed by `HTMLEditor::SplitParagraph()` and it calls
`WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` correctly before
splitting the block. However, in the case (caret is at middle of a text node),
the text has already been split to 2 nodes because of #1. Therefore, it fails
to handle to keep the white-space visibility.
So that I believe that the root cause of this bug is, the method does much
complicated things which are required, and doing the redundant things will
eat memory space due to undo transactions. However, for now, I'd like to fix
this with a simple patch which just call the preparation method before splitting
the text node because I'd like to uplift this if it'd be approved (Note that
this is not a recent regression, the root cause was created by bug 92686 which
was fixed in 17 years ago:
<https://searchfox.org/mozilla-central/commit/2e66280faef73e9be218e00758d4eb738395ac83>,
but must be annoying bug for users who see this frequently).
The new WPTs are pass in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D130950
There are a lot of check of `Document`'s editable state **with** comments. This
means that it's unclear for developers that only `Document` node is editable in
design mode.
Additionally, there are some points which use composed document rather than
uncomposed document even though the raw API uses uncomposed document. Comparing
with the other browsers, checking uncomposed document is compatible behavior,
i.e., nodes in shadow trees are not editable unless `contenteditable`.
Therefore, `nsINode` should have a method to check whether it's in design mode
or not.
Note that it may be called with a node in UA widget. Therefore, this patch
adds new checks if it's in UA widget subtree or native anonymous subtree,
checking whether it's in design mode with its host.
Differential Revision: https://phabricator.services.mozilla.com/D126764
ElementInternal implements nsIFormControl and QueryInterface HTMLElement to a
nsIFormControl would return its associated ElementInternal instead.
Differential Revision: https://phabricator.services.mozilla.com/D125211
nsGenericHTMLFormElement doesn't implement nsIFormControl now as HTMLElement would
inherit it to be able to be added into HTMLFormElement and HTMLFieldSetElement and
support some common form feature.
So some places that call the nsIFormControl method on nsGenericHTMLFormElement
directly would need to queryInterface it to nsIFormControl first, this should be
fine as those places are not in a hot path.
Differential Revision: https://phabricator.services.mozilla.com/D124788
