Changes:
- set up a new minimal docker image for `android-em` tests.
- reorganize commonly referenced files into a specific folder `taskcluster/docker/files` to reduce instances of same file being copy-pasted into directories.
- add android-test docker build task to taskcluster.
Differential Revision: https://phabricator.services.mozilla.com/D82204
Two changes happened during the LLVM 11 timeframe that break our Searchfox plugin.
First, the conversion from `llvm::StringRef` to `std::string` became explicit: adcd026838 This is easy enough to fix in a version-agnostic way.
Second, `mangleCXXCtor` no longer exists: 29e1a16be8 Since there isn't a one-size-fits-all fix, I had to use an ifdef. I mostly cargo-culted the change from 29e1a16be8 (diff-dac09655ff6a54658c320a28a6ea297c).
Differential Revision: https://phabricator.services.mozilla.com/D83838
Consider the following:
struct Complex<T> {
something: T,
#[compute(field_bound)]
something_else: Generic<Self, T>,
}
That will generate:
impl<T> ToComputedValue for Complex<T>
where
T: ToComputedValue,
Generic<Self, T>: ToComputedValue<ComputedValue = Generic<Self, <T as ToComputedValue>::ComputedValue>>,
{
// ...
}
That last clause is obviously incorrect. map_type_params correctly maps
the T, but it should know also about Self.
Ideally we could just do the same as for T and do:
<Self as ToComputedValue>::ComputedValue
But that doesn't quite work, because we are in that implementation of
the trait, and the compiler rightfully complains about we don't yet
knowing the computed type. So we need to pass it explicitly, which is
simple enough, if a bit annoying.
Differential Revision: https://phabricator.services.mozilla.com/D83816
This currently only works for WebRender. In non-WR, no frame drops are reported.
There are two reasons why it doesn't work for non-WR:
- Non-WR currently does not increment the composition opportunity ID.
- In non-WR, UpdateCompositedFrame is only called for videos when they are
drawn. But this detection relies on it being called on every composite, if
the video is part of the on-screen scene. (WR does that.)
To make this detection work for non-WR as well, we would need to address both
of those points. The latter point is somewhat tricky because non-WR calls
ChooseImageIndex many times throughout a composite, and we would need to choose
a point in the composite at which to "lock in" the image for that composite and
cache the image index on the ImageHost somewhere, and then also find a way to
reset that locked-in index in the next composite. I haven't come up with a way
to do that and I do not know if it is worth the effort.
Differential Revision: https://phabricator.services.mozilla.com/D83463
This ID is different from the IDs we already have:
- It is different from VsyncId because it doesn't skip numbers when composites
are delayed.
- It is different from RenderedFrameId because it also increases for no-op
composites.
- It is different from transaction IDs and epochs because it doesn't care about
the content side, it just looks at compositing.
It is currently not implemented for non-WR. In non-WR the video frame drop
detection wouldn't properly work anyway, because UpdateCompositedFrame is not
called on every composite for non-WR.
Differential Revision: https://phabricator.services.mozilla.com/D83461
In the current state this also counts frame drops while the video is offscreen,
but this will be fixed in a later patch in the series.
This patch also adjusts the time delta check: It now compares floored milliseconds.
In 60fps WebM videos, the video frame durations are 16.0, 17.0, 17.0, 16.0, 17.0, 17.0, ...
so we need to consider frames with 16.0ms as displayable even when the target
frame duration is 16.67ms, otherwise we gloss over one third of the frames when
counting potentially dropped frames.
Differential Revision: https://phabricator.services.mozilla.com/D82635
Correctly indicate that we're not in a composition during SetDisplayList or
during empty transactions, by making sure the composition timestamp is null
outside of a composition.
We also now return 0 rather than -1 from the first call to ChooseImageIndex
outside of a composition, so that static images (like canvases) default to
the correct initial frame. We don't call ChooseImageIndex for them again once
we composite them.
This is different from non-WebRender, which would call ChooseImageIndex on
canvas layers during every composition.
This introduces a behavior difference for static images when WebRender is enabled:
Those images will no longer update mLastFrameID, because UpdateCompositedFrame
will not be called during a composition for them.
I'm also removing a comment that seems like it's unnecessarily duplicating
information from another comment a few lines further up. That other comment is
also easier to understand.
Differential Revision: https://phabricator.services.mozilla.com/D83460
This also makes it so that UpdateBias for non-WebRender is only called when the
video frame changes. This mirrors the recent change that we made for WebRender
in bug 1652181. Non-WebRender only calls UpdateCompositedFrame when it actually
draws the video onto the screen, so when the video is the only thing that was
updating, the new behavior is equivalent. But the new behavior makes more sense
if you have a 30fps video and a 60fps animation running on a 60fps screen at the
same time - now the bias won't be accidentally reset every other frame.
Differential Revision: https://phabricator.services.mozilla.com/D83459
The telemetry probe, which is related with `mDocTreeHadPlayRevoked`, has already been removed, so we don't need these code anymore.
Differential Revision: https://phabricator.services.mozilla.com/D83163
After we enable Fissions, we can't always access the top level document because it might be in another process.
Therefore, we should move `mDocTreeHadAudibleMedia` from document to the top window context, which can ensure that we set the value correctly even if setting `mDocTreeHadAudibleMedia` happens in a different process which is different from the process where the top level document exists.
Differential Revision: https://phabricator.services.mozilla.com/D83162
In tests, the settings object doesn't have as many sections. When a section isn't
available, it raises an error.
The Sentry integration can interpret this error as telemetry being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D83717
This patch adds support for Wasm reference types when using the
Cranelift/aarch64 Wasm backend in SpiderMonkey.
The changes on the SpiderMonkey side principally involve (i) updating
the compiler-selection logic to allow Cranelift when reftypes are
enabled, and (ii) conveying the stackmaps from Cranelift to
SpiderMonkey.
This also fixes an assert failure hit in the VIXL-based MacroAssembler
in a debug build. The assert was checking that the source of a
move-to-FP-reg was not the zero register (xzr); a move like `mov v0.d[0],
xzr` is perfectly valid, and should be allowed. Unsure why this assert
had not been hit before, but it seems unrelated to reftype support.
Differential Revision: https://phabricator.services.mozilla.com/D83583
This patch updates the vendored version of Cranelift, pulling in the
reference-types support recently merged in Cranelift's PR
bytecodealliance/wasmtime#1852. Usage of this update to support reftypes
in SpiderMonkey on aarch64 is added in the subsequent commit.
Differential Revision: https://phabricator.services.mozilla.com/D83582
The eslint and jsx-a11y jobs have been broken for 6 months now.
The eslint version used by the debugger is too old to be compatible with mozilla central's eslintrc.
If we update eslint, then there are other failures (`Environment key "mozilla/xpcshell" is unknown`).
We should be able to trust the mozilla-central eslint job for basic linting.
For jsx-a11y, there is currently no equivalent in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D83495
Depends on D83194
Those test helpers were introduced to easily assert the markup view, when working on the webcomponents support in the inspector.
They use rather high level APIs and are quite close to what would be triggered by real user actions.
Roughly the helper expands nodes from the markupview recursively and checks that the tree matches the expected tree.
This "expected tree" should be provided via a simplistic DSL:
```
root
child1
subchild1
subchild2
child2
subchild3!slotted
child3!ignore-children
```
Differential Revision: https://phabricator.services.mozilla.com/D79674
- Add a helper to log cdm::Status as a string to improve error reporting.
- Fix up format strings in ChromiumCDMParent to use PRIu32 instead of u for logs
where it's appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D83702
Also add a log for when decoding fails. We typically log on any unhappy return
values from the CDM, so it makes sense we should also do so when a decode fails.
Differential Revision: https://phabricator.services.mozilla.com/D83419
This is safer in case Necko fails to notify us. The only repro we have
is fixed by bug 1651661, but this should hopefully be uncontroversial as
well and prevents crashing in release builds.
Differential Revision: https://phabricator.services.mozilla.com/D83642
