Regression from bug 1643540.
Debugger.findSourceURLs is recording all sources except the one having an `introductionScript` defined.
i.e. the one being added dynamically and not part of the original HTML content (at least that the expectation of findSourceURLs)
It is important to use the same filtering in ThreadActor, otherwise we may not populate `urlMap`
correctly and call resurrectSource for sources that were recorded by findSourceURLs.
This would introduce duplicated Debugger.Source and SourceActor for the same URL.
Differential Revision: https://phabricator.services.mozilla.com/D132218
I'm adding one test for each Debugger.Source's introductionType
which was not covered yet.
Except for eventHandler and domTimer, which require some additional fix (see next changeset).
Differential Revision: https://phabricator.services.mozilla.com/D132217
Regression from bug 1643540.
Debugger.findSourceURLs is recording all sources except the one having an `introductionScript` defined.
i.e. the one being added dynamically and not part of the original HTML content (at least that the expectation of findSourceURLs)
It is important to use the same filtering in ThreadActor, otherwise we may not populate `urlMap`
correctly and call resurrectSource for sources that were recorded by findSourceURLs.
This would introduce duplicated Debugger.Source and SourceActor for the same URL.
Differential Revision: https://phabricator.services.mozilla.com/D132218
I'm adding one test for each Debugger.Source's introductionType
which was not covered yet.
Except for eventHandler and domTimer, which require some additional fix (see next changeset).
Differential Revision: https://phabricator.services.mozilla.com/D132217
Previously, we were using `UniquePtr<..>` for `CompilationStencil`, which is ok
to move, as we have the garantee that we have a single entity.
However, as we replaced the `UniquePtr<..>` by `RefPtr<..>`, using a move can be
considered harmful if more than one reference exists. This patch changes usage
of `CompilationStencil&&` by `RefPtr<CompilationStencil>&&`, and check the
number of references before moving the content out of the CompilationStencil.
Differential Revision: https://phabricator.services.mozilla.com/D132726
Currently, CompilationStencil are used both as UniquePtr and RefPtr which is
risky. This patch replaces all uses of UniquePtr by RefPtr, and
already_addRefed, such that we either have or not reference counted Stencils.
Differential Revision: https://phabricator.services.mozilla.com/D132695
RefPtr<CompilationStencil> would be used for caching the result of compilation
which might be reused by other functions inside SpiderMonkey. However, many
compilation functions are returning UniquePtr<CompilationStencil>.
Converting a RefPtr<..> to a UniquePtr<..>, when the ref-count is not equal to
1, or when the value still exists in a cache will cause some UAF. This assertion
prevents such mistake to happen in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D132694
To rewrite debugger API test that uses JSScript-based off-thread testing
functions with stencil-based testing functions, support debugger "onNewScript"
callback in `evalStencil` and `evalStencilXDR`.
Differential Revision: https://phabricator.services.mozilla.com/D132874
To replace JSScript-based off-thread testing functions with stencil-based
testing functions, support "elements" and "elementAttributeName" options in
`evalStencil` and `evalStencilXDR`.
Differential Revision: https://phabricator.services.mozilla.com/D132873
Previously, the screenOrientation.lock API was for Fennec and not supported for Fenix and multi-process use. The overall idea is to now allow apps to use the API through a delegate and make asynchronous calls to LockDeviceOrientation. This required replacing the existing code that returned a default false bool to calls that perform the requested orientation change and instead return a promise that contained either an allow or deny value.
Returning a promise instead of a bool involved changing the API calls from the C++ side to Java. The new general control flow of screenOrientation lock follows: an app calls C++ ScreenOrientation.lock() which eventually dispatches LockOrientationTask to resolve the pending orientation promise. Hal.cpp sends an IPC call to the content process and RecvLockScreenOrientation retrieves the current instance of geckoRuntime and calls the java side LockScreenOrientation. Apps must create a delegate and override onOrientationLock to set the requested orientation. In geckoview's testing, this is done with the android API setRequestedOrientation. Once a device orientation change has been triggered, native OnOrientationChange calls to NotifyScreenConfigurationChange, which notifies all observers and dispatches a change event to resolve the pending orientation promise.
Testing:
I used a demo on the GeckoView Example (https://usefulangle.com/demos/105/screen.html) to test locking to landscape orientation. This required a change to the GVE to show the app from recreating the whole thing on orientation change. In the example AndroidManifest xml file, `orientation` prevents restart when orientation changes.
The Junit/Kotlin tests were to verify that the expected orientation delegate was called with the expected new orientation value, in an orientation change, if the new orientation was the same as the current, and if the pre-lock conditions such as being fullscreen were not met.
A static preference `dom.screenorientation.allow-lock` was added to the dom group, since it affects the ui dom) and is currently turned off. C++ can access it through its mirrored variable dom_screenorientation_allow_lock (same name but with underscores). The junit tests turn the preference on and test the lock feature.
Reference:
Orientation constant values:
C++
1 ScreenOrientation_PortraitPrimary); - vertical with button at bottom
2 ScreenOrientation_PortraitSecondary); - vertical with button at top
4 ScreenOrientation_LandscapePrimary); - horizational w button right
8 ScreenOrientation_LandscapeSecondary); - horization button left
16 ScreenOrientation_Default);
Java
1 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_PRIMARY.value
2 GeckoScreenOrientation.ScreenOrientation.PORTRAIT_SECONDARY.value
4 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_PRIMARY.value
8 GeckoScreenOrientation.ScreenOrientation.LANDSCAPE_SECONDARY.value
Java public API
0 ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE
1 Activitynfo.SCREEN_ORIENTATION_PORTRAIT
Android
1 ORIENTATION_PORTRAIT
2 ORIENTATION_LANDSCAPE
Differential Revision: https://phabricator.services.mozilla.com/D129427
If mTTL is initialized to UINT32_MAX then the update condition when
adding a new IP via DOHResp::Add will never be triggered (a TTL can
never be larger than UINT32_MAX).
So it is better to have it be initialized to 0.
Differential Revision: https://phabricator.services.mozilla.com/D132697
I confused myself for a while worrying about who keeps the stubs code alive
if an instance creates a stub for an imported function in a table that it
then exports; the stub-creating instance could subsequently die without the
table dying. But since the stub-creating instance's tls is stored in the table
with the stub, this is fine. Just clarifying this.
Differential Revision: https://phabricator.services.mozilla.com/D132554
In certain situations (such as a print preview dialog, with fission
enabled, where an iframe spans a page), the display list contains
a reference to the same iframe multiple times.
Handle this in WR by namespacing the spatial id (via a stack as
iframes are traversed) and uid (by iframe pipeline instance id).
This is more of a band-aid fix than a proper fix - we need to
rethink how we handle spatial mapping properly with iframe
instances.
Differential Revision: https://phabricator.services.mozilla.com/D132661
Since bug 1670545 we unconditionally override the `mesa_glthread`
env var when using the EGL backend on X11 to avoid crashes.
Unfortunately this triggers warnings from Mesa, cluttering debug
logs.
Let's not override the variable if it's not set. Also lets log an
explicitly warning that we disabled it so users know that the
variable is causing troubles.
Differential Revision: https://phabricator.services.mozilla.com/D132858
This seems to have better cache locality on typical workloads, because objects
that are tenured are now more likely to be fixed up shortly after. It's also easier
to implement.
Some benchmarks (Speedometer, ARES6, various Octane subtests like TypeScript) improve
a bit so this seems worth trying to see how it affects telemetry data in the browser.
Differential Revision: https://phabricator.services.mozilla.com/D132798
