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
Juggler code had a bug where we subscribed to window and tab
events, but did not iterate collections of current windows and tabs.
As a result, we were sometimes failing to set viewport size for the
initial window, and implemented an artificial promise to workaround
the problem.
This patch:
- starts calling `onOpenWindow` and `onOpenTabListener` callbacks
for *all* windows and tabs - current and future, eliminating the
race condition.
This worked too well and we started overriding window sizes that
were set by users with `window.open(url, 'width=300;height=400')` (we
have a test for this). To fix this, we now plumb `CHROME_WITH_SIZE`
flag from appWindow and override viewport iff this flag is not set.
After this patch, we will use the `onTabOpened` event to move user
agent emulation to the browser-side.
References #3995
`MediaFeatureValuesChanged` is what their devtools code uses to update the styles. I tried using their code directly, but it doesn't play nicely with navigations so I decided to stick with ours.
When innerWindow is restored from the history state, we do not receive
content-document-global-created notification, but would still like to know
that window is now using a different inner window to reset the state.
This introduces a new notification juggler-dom-window-reused.
At the same time, goBack()/goForward() sometimes do not initiate
navigation synchronously, so our check for pendingNaivgationId() does
not work. Instead, we rely on canGoBack, and assume that client will
not need the navigationId synchronously.
