It turns out that patch for bug 1698543 was too optimistic and we need the special case barrier for rope flattening for another reason: during flattening rope nodes are transformed before their ancestors. Interior rope nodes are transformed to dependent strings with the base being the root node, and the root transformed into a linear string. Since the root is changed last the GC graph is not safe to traverse until flattening has finished.
This makes the test case pass. I added this test case and the one for the previous bug. I don't think we need to hide these since this change has only been on nightly so far.
If there are futher issues with this then I'm going to back out the barrier changes and think about an alteranative approach.
Differential Revision: https://phabricator.services.mozilla.com/D108979
Previously, the DocGroup type was not cycle-collected, as it needed to have
references from other threads for Quantum DOM. Nowadays the only off-main-thread
use of DocGroup is for dispatching runnables to the main thread which should be
tracked using a performance counter for about:performance. This means we can
remove the DocGroup references from these dispatching callsites, only storing
the Performance Counter we're interested in, and simplify make DocGroup be
cycle-collected itself.
This fixes a leak caused by adding the WindowGlobalChild getter to
WindowContext, by allowing cycles between the document and its BrowsingContext
to be broken by the cycle-collector.
Differential Revision: https://phabricator.services.mozilla.com/D108865
This should further reduce the chance that a BrowsingContextGroup is mentioned
in a message which has already ben destroyed by a remote process.
Differential Revision: https://phabricator.services.mozilla.com/D108121
This allows for the WindowGlobalChild getter in WindowContext to be acquired
more efficiently without performing hashtable lookups, and should generally
simplify things.
The patch also removes the unnecessary XRE_IsContentProcess assertions, and
removes the global hashtable for tracking WindowGlobalChild instances which is
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D108120
Previously it appears that `WindowContext::Discard` was never invoked in the
content process which hosts the window in question, which may have lead to the
crashes mentioned in this issue, among other problems.
Differential Revision: https://phabricator.services.mozilla.com/D108119
When these fields were added, it appears I completely forgot to add them to the
cycle collection unlink logic. This somehow didn't cause leaks due to existing
code which would break the cycles between the inner window and the outer window
/ BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D108118
The issues with BrowsingContextGroup identity may be related to using a
destroyed BrowsingContextGroup in some situations when we shouldn't be. By
upgrading the intensity of these assertions, we should be able to catch the
issues more readily.
Differential Revision: https://phabricator.services.mozilla.com/D108117
Simplify code and improve performance by adding
lazy getters for checks that will be constant
for the whole lifetime of the application process.
Differential Revision: https://phabricator.services.mozilla.com/D107645
Thanks to the previous patch in this series we can now play video
using the non-essl3 GL_OES_EGL_image_external extension, therefore we
no longer require the essl3 version.
It is assumed that all android devices support
GL_OES_EGL_image_external (non-essl3). Even if that is not the case,
webrender is no worse off than layers in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D108909
On android video data is provided to webrender via EGL external
images. Webrender currently relies on the extension
GL_OES_EGL_image_external_essl3 to render these images. Unfortunately,
however, there are a number of devices which support GLES 3, but do
not support GL_OES_EGL_image_external_essl3.
This means we that must use the older GL_OES_EGL_image_external
(non-essl3) extension to render video on such devices. This requires
shaders to be written in ESSL1 rather than ESSL3.
Most of webrender's shaders use too many modern GLSL features to be
compatible with ESSL1. For that reason, this patch implements ESSL1
compatible variants of just the composite and cs_scale shaders, as
they are both relatively simple.
In the happy path, videos are promoted to compositor surfaces and we
simply use this new composite shader variant. In other cases, this
patch makes it so that we use a render task to perform a copy of the
video frame using the cs_scale shader, then the output of that render
task can be rendered using the regular ESSL3 TEXTURE_2D variant of
whatever shader is required. The extra copy is unfortunate, but
rewriting every shader to be ESSL1 compatible is unrealistic.
Differential Revision: https://phabricator.services.mozilla.com/D108908
We used to support having a null delegateController because WebExtension could
be constructed from the app. Now that we can only go through the Controller we
don't need to do that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D108695
This is to fix intermittent failure on all browser toolbox tests.
It looks like these patches make toolbox.destroy shuts down connection faster
and lead to evaluateJSAsync request still be pending while the connection is closed
and actors and fronts are destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D108630
Close method may be called by the transport on close.
This was highlighted by browser_target_from_url.js
Surprisingly devtools/shared/tests/xpcshell/test_debugger_client.js
tries quite hard to cover such issue, but we seem to get yet another type of reentrancy.
This probably depends on WebSocketTransport, which is a bit hard to get covered.
No test seems to be spawning a WebSocket DevToolsServer...
Differential Revision: https://phabricator.services.mozilla.com/D107988
Following the landing of wasm-via-Ion on arm64 (bug 1678097), some obscure
build configurations now break the build due to incorrect target-selection
ifdeffery. This has been observed to happen for x86_64-linux when the
following are specified together (in a browser build):
ac_add_options --enable-cranelift
ac_add_options --enable-js-shell
In particular, `forceWasmIon` is declared in js.cpp and is guarded by
JS_CODEGEN_ARM64. But there were later some uses of it guarded by
ENABLE_WASM_CRANELIFT. In effect this incorrectly assumes that
JS_CODEGEN_ARM64 and ENABLE_WASM_CRANELIFT are both either defined or
undefined. But that's not correct, (eg) for a build on x86_64-linux that is
configured `--enable-cranelift`.
This patch fixes that by guarding such use points *additionally* with
JS_CODEGEN_ARM64, so as to ensure the sets of configurations that read or
write `forceWasmIon` are a subset of the configurations that declare it.
Differential Revision: https://phabricator.services.mozilla.com/D108934
This patch doesn't change behavior; it's just switching us between two
functions that do the same thing. (One is literally a trivial wrapper for the
other.)
We're using the new "InProcess" version of this API as a way of annotating
callsites that have been vetted as behaving properly in out-of-process iframes.
The calls in FrameLayerBuilder.cpp seem to be about deciding how best to form
layers from our frame tree. A layer tree and its associated frames will
always be restricted to all live in a particular process, so it's fine
that we're not able to reach other processes when we're making these decisions.
Differential Revision: https://phabricator.services.mozilla.com/D108902
This could already be achieved by calling standaloneNativeMenu.menuOpened(),
except for the MenuClosed() call.
Depends on D108729
Differential Revision: https://phabricator.services.mozilla.com/D108730
Gijs Kruitbosch
Jon Coppeard
Nika Layzell
Bryce Seager van Dyk
Emilio Cobos Alvarez
Henrik Skupin
Tom Tung
Jamie Nicol
Agi Sferro
Yury Delendik
Eden Chuang
Dylan Roeh
Tim Nguyen
Marcos Cáceres
Stephen A Pohl
Nicolas Chevobbe
Sebastian Hengst
Aki Sasaki
Alexandre Poirot
Mark Striemer
Julian Seward
Kershaw Chang
Daniel Holbert
smolnar
Markus Stange