Previously the initial value of BytecodeSection.lastTarget_ is chosen to make
the following condition true:
lastTargetOffset() + ptrdiff_t(JSOP_JUMPTARGET_LENGTH) == -1
BytecodeOffset class introcuced in part 3 requires the offset value to be
either -1 (invalid) or non-negative, and that rule conflicts with above.
Changed the initial value of BytecodeSection.lastTarget_ to -1 and added
the check for that condition in BytecodeSection::lastOpcodeIsJumpTarget,
so that we don't use negative value in BytecodeOffset.
Differential Revision: https://phabricator.services.mozilla.com/D33052
--HG--
extra : moz-landing-system : lando
Classes defined in JS using the `class` keyword, without using `extends`,
implicitly construct a new `this` object before running the body of the
constructor, and they use `new.target.prototype` as the new object's
[[Prototype]]. This is one of the ways that JS classes support subclassing.
When the subclass calls the base class constructor, the subclass's `.prototype`
is used.
Until now, we did not do this for classes defined in C++ using
JS_NewObjectForConstructor. But there's no reason it shouldn't work the same
way. Changing this is a nicety for embedders -- there's nothing using it in
Firefox or internally right now, except for testing.
Differential Revision: https://phabricator.services.mozilla.com/D31490
--HG--
extra : moz-landing-system : lando
Now that we have a suitable composition recorder infrastructure, it is just a
matter of plumbing the `WebRenderCompositionRecorder` from the
`CompositorBridgeParent` to the `RenderThread` to start recording frames.
Differential Revision: https://phabricator.services.mozilla.com/D32234
--HG--
extra : moz-landing-system : lando
Since WebRender does its rendering on a separate thread from the compositor
thread, we need a composition recorder that can be shared between threads.
Differential Revision: https://phabricator.services.mozilla.com/D32231
--HG--
extra : moz-landing-system : lando
The AsyncScreenshotGrabber now can operate in two modes:
* `ProfilerScreenshots`, which does asynchronous scaling of the captured frames
for inclusion in profiles by the Gecko Profiler; and
* `CompositionRecorder`, which does not do any scaling and is used for visual
metrics computations.
The latter mode is exposed by on the `Renderer` via the `record_frame`,
`map_recorded_frame`, and `release_composition_recorder_structures` methods.
A different handle type (`RecordedFrameHandle`) is returned and consumed by
these functions, but they translate between `RecordedFrameHandle` and
`AsyncScreenshotHandle` when communicating with the underlying
`AsyncScreenshotGrabber`.
I considered making the `AsyncScreenshotGrabber` generic over its handle type,
but the extra cost of monomorphization just to change the handle type did not
seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32232
--HG--
extra : moz-landing-system : lando
The CompositionRecorder was being stored as a UniquePtr on the
CompositorBridgeParent, but was then passed to and stored on the LayerManger as
a raw pointer. This has been updated to use a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D32230
--HG--
extra : moz-landing-system : lando
To avoid hitting the assertion for ResizeObserver, which calls GetBBox()
for all SVG elements.
Note:
If the target has SVG layout and its primary frame cannot be queries as
nsSVGDisplayableFrame, we return a default gfxRect(). And always
returning a default gfxRect() on <view> or <stop> element makes ResizeObserver
doesn't report it (because it is always not active). This behavior
is the same as what Google Chrome has. (i.e. No event is fired.)
Differential Revision: https://phabricator.services.mozilla.com/D32904
--HG--
extra : moz-landing-system : lando
This code was added over 9 years ago per a request from Firefox UX but it has never been used.
This does not affect the What's New page.
Differential Revision: https://phabricator.services.mozilla.com/D32903
--HG--
extra : moz-landing-system : lando
mozalloc_abort and related abort functions are the top frame for many
different, unrelated crashes because they happen to be the standard way to
abort execution. That makes it difficult to properly classify and deal with
intermittent failures.
This patch changes our crash handling behavior so that we try to skip any
frames at the top of the stack that are in generic abort functions, and use
the topmost frame which is actually relevant to the crash reason instead.
Differential Revision: https://phabricator.services.mozilla.com/D33051
--HG--
extra : moz-landing-system : lando
globalThis was already handled specially in JS_ResolveStandardClass,
JS_MayResolveStandardClass, and various other places, but not in
JS_NewEnumerateStandardClasses.
Differential Revision: https://phabricator.services.mozilla.com/D32045
--HG--
extra : moz-landing-system : lando
This fixes the issue in a few redundant ways:
* nsProfileLock is made to properly clean itself up when destroyed.
* nsRemoteService makes sure the unlock when destroyed.
* nsAppRunner unlocks when a remote client has been found.
Differential Revision: https://phabricator.services.mozilla.com/D32360
--HG--
extra : moz-landing-system : lando
This test only contains simple API behavior test, which is not possible to be affected by web-render.
Differential Revision: https://phabricator.services.mozilla.com/D32870
--HG--
extra : moz-landing-system : lando
Incremental effort to improve android-hw device availability: Stop running android-hw
debug jsreftest and jittest on integration branches.
Also, remove the option for android-hw opt jittest on try. opt is a nice alternative
to pgo on try in general, but the risk of accidental (unnecessary) inclusion in
try pushes makes this a luxury we cannot afford on android-hw.
Differential Revision: https://phabricator.services.mozilla.com/D33156
--HG--
extra : moz-landing-system : lando
The renaming of MediaWebspeechRecognitionEnable to
media_webspeech_recognition_enable is to follow the StaticPrefs convention,
because bindings are going to assume that convention.
Differential Revision: https://phabricator.services.mozilla.com/D32942
--HG--
extra : moz-landing-system : lando
This follows the model set down for EME artifacts:
- a new tier is added that uses a new Python build action to fetch and
artifacts
- the action unpacks the fetched artifacts and moves specific inputs
into places expected by the build and packager
- in automation, MOZ_ARTIFACT_TASK* is used to ensure the artifacts
come from the correct tasks
In this case, the artifact fetching is done entirely in a new Python
build action that internally uses `mach artifact install --job ...`.
The action also verifies that the fetched artifacts are compatible and
that we're not assembling a fat AAR that is nonsensical. The specific
inputs are not used in the Fennec APK that is produced; they're only
used in the GeckoView AAR that is produced.
The artifact fetching itself required tweaking to fetch only
`target.maven.zip` artifacts and to not unpack them.
The specific inputs used are the native libraries (libs/$ARCH/*.so)
and the architecture-specific preference files ($ARCH/greprefs.js and
defaults/pref/$ARCH/geckoview-prefs.js). None of these inputs are
impacted by l10n.
Differential Revision: https://phabricator.services.mozilla.com/D31572
--HG--
extra : moz-landing-system : lando
This allows to use the existing artifacts VCS-based crawling to
download the "raw" target.maven.zip from Android jobs and not process
it further. It's just put in a specific directory, ready for use.
This isn't a big deal in automation, where all URLs are known, but
it's very useful when building locally and the VCS and the pushlog
must be consulted to determine task URLs.
Differential Revision: https://phabricator.services.mozilla.com/D31571
--HG--
extra : moz-landing-system : lando
