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
By storing the PrincipalInfo in the parent copy it is possible to
query the BackgroundSessionStorageManager withouth the need of a
preprocessing step matching resulting data to principals using the
browsing context tree. Instead the result from the query contains the
principal info.
To be able to initialize the parent actor lazily with a principal
info, it was needed to make clearing the storage be a less fine
grained transaction. Instead of sending updates per cache, we after
clearing in the child process we send a message to the parent that in
turn performs the same steps.
Differential Revision: https://phabricator.services.mozilla.com/D125680
This is slightly complicated by the fact that the editor code wants to be able
to set this from the content process, so we really need separate
BrowsingContext and WindowContext flags, the latter of which can be set by the
owning process.
Differential Revision: https://phabricator.services.mozilla.com/D114899
Session Storage used to share implementation with Local Storage, where
a distinction of a default data set from a session data set made
sense. In Session Storage all data is actually scoped by the
session. Since Bug 1322316 Session Storage no longer share
implementation with Local Storage, which makes it safe to collapse the
datasets in Session Storage to one dataset, which makes life easier,
especially for Session (Re-)Store.
Differential Revision: https://phabricator.services.mozilla.com/D116609
Use the newly added session storage data getter to access the session
storage in the parent and store it in session store without a round
trip to content processes.
Depends on D111433
Differential Revision: https://phabricator.services.mozilla.com/D111434
Use the newly added session storage data getter to access the session
storage in the parent and store it in session store without a round
trip to content processes.
Depends on D111433
Differential Revision: https://phabricator.services.mozilla.com/D111434
A previous patch made it so we'd fire this after the full restore finished, but
some consumers expect this event prior to the completion of the load.
Differential Revision: https://phabricator.services.mozilla.com/D114001
This also makes it so that we will never fire SSTabRestored without first having
sent the associated SSTabRestoring event.
Differential Revision: https://phabricator.services.mozilla.com/D110335
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
This also makes it so that we will never fire SSTabRestored without first having
sent the associated SSTabRestoring event.
Differential Revision: https://phabricator.services.mozilla.com/D110335
This should help avoid message ordering issues in the next patches. To ensure
that we're not firing events too early, we now do a "full" restore even if we
don't have form or scroll data, including for about:blank URIs.
This also moves all restore state on the CanonicalBrowsingContext into a
separate `mRestoreState` struct.
Differential Revision: https://phabricator.services.mozilla.com/D110333
A document that changes the "multiple" attribute of the <select> element after
the load event (eg., perhaps in response to user action) will crash the browser
since we will attempt to restore data collected for a multi-select into a
single-select.
Differential Revision: https://phabricator.services.mozilla.com/D112057
A document that changes the "multiple" attribute of the <select> element after
the load event (eg., perhaps in response to user action) will crash the browser
since we will attempt to restore data collected for a multi-select into a
single-select.
Differential Revision: https://phabricator.services.mozilla.com/D112057
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Differential Revision: https://phabricator.services.mozilla.com/D107814
