On e.g. Debian unstable, the wasi SDK is available via packages in a
multiarch fashion, which doesn't require the --sysroot flag being passed
to the compiler.
Differential Revision: https://phabricator.services.mozilla.com/D166978
webgl.out-of-process and webgl.out-of-process.worker is already enabled on Android nightly. Since Bug 1794237 and Bug 1798703 were addressed, we do not have a regression bug. Then it seems OK to enable them until release.
Differential Revision: https://phabricator.services.mozilla.com/D166974
There are no -Wtautological-constant-in-range-compare warnings in C or C++ code in mozilla-central, so we can enable this warning.
However, the -Wtautological-constant-in-range-compare flag also enables -Wtautological-value-range-compare warnings and there are some -Wtautological-value-range-compare warnings in some third-party C code.
I filed https://bugs.chromium.org/p/google-breakpad/issues/detail?id=859 for the Google Breakpad warning.
---
toolkit/crashreporter/google-breakpad/src/third_party/libdisasm/ia32_invariant.c:112:30 [-Wtautological-value-range-compare] result of comparison of 3-bit unsigned value == 101 is always false
js/src/zydis/Zydis/Decoder.c:2200:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:2213:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:2226:43 [-Wtautological-value-range-compare] result of comparison of 2-bit unsigned value < 4 is always true
js/src/zydis/Zydis/Decoder.c:3650:46 [-Wtautological-value-range-compare] result of comparison of 3-bit unsigned value < 8 is always true
js/src/zydis/Zydis/SharedData.c:119:47 [-Wtautological-value-range-compare] result of comparison of 15-bit unsigned value != 65535 is always true
third_party/aom/aom_dsp/intrapred.c:94:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:123:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:152:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:413:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:444:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
third_party/aom/aom_dsp/intrapred.c:475:3 [-Wtautological-value-range-compare] result of comparison of 4-bit unsigned value < 31 is always true
Differential Revision: https://phabricator.services.mozilla.com/D165522
On e.g. Debian unstable, the wasi SDK is available via packages in a
multiarch fashion, which doesn't require the --sysroot flag being passed
to the compiler.
Differential Revision: https://phabricator.services.mozilla.com/D166978
I looked at every call to `guardClass` in CacheIR.cpp and modified it unless:
1. It was in an IC that we already only attach once (eg tryAttachTypedArrayConstructor).
2. It was only being generated in megamorphic code.
3. It was for WindowProxy (we already have issues with globals changing shape).
Then I collected rough statistics from Speedometer / Facebook / CNN / Reddit:
```
| FirstStub | NotFirstStub | Percent
Array | 11882 | 1141 | 9.6%
Map | 1425 | 41 | 2.9%
Set | 447 | 0 | 0.0%
DataView | 42 | 5 | 11.9%
MappedArguments | 952 | 716 | 75.2%
UnmappedArguments | 25688 | 13724 | 53.4%
JSFunction | 121 | 99 | 81.8%
```
The failure rate for arguments and JSFunction was way too high, so I removed the code for those.
Differential Revision: https://phabricator.services.mozilla.com/D166840
This patch fixes a bug introduced by bug 1808228/D166266, where, if an
element does not initially match :nth-child(An+B of selector list) or
:nth-last-child(An+B of selector list), changing a sibling or ancestor
will not invalidate that element.
Differential Revision: https://phabricator.services.mozilla.com/D166982
Height of inline elements are considered with current `font-size` and
`line-height`. Therefore, if content in inline elements are taller, the
`background-color` does not fill the bigger content background entirely.
For solving this issue, Chrome handles styles of `<font>` element as
outer-most style. This is reasonable approach, let's follow this.
For solving this issue, we can change the order of `PreservedStyle`s at setting
the preserved styles. Then, `SetInlinePropertiesAsSubAction` is called with
reversed order and apply later style first and applies newer styles to all
content in an element which is previously inserted. Therefore, the `<font>`
element styles should be last elements of `PendingStyles::mPreservingStyles`.
When applying new style, our style editor does not reuse existing `<font>`
element, and this causes writing WPT harder. Therefore, this patch also changes
the applying range of `<font>` style to wrapping existing `<font>` element if
and only if its content is entirely selected.
Unfortunately, this approach cannot get exactly same result as Chrome because we
insert outer-most `<font>` element first, then, try to apply `background-color`,
at this moment, our style editor applies the style to the previously inserted
`<font>` element instead of creating new `<span>` element. This behavior is
required for compatibility in the other cases. Additionally, changing only this
behavior requires a lot of method changes to specify how to handle it. However,
this incompatible behavior may not cause any problems in web apps in the wild.
Therefore, this patch does not solve this incompatible issue. I think that once
we get a bug report caused by this difference, we should redesign how to set
multiple inline styles once.
Differential Revision: https://phabricator.services.mozilla.com/D166617
Took a stab at revamping and adding to the Storybook README. The stuff on reusable components should probably be in a separate document, but I wasn't sure where to put it just yet. Eventually some part of this doc will become our Storybook landing page.
Differential Revision: https://phabricator.services.mozilla.com/D166209
Since language is also exposed as a text attribute and we cache all text attributes, we already cache this.
Thus, the RemoteAccessibleBase implementation just fetches it from the text attributes cache.
Differential Revision: https://phabricator.services.mozilla.com/D166857
The new statistic data sent from the new media engine which we created
after crash would be a completedly new data.
However, we might have accumulated some data in our `mFrameStats` before
crash. We need to consider the statistic data we've accumulated before
in order to make `mFramsStats` growing correctly.
Differential Revision: https://phabricator.services.mozilla.com/D166412
This patch makes the external state machine be able to recover playback
when the MF CDM process crash.
In addition, one of the important thing is that, the external state
machine would need to recreate the MFMediaEngineParent/Child actor
first, before the media format reader recreate the remote decoder.
Otherwise, the new created remote decoder won't be able to find the
correct media engine stream, which would be created after finishing
the initializtion of the engine parent actor and the media source.
Differential Revision: https://phabricator.services.mozilla.com/D166411
Tom Schuster
Mike Hommey
Noemi Erli
Mozilla Releng Treescript
Lee Salzman
sotaro
Karl Tomlinson
Norisz Fay
Chris Peterson
Masayuki Nakano
alwu
Eden Chuang
Iain Ireland
Zach Hoffman
Jim Blandy
Butkovits Atila
Nico Grunbaum
Hanna Jones
Mark Banner
James Teh
Otto Länd
Mike Conley
Geoff Brown
Gijs Kruitbosch
Edgar Chen
Mark Striemer