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
Previously, we used a bitmask stored in the primitive visibility
state to determine which alpha batchers a primitive should be
added to, based on dirty regions.
The problem with this is that we had a limited number of bits that
could store visibility. If we overflowed that, all primitives that
touched any dirty rect would get added to the final bit group. This
was a performance cost in this edge case, but didn't affect the
correctness of rendering.
However, in future we'll have alpha tiles behind and in front of
compositor surfaces, if the compositor surface itself is not
opaque. This means we'll have more tiles that we need to add
prims to, and we must ensure the dirty rect tracking only adds
prims to tiles that the prim definitely belongs to.
This patch removes the bitmask, and instead stores a rect that
the prim occupies, which is intersected with the dirty rect
for the specific alpha batcher. No extra space in consumed in
the visibility state enum, as there was already padding in the
Detailed enum kind. There is a slight extra cost in terms of
the comparison for dirty primitives, but this is mitigated by
the ability to early out during Coarse -> Detailed prim visibility.
Long term, we want to change how tiles store this information so
that an index buffer is stored of dirty prims, negating the need
to walk the entire picture tree during batching.
Differential Revision: https://phabricator.services.mozilla.com/D109023
`AutoScrollParent` starts autoscroll even if the requested tab has already
been in background tab. In this case, it does not make sense to start
autoscrolling in new foreground window since it may not be scrollable.
Additionally, our `mousedown` event default action activates the DOM window,
but in the DuckDuckGo's case, focus shouldn't be backed to the clicked tab.
Differential Revision: https://phabricator.services.mozilla.com/D106590
Remove a bit of the aStyleDisplay gunk that shouldn't be needed because
of two reasons:
* Stylo is faster / has the style display one pointer-chase away, as
opposed to the old style system.
* We now check the MAY_BE_TRANSFORMED bit first now, and we deal with
SVG-transformed frames, so for non-transformed frames IsTransformed
should just be a bit-check now.
Differential Revision: https://phabricator.services.mozilla.com/D109511
The change in `guessPhiType` is necessary because after pruning the path from the entry block to the OSR preheader, phis in the preheader only have one operand and can be simplified by phi elimination, making it possible for a phi elsewhere in the CFG to have two distinct OsrValues as its operands.
The alternative to this patch and the previous one is to add code in PruneUnreachableBlocks to bail out of pruning if the non-OSR predecessor of the OSR preheader is unreachable. This lets us do branch pruning in a subset of OSR compilations. (Top-level scripts are the most likely to be unprunable.)
Differential Revision: https://phabricator.services.mozilla.com/D108898
In OSR compilations, if branch pruning eliminates the path from the entry block to the OSR preheader block, we can end up with loop headers with a backedge but no other predecessors. This breaks our dominator tree implementation. (Specifically, we crash in `IntersectDominators` with the header as `block1` and the OSR entry as `block2`.)
GVN solves this problem by adding fake unreachable predecessors to loop headers. This patch factors out the GVN code so that the next patch can use it to support branch pruning with OSR.
In the existing implementation, we create zero-input phis to use as inputs for any phis in the loop header. The zero-input phis were a problem for branch pruning, which runs before phi specialization, so I replaced them with MUnreachableResults. To avoid problems during lowering, I added a simple pass that removes the fake blocks after they are no longer needed.
(This removes one of the cases where visitBlock can visit an unreachable block; I verified that the no-GVN case is still possible and updated the assertions.)
Differential Revision: https://phabricator.services.mozilla.com/D108897
When we prune unreachable code, we mark the operands of removed instructions to ensure that they can be recovered if we bail out. The previous implementation of branch pruning always eliminated entire blocks. For blocks that always bail out, the new approach will only remove the instructions after the first MBail. We can therefore be a bit more precise about which operands we flag as having removed uses.
Differential Revision: https://phabricator.services.mozilla.com/D108896
We mark blocks as bailout blocks in WarpBuilder when we add an unconditional bailout. In branch pruning, we remove all the unreachable instructions (everything in a basic block after a bail), and remove any unreachable blocks.
I used a worklist approach to marking blocks instead of ReversePostOrderIterator because it gives us a more precise result for the reachability of a block header in the presence of OSR.
`optimized-out-03.js` was fragile and depended on compiling at exactly the right time. The new version should be a little more robust.
The TODO about over-marking is addressed in the next patch. The TODO about supporting OSR is addressed in the two patches after that.
Differential Revision: https://phabricator.services.mozilla.com/D108895
We don't use code coverage hitcounts for PGO in Warp, so HitState is always NotDefined.
Drive-by: Removing `JSScript::incHitCount`. Its only caller was removed in part 9 of bug 1682767.
Differential Revision: https://phabricator.services.mozilla.com/D108894
This restyling mainly focuses on the text inputs, but also adjusts some
margins so that they apply more consistently between permission panels
and the password panel.
Differential Revision: https://phabricator.services.mozilla.com/D109105
This also fixes an issue with block margins that I noticed while developing
this patch, namely that the Profiler menu item was a few pixels too short
in addition to being offset to the right.
Differential Revision: https://phabricator.services.mozilla.com/D109453
Previously, we used a bitmask stored in the primitive visibility
state to determine which alpha batchers a primitive should be
added to, based on dirty regions.
The problem with this is that we had a limited number of bits that
could store visibility. If we overflowed that, all primitives that
touched any dirty rect would get added to the final bit group. This
was a performance cost in this edge case, but didn't affect the
correctness of rendering.
However, in future we'll have alpha tiles behind and in front of
compositor surfaces, if the compositor surface itself is not
opaque. This means we'll have more tiles that we need to add
prims to, and we must ensure the dirty rect tracking only adds
prims to tiles that the prim definitely belongs to.
This patch removes the bitmask, and instead stores a rect that
the prim occupies, which is intersected with the dirty rect
for the specific alpha batcher. No extra space in consumed in
the visibility state enum, as there was already padding in the
Detailed enum kind. There is a slight extra cost in terms of
the comparison for dirty primitives, but this is mitigated by
the ability to early out during Coarse -> Detailed prim visibility.
Long term, we want to change how tiles store this information so
that an index buffer is stored of dirty prims, negating the need
to walk the entire picture tree during batching.
Differential Revision: https://phabricator.services.mozilla.com/D109023
