No behavior change, just compute the different things we need upfront.
At first I was going to use this in the following patch but it ended up
not being needed.
Differential Revision: https://phabricator.services.mozilla.com/D109545
The test was adding a tab with a page that does a console.group call, and then
was refreshing the page and waiting for the next console.group message to be displayed.
The problem seems to be that we weren't waiting for the initial console.group message,
which might mess up the rest of the test.
We're fixing this in the patch, and adding selector to `waitForMessage` so we
are sure to get the console.group message (and not another message, as the location
does have the `hello` world in it, since we're using a data url).
Differential Revision: https://phabricator.services.mozilla.com/D109491
This fixes a regression from bug 1696178 part 5 with dictionary objects.
Object flags on non-last-properties aren't used anywhere, we need to set them on the
last property's shape.
Differential Revision: https://phabricator.services.mozilla.com/D109579
This patch:
- adds QM_WARNONLY_TRY/QM_NOTEONLY_TRY macros
- adds QM_WARNONLY_TRY_UNWRAP/QM_NOTEONLY_TRY_UNWRAP macros
- adds QM_OR_ELSE_WARN/QM_OR_ELSE_NOTE sub macros
- replaces non-propagating uses of NS_WARNING with redundant messages by
QM_WARNONLY_TRY
- replaces uses of QM_TRY with orElse by QM_TRY(QM_OR_ELSE_WARN(...))
- replaces uses of QM_TRY inside an extra lambda with QM_WARNONLY_TRY
- replaces uses of QM_TRY with QM_VOID with QM_WARNONLY_TRY.
- replaces uses of QM_TRY with unwanted warnings with QM_NOTEONLY_TRY
- replaces uses of QM_TRY with additional Maybe wrapping for doing a
fallback with QM_TRY(QM_OR_ELSE_WARN(...))
Differential Revision: https://phabricator.services.mozilla.com/D108424
Those command handlers just check whether the given editor is an `HTMLEditor`
or not. Therefore, we should make them check whether the given editor is
a single line editor or not instead.
Differential Revision: https://phabricator.services.mozilla.com/D108572
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
The IPDL source added in this stack changes the unified protocol chunking and
triggers problems caused by the missing include.
Differential Revision: https://phabricator.services.mozilla.com/D109024
This migrates WebNavigation.jsm to use messages from PExtensionsParent
generated by the native WebNavigationContent class, and removes the now-unused
WebNavigationContent.js frame script.
Differential Revision: https://phabricator.services.mozilla.com/D103217
This ports the last remaining piece of WebNavigationContent.js, the
DOMContentLoaded event listener, to C++ and adds IPC messages to notify the
parent process of the events. Linkage between the parent IPDL endpoints and
the parent WebNavigation.jsm listeners is added in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D103216
This ports the WebProgressListener logic from WebNavigationContent.js to the
C++ implementation, and adds IPC messages to send them to the parent process.
Linkage between the parent IPDL endpoints and the listeners in
WebNavigation.jsm is added in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D103215
This is a skeleton class which will be instantiated at startup in each
process, and eventually track the same events that the deprecated
WebNavigationContent.js frame script currently tracks.
Actual implementation is added in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D103213
This is the start of an actor which will be automatically instantiated in the
parent and each content process which can be used to route most process-level
IPC traffic needed by the extensions framework. It should allow the extensions
framework to keep its IPC glue close to the code that uses it, and simplify
matters for child-side code which needs to run in both parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D103212
There currently isn't a typesafe way to get a property with a given interface
from a property bag from C++. This patch adds one, following the pattern of
similar helpers, like `do_GetInterface`.
Differential Revision: https://phabricator.services.mozilla.com/D103210
The extension framework needs to set specific flags on navigations triggered
by meta refresh headers. Adding this to the load type of all navigations
triggered by meta refreshes allows it to do this without tracking docshells on
which refreshes are attempted so that it can make inferences.
Differential Revision: https://phabricator.services.mozilla.com/D108726
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
This is needed for bug 1700379, because otherwise we create a reference
frame with the root's scrolled content (the
::-moz-scrolled-page-sequence), and that breaks some display list
invariants.
Always create a canvas frame instead, (doesn't matter when printing
since we print off the page sequence frame directly), and create a
single ::-moz-page-sequence box.
Differential Revision: https://phabricator.services.mozilla.com/D109512
No behavior change, just compute the different things we need upfront.
At first I was going to use this in the following patch but it ended up
not being needed.
Differential Revision: https://phabricator.services.mozilla.com/D109545
Emilio Cobos Álvarez
Mirko Brodesser
Marco Bonardo
Kershaw Chang
Mike Conley
Keefer Rourke
Nicolas Chevobbe
Jan de Mooij
Mike Hommey
Csoregi Natalia
Butkovits Atila
Jan Varga
Tooru Fujisawa
Masayuki Nakano
Kris Maglione
Harry Twyford
Sam Foster
Timothy Nikkel