In-tree users of `Math.pow` show that the function is often called with the base operand equal to
two. This case can easily be optimised to a series of shift-instructions for any power of two. For
now this optimisation is only taken for 2^i with i in {1..8} to avoid generating too many
consecutive shift-instructions. 2^8 = 256 was chosen as the limit, because it is the maximum power
of two base operand for `Math.pow` used in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D37587
Similar to `LIRGeneratorX86Shared::lowerForALU`, try to use the same register when multiplying an
operand with itself.
This change improves the generated assembly for `Math.pow(x, 2)` from:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI
imull %ecx, %eax
jo .Lfrom0000
```
to:
```
# instruction MulI
imull %eax, %eax
jo .Lfrom0000
```
Differential Revision: https://phabricator.services.mozilla.com/D37586
That way the trailing DoubleToInt32 doesn't emit the negative zero check sequence:
```
movq %xmm0, %rax
cmpq $0x1, %rax
jo .Lfrom0000
```
When MPow is used with a constant power which can be folded to MMul, this change
will lead to better codegen, too. For example `Math.pow(x, 2)` where `x` is an
Int32 value, currently generates the following assembly:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI:CanBeNegativeZero
imull %ecx, %eax
jo .Lfrom0000
testl %eax, %eax
je .Lfrom0000
```
With this patch, this assembly will be generated:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI
imull %ecx, %eax
jo .Lfrom0000
```
Differential Revision: https://phabricator.services.mozilla.com/D37584
Includes removing an error code for a function that never fails, and removing
an error return when the function successfully did what it said it would.
Differential Revision: https://phabricator.services.mozilla.com/D78929
Not returning a valid target for print output causes the whole printing
progress to fail. When printing silent, we choose "native" format, which in the
GTK backend just fails because we return null (wat).
This fixes printing with print.always_print_silent. Printing via the file
dialog gets an explicit format so we don't hit that code path.
Differential Revision: https://phabricator.services.mozilla.com/D79116
This seems to match what other browsers do, and seems saner layout-wise,
at least.
I only annotated outline-width-interpolation.html because it's already
fixed upstream in:
8a489657bc
Differential Revision: https://phabricator.services.mozilla.com/D75360
This prevents us not descending to rebuild the display list if the
overflow changes during an intermediate layout like a flex layout.
To capture Matrix discussion: This is a bit unfortunate, but the idea is
that text-overflow is usually pretty small (at most one line of content)
so we can probably live with this.
An alternative would be to do something like
nsDisplayListBuilder::MarkFrameForDisplayIfVisible, which could work as
well.
Note that this is a bit of a speculative fix because neither me or
Cameron have been able to reproduce the issue in local builds (I tried
all the combinations of gfx-things that I could think about). :-(
If this doesn't fix it on next nightly, we should back out and try to
repro some other way, I guess. But the hypothesis of why it happens
makes sense to me, and if it's correct it should fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D79009
When the SIMD code landed, all aligned loads/stores (except constant loads)
were changed to be unaligned, so as to not have to worry about aligning
SIMD parameters and locals. But I forgot to remove this assert.
Differential Revision: https://phabricator.services.mozilla.com/D79036
This broke when the main developer tools window was converted from XUL to XHTML. By adding the application role, the window is once again a window, not a document for the accessibility engine.
In addition, while I was here, I fixed the role of the focusable vbox because it is the first thing the user lands on when tabbing, to make it a semantic group, not an "unknown". Since this is probably supposed to be focusable for keyboard users, it is better to have an appropriate role.
Differential Revision: https://phabricator.services.mozilla.com/D79038
This adds the elements `formaction`, `data`, `ping`, `poster`.
We can't really add a test for the `<object data>`, since we never
allow `<object>` elements in the first place and we don't allow
settings exceptions for temporarily allowed elements.
Same for `poster` elements, since it's only used in media elements
and those are either all allowed or none.
Differential Revision: https://phabricator.services.mozilla.com/D78638
When window emulation is enabled, the emulated window is set on the top level DocAccessibleChild.
However, it isn't set on child documents (in-process iframes).
Therefore, when querying the window handle, we need to check for an emulated window handle on the top level document and return that if present.
This fixes the window handle returned by IAccessible2::get_windowHandle.
Note that the window handle used when firing events was already correct, as that is determined in the parent process.
In the parent process, the emulated window was already being propagated down to child DocAccessibleParents by BrowserParent::RecvPDocAccessibleConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D79035
