When starting the profiler, also make a copy of the filter strings
converted to lower-case. This allows caseless comparisons to be made
against thread names without repeatedly converting the filters to
lower-case for each thread.
Differential Revision: https://phabricator.services.mozilla.com/D123302
Add an interface (and update Gecko to provide) a stable unique
identifier for each spatial node that is consistent across
display lists.
Although this patch doesn't _do_ anything useful with this yet,
we'll use this in future to allow interning, persisting and caching
a lot more information related to primitives and clips.
For now, it just asserts that the calling code never supplies a
duplicate unique identifier - which will be useful to have running
in nightly for a couple of weeks before starting to make use of
these identifiers.
Differential Revision: https://phabricator.services.mozilla.com/D123177
Depending on glean creates a circular dependency as glean depends on
glean-native which is substituted with GeckoView in omni builds.
Since Gradle 6 capabilities are passed on to consumers using the Gradle Module
Metadata, so now we can just define a glean capability in GeckoView and Fenix
will consume glean-native from GeckoView instead of adding a duplicated
libglean blob (there is code in the glean plugin to make sure this happens).
See also: https://docs.gradle.org/current/userguide/component_capabilities.html
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123572
There's a lot of code that we don't need anymore in our publication path (I'm
assuming it was needed when it was written but then gradle/the android plugin
caught up).
This has the nice side effect of producing better metadata (e.g. our
implementation dependencies end up in the |runtime| dependency group instead of
the default one where they were before, which means the app doesn't inherit our
private dependencies).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123571
This is the last version that doesn't require Java 11, we will upgrade to
Gradle 7 once all components are ready (namely, apilint).
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>
Differential Revision: https://phabricator.services.mozilla.com/D123569
Add several test cases to cover our cbcs path. These test a number of different
patterns. These patterns are
- 1:9, 5:5, 10:0. These are more conventional patterns.
- 7:7, 9:8. These are not conventional. Both go against the spec by not summing
to 10. This tests we can appropriately handle unconventional cases.
Note that the spec says patterns should only be applied to video tracks. So in
all cases the audio actually use 0:0 (full encryption). So these test cases also
cover the 0:0 case.
Differential Revision: https://phabricator.services.mozilla.com/D123498
This change instead recovers from unhandled special messages by reporting a
normal IPC error, which should be handled using the normal IPC error
mechanisms.
Depends on D123148
Differential Revision: https://phabricator.services.mozilla.com/D123149
When this change was first implemented, it ignored dead actors for all types of
messages, but for messages with replies they cannot be ignored, as a reply must
be sent. This should fix that oversight.
Differential Revision: https://phabricator.services.mozilla.com/D123148
After some investigation, I was able to find a theoretical codepath
which could lead to the "missing initial frame browsing context" error:
1. Two iframes are created for the same origin, and begin process
switching.
2. The first iframe finishes process switching, but for some reason
(e.g. being in shutdown) the call to `LaunchSubprocessResolve`
errors.
3. The second callback is called and also calls LaunchSubprocessResolve,
which this time returns `true` due to it previously having been
called.
4. The BrowserParent is created in the new content process despite
`InitInternal()` never having been finished, and therefore the
ContentParent never becoming subscribed to the BrowsingContextGroup.
To fix this, I made 2 changes:
1. Abort from process switching if the target process which we're going
to be creating a BrowserParent in `IsDead()`, and
2. Track the return value from `LaunchSubprocessResolve`, so we return
`false` if it is called a second time after a failed content process
launch.
I'm not confident that this is the cause of the crashes, as I was unable
to reproduce the issue.
Differential Revision: https://phabricator.services.mozilla.com/D123548
All these tests most likely have been fixed with the enabling of server targets.
Because bfcache in parent was introducing more cross process navigations,
being initiated from the server, having the support of server targets was uterly
important to support bfcacheInParent.
Differential Revision: https://phabricator.services.mozilla.com/D123448
