Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
Currently, `Document` checks it only with whether the document is editable
or not. Only with this check, `execCommand` and the other related methods
work only when there is `contenteditable`.
Therefore, this patch makes it to check whether the target is editable or not
with target editor.
Differential Revision: https://phabricator.services.mozilla.com/D108570
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
This will guarantee that when `<input>` or `<textarea>` is in `contenteditable`,
`execCommand` and the other related methods work with same command class
instance and same command context (in this case, it's editor instance).
Differential Revision: https://phabricator.services.mozilla.com/D108568
Editor command should be handled in same command table between `ExecCommand`
and the other related methods. However, currently, only `ExecCommand` does
optimized things. For using same logic in the other methods, the code should
be in an independent stack class.
Differential Revision: https://phabricator.services.mozilla.com/D108567
Although these commands supported supported only by Gecko, we shouldn't stop
supporting them unless we know the usage in the wild. Therefore, this patch
adds the handling code for `TextEditor` too.
Differential Revision: https://phabricator.services.mozilla.com/D108571
Currently, `Document` checks it only with whether the document is editable
or not. Only with this check, `execCommand` and the other related methods
work only when there is `contenteditable`.
Therefore, this patch makes it to check whether the target is editable or not
with target editor.
Differential Revision: https://phabricator.services.mozilla.com/D108570
For making `execCommand` and related methods with `<input>` and `<textarea>`
even if they are in `contenteditable` and focused, command should be handled
in active editor (focused editor if in foreground window and tab).
However, some commands should be handled by `HTMLEditor` even if an `TextEditor`
has focus. Therefore, this patch adds new enum class which have 3 state into
`InternalCommandData` and makes `AutoEditorCommandTarget` consider it with the
enum class.
Note that the new failures about `contentReadOnly` command will be fixed by
a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D108569
This will guarantee that when `<input>` or `<textarea>` is in `contenteditable`,
`execCommand` and the other related methods work with same command class
instance and same command context (in this case, it's editor instance).
Differential Revision: https://phabricator.services.mozilla.com/D108568
Editor command should be handled in same command table between `ExecCommand`
and the other related methods. However, currently, only `ExecCommand` does
optimized things. For using same logic in the other methods, the code should
be in an independent stack class.
Differential Revision: https://phabricator.services.mozilla.com/D108567
Previously, the DocGroup type was not cycle-collected, as it needed to have
references from other threads for Quantum DOM. Nowadays the only off-main-thread
use of DocGroup is for dispatching runnables to the main thread which should be
tracked using a performance counter for about:performance. This means we can
remove the DocGroup references from these dispatching callsites, only storing
the Performance Counter we're interested in, and simplify make DocGroup be
cycle-collected itself.
This fixes a leak caused by adding the WindowGlobalChild getter to
WindowContext, by allowing cycles between the document and its BrowsingContext
to be broken by the cycle-collector.
Differential Revision: https://phabricator.services.mozilla.com/D108865
According to the source code of Chromium, we should throw exceptions from
them only when the document is not for HTML nor XHTML. For the other reasons,
we should not throw any exceptions even if it's unknown command.
Differential Revision: https://phabricator.services.mozilla.com/D108573
This patch adds two events - `DOMFormRemoved` and `DOMInputPasswordRemoved`.
These events are notified when a form/password field is removed from
the DOM tree. When the LoginManagerChild receives the event, it calls
_onFormSubmit as the form is submitted.
This patch also adds a WeakFieldSet formlessModifiedPasswordFields to
record all the form-less password fields that users have interacted
with to track whether a formless password is removed
Depends on D106024
Differential Revision: https://phabricator.services.mozilla.com/D106025
The goal of this series of patches is to address the cases where sites
don't use standard form submission events.
The basic idea is inferring a form is submitted when the form is removed
from the DOM tree, but with one premise:
There must be a successful fetch or XHR request sent in the document before the
form is removed.
This is because websites usually send the credentials with a fetch or an
XHR. After the request succeeds, the website removes the form.
In summary, this patch does the following:
1. Add NotifyFetchOrXHRSuccess API in Document. The API sends a
"DOMDocFetchSuccess" event to who registers the event listener.
2. When a fetch request or a XMLHttpReuqest completes and succeeds,
call NotifyFetchOrXHRSuccess().
3. LoginMangerChild listen to `DOMDocFetchSuccess` event only when there
is an user interaction on the password field.
Differential Revision: https://phabricator.services.mozilla.com/D106024
We now use BrowsingContext to climb the tree and grab frame elements so
we skip over any OOP ancestors.
`Document::GetBrowsingContext()` may be `null` when the document was
just created with `document.implementation.createDocument`.
`Document::GetWindow()` will also return `null` in this case, so we
assume the document isn't a descendant of the adoptedNode, preserving
the old behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D107584
This seems to match Chrome, and makes our fullscreen implementation more
consistent between desktop and mobile.
Do you know how to best test this? This repros in RDM, but all
fullscreen tests seem disabled on Android...
Differential Revision: https://phabricator.services.mozilla.com/D107365
Use internal events which get fired for CSSOM changes, and in Shadow
DOM. This will also allow us to remove mutation events in the future.
Depends on D106273
Differential Revision: https://phabricator.services.mozilla.com/D106274
Use internal events which get fired for CSSOM changes, and in Shadow
DOM. This will also allow us to remove mutation events in the future.
Depends on D106273
Differential Revision: https://phabricator.services.mozilla.com/D106274
There are quite a few different logging modules for session history, but while developing
SHIP BFCache, I'd prefer to add some specific one for it. Later we can perhaps
merge various modules to some generic session history related.
SHIPBFCache log module will be used more in the followup patches.
Differential Revision: https://phabricator.services.mozilla.com/D105237
