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
Given the time constraints, and how fiddly this menupopup is (it's a menupopup
masquerading as a panel), I opted to not try to fix bug 985024. Instead, I've
applied the Proton styles as best I can given what I know about the styles
applied for the other menus.
Differential Revision: https://phabricator.services.mozilla.com/D109151
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
This is a real issue, but realistically we're probably not going to dig
a lot into it, and it wasn't really caused by the regressing bug in any
meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D109532
The automated tests become orange only in macOS and 32bit Windows builds. It
fails when left mouse button down is synthesized in the autoscroller (a XUL
`<panel>` element). Although I'm not sure why that depends on the platform,
APZ cancels active autoscrolling before dispatching `mousedown` event.
Therefore, `AutoScrollParent` nor `AutoScrollChild` cannot block the following
click event.
Therefore, this patch adds new field into `APZEventResult` and set it to `true`
when APZ runs `autoscroll` but canceled by a mouse input. Then, `nsBaseWidget`
can prevent following click event of `eMouseDown` and `eMouseUp` events as
expected before dispatching them into the DOM tree. (FYI: Preventing click
event of either `eMouseDown` or `eMouseUp` can prevent the following `click`
event, etc.)
Differential Revision: https://phabricator.services.mozilla.com/D107325
I was confused by the old flag `this._ignoreMouseEvents`. It's now set to
`true` by `startAutoscroll`, but `stopScroll` does not set it to `false`.
Instead, `this._scrollable` is available for this purpose.
Then, the test does not pass only on 32bit Windows and macOS. The failure is,
when clicking on left mouse button, `click` event is fired in the content.
The difference from the other platforms, the click is handled by APZ on them.
Therefore, there is no chance to consume click event in `AutoScrollParent`,
`AutoScrollChild` nor `browser-custom-element`.
Differential Revision: https://phabricator.services.mozilla.com/D107324
Chrome behaves like this:
1. When user starts autoscroll with a middle click, `mousedown` and `mouseup`
are fired, but `auxclick` nor `paste` event is not fired.
2. When user ends autoscroll with a left click, only `mouseup` event is fired.
I.e, `mousedown` nor `click` event is not fired.
3. When user ends autoscroll with a middle click, only `mouseup` event is fired.
I.e., `mousedown`, `auxclick` nor `paste` events is not fired.
4. When user ends autoscroll with a right click, `mouseup` and `contextmenu`
events are fired, but `mousedown` and `auxclick` events are not fired.
This patch emulates these Chrome's behavior as far as possible. However,
unfortunately, we cannot do exactly same behavior without some big patches
because each widget (`nsWindow` or `nsChildView`) discards a mouse event
which rolled up a widget before dispatching it into the DOM. Therefore,
for now, this patch does not fix the following issues:
1. `mousedown` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the secondary button or on any
buttons on Linux.
2. `mouseup` event is not fired in content when clicking outside the
autoscroller to close it except when pressing the primary button macOS.
3. `click` event and `auxclick` events are fired when clicking outside the
autoscroller with the secondary button.
So, the middle button `click`/`auxclick` events and `paste` event which is
reported to the bug won't be fired with this patch. I'll file follow up bugs.
Differential Revision: https://phabricator.services.mozilla.com/D104652
Chrome and Safari move selection at middle button down and does not modify the
range at middle button up. However, they handle middle button down with
`Shift` key is "continue selection". So, we should handle selection in
nsIFrame when `mousedown` event for middle mouse button is fired, but ignore
multiple selection, drag and drop and maintaining selection for aligning the
behavior to the other browsers.
This patch splits `nsIFrame::HandlePress()` and calls new method which
moves selection from `nsIFrame::HandleEvent()` when middle button is pressed.
(Note that this patch does not check whether middle click paste is enabled
because Chrome moves selection even on Windows which Chrome always disable
middle click paste on.)
With this change, "paste" event target is changed. Previously, we used target
of the preceding `mouseup` event, but we start to use the target of the
preceding `mousedown` event.
Note that even with this patch, we still behave differently from Chrome even
in the following cases:
- middle mouse button down in selected range, we collapse it, but Chrome keeps
the selection.
- middle mouse button click in selected range, we dispatch "paste" event, but
Chrome collapse selection and not dispatch "paste" event.
- middle mouse button down in selected range and up in different element,
Chrome does not modify the range nor dispatch "paste" event.
- Shift + middle mouse button in editable `<table>` works as non-editable
in Chrome, but our editor handles it with special path. Therefore, we
don't modify the range but dispatch "paste" event in the selected range.
Changing them requires bigger change and probably requires some other features'
behavior changes. Therefore, we shouldn't touch these issues until they are
actually reported as web-compat issues.
Differential Revision: https://phabricator.services.mozilla.com/D103997
The test previously depended on the position of the blocked request
in the request list view, This causes the test to fail intermittently
when the list is out of order.
This fix instead finds the request using the name in the url which is
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D109497
