This roll:
- NetworkObserver now uses the `remote's` ChannelEventSink layer to
subscribe to redirects.
- Wheel events now must be dispatched from browser process.
- There's a new API for console messages
- The old methods to wait for search service and addon manager no longer
work; speculatively remove them since neither `remote` nor
`marionette` have anything like this.
Native manual merge: 9e6fcfd868
> lgtm % null-check for the docshell
The code is inside following if condition
```
if (auto* browserChild = BrowserChild::GetFrom(root->GetDocShell())) {
```
which ensures that the doc shell is not null.
Review URL: aff16fc8e4
This patch fixes 2 firefox crashers:
- color scheme override code was not used, but was called
from multiple threads, which caused a weakptr use violation (cannot
be used from multiple threads)
- snapshot listener callback was reset asynchronously, so when
`HeadlessWindowCapturer` was destroyed, it was still occasionally
called (see `HeadlessWindowCapturer::~HeadlessWindowCapturer`)
With this patch, I no londer experience tracing crashes in firefox.
References #10259
This patch adds Firefox cross-compilation from x86_64 Ubuntu 20.04 to
arm64 Ubuntu 20.04.
This patch also fixes packaging logic for Firefox to use a STRIP
command from the aarch64 toolchain.
References #7723
Merging conflicts:
038f367c30
After this roll, we no longer require our custom `onFrameLocationChanged` instrumentation
since gecko now fixed the `NOTIFY_LOCATION` behavior so that it works
for same-document navigations inside iframes.
browser(firefox): properly initialize debugging pipe on windows
Firefox on Windows has 2 launch modes:
- default: a special "launcher process" is used to start browser as a
sub-process
- non-default: browser process starts right away
Firefox has a logic to detect how successful was the use of the
launcher process to do self-recovery when things go wrong. Namely:
- when attempting to use launcher process, firefox records a timestamp
of the attempt beginning
- once the launcher process successfully launches browser sub-process,
firefox records another timestamp of the completion
On a new launch, firefox checks what timestamps are present. If there's
a timestamp that signifies start of launcher process, but no successful
timestamp, it decides that last "launcher process" use was not
successful and falls back to launching browser right away.
When launching 2 firefox processes right away, the first process
uses attempts to use launcher process and records the first timestamp.
At the same time, the second instance sees the first timestamp and
doesn't see the second timestamp, and falls back to launching browser
right away. Our debugging pipe code, however, does not support
non-launcher-process code path.
This patch adds support for remote debugging pipe in case of
non-launcher-process startup.
Drive-by:
- disable crashreporter altogether
- remove stray dcheck that breaks firefox debug compilation
- disable compilation of firefox update agent
- do not use WIN32_DISTRIB flag unless doing full builds since
it kills incremental compilation
References #4660
Yury Semikhatsky