Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--HG--
extra : moz-landing-system : lando
Stopping the tracks as happens in cleanup makes the media element end playback,
which fires durationchange. It doesn't fail the test since it already finished,
but having it show up in the log is distracting.
Depends on D34707
Differential Revision: https://phabricator.services.mozilla.com/D34708
--HG--
extra : moz-landing-system : lando
This patch implements the majority of the planned picture caching
improvements. It supports most of the functionality required to
(as a follow up) support OS compositor integration. It also improves
on the robustness and functionality of the previous picture caching
implementation.
There are some expected temporary performance regressions in
some cases (such as content that is constantly invalidating) and
during initial page render when many render targets must be drawn
to. These performance regressions will be resolved in follow up
commits by supporting multi-resolution tiles.
The scene is split into a number of slices, determined by the scroll
root of each primitive, which can be found by the primitive's
spatial node indices. If a scene contains too many slices, then
picture caching is disabled on the page, to avoid excessive texture
memory usage, and rendering falls back to rasterizing each frame.
The specific changes in this patch are:
* Support tile caches for multiple scroll roots, allowing the
entire page (including fixed divs and the main UI bar) to be
cached in most cases, in addition to the main content.
* Remove requirement to read tiles back from the framebuffer.
Instead, they are drawn into the picture cache target tiles,
and blitted to the screen. This is slightly slower than the
existing picture caching when content is constantly changing,
however this cost will disappear / become irrelevant when
the OS compositor integration work is complete.
* Switch picture cache render targets to be nearest sampled (they
are always rendered 1:1) and support depth buffer targets.
* Make use of the external scroll offset support to allow removal
of the primitive correlation hacks in the previous picture
caching implementation. Also allows storing of primitive
dependencies in picture space rather than world space, which
reduces floating point inaccuracies.
* Determine if each tile and picture cache can be considered
opaque. This is used to determine whether subpixel AA text
rendering is available on a slice, and for rendering optimizations
related to disabling blending and/or tile clears.
* Use the clip chain instance results from the recent visibility pass
work to determine clip chain dependencies. This results in fewer
clip item dependencies in tiles, which is faster to check validity
and reduces redundant invalidations.
* Remove extra overhead during batching related to batch lists,
and region iteration, as they are no longer required.
* Support PrimitiveVisibilityMask during batching. This allows a
single traversal of a picture (surface) root during batching to
efficiently construct multiple alpha batcher objects (typically
one per invalida tile).
* Picture caching is now handled implicitly by WR, depending on
the content of the scene. There is no requirement for client
code to manually select which stacking context should be cached.
* Simplify how clip chain / transform dependencies are tracked by
picture cache tiles.
* Support pushing / popping enclosing clip chain roots without
the need for a stacking context / picture in some cases. This
simplifies the logic to split the scene into multiple slices.
The main remaining work in this area is (a) extend the code to
optionally provide each slice as an input to the OS compositor
rather than drawing the tiles in WR, and (b) support multi-resolution
tiles so that we reduce the draw call, batching and render target
overhead in cases where much of the page content is changing.
Differential Revision: https://phabricator.services.mozilla.com/D34319
--HG--
extra : moz-landing-system : lando
Since bug 1535137 the consts array only stores `BigIntValues` so we can change
it to a `BigInt` array. This will also make it easier to fix bug 1535154.
Differential Revision: https://phabricator.services.mozilla.com/D34712
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
IsMarkingTracer no-longer exists, so remove one comment that refers to it
and fix another comment.
Differential Revision: https://phabricator.services.mozilla.com/D34674
--HG--
extra : moz-landing-system : lando
This test was failing due to the tab closing before a response from the tab was recieved.
It is due to the threadClient closing more quickly. This waits for the last message before closing
Differential Revision: https://phabricator.services.mozilla.com/D32718
--HG--
extra : moz-landing-system : lando
this test was failing because the threadClient was posting messages due to being unable to
find the source map. After investigating, I found that the sourcemap was formatted incorrectly. I do
not know if this was intentional. If it wasn't this fix works. If it was, then we need to find a way
to wait on source map failures, and the test name might need to be updated
Differential Revision: https://phabricator.services.mozilla.com/D32715
--HG--
extra : moz-landing-system : lando
There was an issue where this test was timing out, and due to the way it was written it was
very hard to identify where -- there were many nested promises. I rewrote the test in order to
identify the time out.
Differential Revision: https://phabricator.services.mozilla.com/D32714
--HG--
extra : moz-landing-system : lando
the test `browser_net_params_sorted` may not have been functioning for some time. While
investigating this, I discovered that we were getting an empty array for `actualKeys`. Iterating
over this array returned immediately. As a result the test always passed, even though the shape of
the data changed. I updated this code so that it waits for the dom to be populated with the number
of keys expected. I also updated the test to reflect the data the front end has today.
Differential Revision: https://phabricator.services.mozilla.com/D32713
--HG--
extra : moz-landing-system : lando
There were a few miscellaneous situations in which the test would fail due to a hanging
request. These tests passed in the past because the old way of using the threadActor did not
identify which requests had been responded to.
Differential Revision: https://phabricator.services.mozilla.com/D32711
--HG--
extra : moz-landing-system : lando
Member variables `calledPrepareVMCall_` and `inStubFrame_` served the same purpose for their classes.
Unified them in CacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D33526
--HG--
extra : moz-landing-system : lando
Base commit for bug 1467191. Moves declarations of BaselineCacheIRCompiler and IonCacheIRCompiler
into their respective header files.
Differential Revision: https://phabricator.services.mozilla.com/D33521
--HG--
extra : moz-landing-system : lando
Base commit for patch for bug 1467191 that fixes inconsistencies in
namespace use between BaselineCacheIRCompiler and IonCacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D33516
--HG--
extra : moz-landing-system : lando
The regressor Bug 1248708 inadvertently changed the behavior for opacity 0 text
when implementing -webkit-text-stroke. It treats all opacity 0 text as drawing stroke
even if the stroke property isn't used in the first place.
We should check aParams.textStrokeWidth is actually set before changing draw mode.
Differential Revision: https://phabricator.services.mozilla.com/D34663
--HG--
extra : moz-landing-system : lando
This is consistent with the scroll area events too, and allows us to
remove the WillPaintObserver stuff.
Differential Revision: https://phabricator.services.mozilla.com/D5271
--HG--
extra : moz-landing-system : lando
On MacOSX, especially on MacOS 10.10, the toolbar paint flush happens along
with the urlbar flickers.
Differential Revision: https://phabricator.services.mozilla.com/D34489
--HG--
extra : moz-landing-system : lando
Previously, BrowserBridgeChild::SendSetEmbedderAccessible was only called when an OuterDocAccessible was constructed.
However, it's also possible that the BrowserBridgeChild is created *after* the OuterDocAccessible.
Therefore, we must also do this when a BrowserBridgeChild is created if the OuterDocAccessible already exists.
Differential Revision: https://phabricator.services.mozilla.com/D34474
--HG--
extra : moz-landing-system : lando
The test is supposed to test that changing the preference layers.acceleration.disabled doesn't cause a crash, but this pref is only read on startup well before the test has a chance to run and switch the pref.
It's not doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D34781
--HG--
extra : moz-landing-system : lando
