This allows us to explicitly specify BrowsingContextGroups when synchronizing
them. A major advantage of this is that it means we can handle an attempt to
create a BrowsingContext with a parent which the content process is unaware of,
which is possible due to changes to the EnsureSubscribed logic in earlier
patches in this stack.
This is OK, because in the case where the content process cannot see its parent,
the parent must be imminently discarding.
Differential Revision: https://phabricator.services.mozilla.com/D71668
The existing infrastructure which stored cached BrowsingContexts on the
BrowsingContextGroup was added before WindowContexts were added, and can cause
racing issues with partially discarded trees during process switches.
Differential Revision: https://phabricator.services.mozilla.com/D71238
There were previously a number of different APIs for creating BrowsingContext
instances. This simplifies them into two major cases: "CreateDetached", which
allows for creating BrowsingContexts which are related to other
BrowsingContexts, and "CreateIndependent" which creates new, fully unrelated,
browsing contexts.
Differential Revision: https://phabricator.services.mozilla.com/D71237
Follow-up parts in this bug depend on being able to read the `nsGlobalWindow`
which embeds a `nsFrameLoader` within `CreateBrowsingContext`, which is called
from the `nsFrameLoader` constructor. Unfortunately, we depend on creating the
`nsFrameLoader` and `BrowsingContext` before we have the window as part of the
fix to bug 1577711.
This patch changes `BuildNestedPrintObjects` to instead use a list of pending
clones stored on the parent `Document` object, and delays creation of the
`nsFrameLoader`, and thus the inner `BrowsingContext`, until after the document
has an owner global.
Due to the low number of automated tests for printing, I manually tested
print-previewing both the reduced test case from bug 1577711, a wikipedia
article, and 'data:text/html,<object data="data:text/html,hi">' to avoid
regressions.
Differential Revision: https://phabricator.services.mozilla.com/D71236
This patch adds the new live site tests as Raptor-Browsertime tasks in CI. These will be scheduled to run through the general-perf-testing cron task on Monday/Wednesday/Friday.
Differential Revision: https://phabricator.services.mozilla.com/D69053
This patch adds some new live-site-only tests to Raptor-Browsertime, these will run on Fenix, & Chrome in CI but are enabled for all mobile browsers. The live sites reside in a new `live` folder since they can be used on desktop and mobile if needed.
Differential Revision: https://phabricator.services.mozilla.com/D69052
This is the first patch of a multi-part patch to enable live site testing on Google Chrome for Android and Fenix. It adds the `--live-sites` command line option that disables the mozproxy playback (or enables live sites) when it is supplied.
Differential Revision: https://phabricator.services.mozilla.com/D69051
If we're shutting down and mSocketThread is no longer accepting work,
this dispatch can fail. As far as I can see, fully fixing this would
require changes to nsIThread in order to allow checking whether the
thread is shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D71964
This way, something like:
*:where(.foo, .bar)
Will end up twice on the selector map, just as if you would've written
.foo, .bar.
But we're a bit careful to not be wasteful, so:
.foo:where(div, span)
Will still end up using the .foo bucket.
It needs a bit of borrow-checker gymnastics to avoid cloning the entry
in the common path. It's a bit gross but not too terrible I think.
Differential Revision: https://phabricator.services.mozilla.com/D71457
There are a bunch of missing tests, and there are some tests that don't
match the current spec text, that I need to write or fix before I enable the
feature everywhere.
But there are fairly complex invalidation tests, that we pass flawlessly :)
Differential Revision: https://phabricator.services.mozilla.com/D71424
See the comment about why this is valuable. For a selector like:
.foo:is(.bar) > .baz
Before this patch we'd generate an Dependency for .bar like this:
Dependency {
selector: .bar,
offset: 0,
parent: Some(Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}),
}
After this patch we'd generate just:
Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}
This is not only less memory but also less work. The reason for that is that,
before this patch, when .bar changes, we'd look the dependency, and see there's
a parent, and then scan that, so we'd match `.bar` two times, one for the
initial dependency, and one for .foo:is(.bar).
Instead, with this we'd only check `.foo:is(.bar)` once.
Differential Revision: https://phabricator.services.mozilla.com/D71423
That way we can look at the parent dependency as described in the previous
patch. An alternative would be to add a:
parent_dependency: Option<&'a Dependency>
on construction to `Invalidation`, but this way seems slightly better to avoid
growing the struct. It's not even one more indirection because the selector is
contained directly in the Dependency struct.
Differential Revision: https://phabricator.services.mozilla.com/D71422
The tricky part of :is() and :where() is that they can have combinators inside,
so something like this is valid:
foo:is(#bar > .baz) ~ taz
The current invalidation logic is based on the assumption that you can
represent a combinator as a (selector, offset) tuple, which are stored in the
Dependency struct. This assumption breaks with :is() and :where(), so we need
to make them be able to represent a combinator in an "inner" selector.
For this purpose, we add a `parent` dependency. With it, when invalidating
inside the `:is()` we can represent combinators inside as a stack.
The basic idea is that, for the example above, when an id of "bar" is added or
removed, we'd find a dependency like:
Dependency {
selector: #bar > .baz,
offset: 1, // pointing to the `>` combinator
parent: Some(Dependency {
selector: foo:is(#bar > .baz) > taz,
offset: 1, // Pointing to the `~` combinator.
parent: None,
})
}
That way, we'd start matching at the element that changed, towards the right,
and if we find an element that matches .baz, instead of invalidating that
element, we'd look at the parent dependency, then double-check that the whole
left-hand-side of the selector (foo:is(#bar > .baz)) actually changed, and then
keep invalidating to the right using the parent dependency as usual.
This patch only builds the data structure and keeps the code compiling, the
actual invalidation work will come in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D71421
When running e.g. check_symbols with extra flags like when checking
for vpx_codec_dec_init_ver when building against system libvpx, in some
configurations, the test can fail when the library flags (-l) appear
before the source file path.
The reason is that in some configurations, the compiler passes
--as-needed to the linker before both the flags and the object file
path, and the object file path is in the same position as the source
file path was. With --as-needed, -l flags are dropped if the library
wasn't needed for any of the linked code that appears *before* the flag.
So linking with `--as-needed -lfoo foo.o`, is equivalent to linking with
`foo.o` only in practice, while `--as-needed foo.o -lfoo` is equivalent
to `foo.o -lfoo`.
Differential Revision: https://phabricator.services.mozilla.com/D71456
We're back to an explicit --android option and --android-app-name, the layer won't use the --browser-binary option as an implicit
fallback anymore. This is cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D72031
Separating out the generic clip definition API into image masks
(and other types in future) makes the serialized data smaller. More
importantly, it will allow us to simplify some of the WR clip internals
in future and optimize the performance spent in clip chain handling.
Differential Revision: https://phabricator.services.mozilla.com/D72125
