This avoids doing wasted work and sending spurious resize
events if this case would be hit.
In practice, it cannot be hit yet, I think, because
callers do check for this and bail out earlier. But
there's no assertion to that respect so this shouldn't
hurt.
Differential Revision: https://phabricator.services.mozilla.com/D43798
--HG--
extra : moz-landing-system : lando
Changes:
- run `awsy` related tests on all platforms except for `mozilla-esr.*`.
Differential Revision: https://phabricator.services.mozilla.com/D43133
--HG--
extra : moz-landing-system : lando
The idea here is that we avoid updating all site data in SiteDataManager.jsm
just for checking a single host/origin and that we optimize performance by prioritizing
the most common data type (cookies) and synchronous lookups (AppCache) and returning
early if any data was found.
We will still refresh the site data list for clearing once the user clicks on "Clear Site Data".
Differential Revision: https://phabricator.services.mozilla.com/D42800
--HG--
extra : moz-landing-system : lando
In automation, we install `ffmpeg` as part of `mach browsertime
--setup` in the browsertime toolchain task. Those tasks run on Linux
64 from within AWS, and most of the hosts we hit (intermittently) deny
AWS traffic. Let's just use github.com in automation (and locally),
for all platforms, which will agree with upcoming fetch tasks.
Differential Revision: https://phabricator.services.mozilla.com/D43656
--HG--
extra : moz-landing-system : lando
There was quite a bit of discussion of this in `#build` on IRC,
and the consensus was that geckodriver should be built as a
stand-alone Rust crate and not as part of Firefox/Gecko (say, as a new
--enable-project target). This follows that approach, and the
expression, modeled off of cbindgen but updated to cross compile from
a Linux host to all targets, is pretty straight-forward.
A sparse profile would be nice, but the way that the Gecko Cargo
workspace works means that the profile must accumulate Rust code from
many locations.
If we want to, eventually testing/geckodriver can be removed from the
top-level Rust workspace, the geckodriver-signing tasks migrated to
these toolchain tasks, consumers migrated to the signing tasks, and
geckodriver removed from the "common" test archive.
Differential Revision: https://phabricator.services.mozilla.com/D43646
--HG--
rename : taskcluster/scripts/misc/vs-setup.sh => taskcluster/scripts/misc/vs-setup32.sh
extra : moz-landing-system : lando
The `zip` dependency doesn't appear to require `bzip2`, and `bzip2` is
tricky to cross-compile, so the feature set is restricted to ease the
build task.
Differential Revision: https://phabricator.services.mozilla.com/D43645
--HG--
extra : moz-landing-system : lando
Naming this field better matches the intent of the field, other actions, and
the schemas used by the recipes on the server. Overall it makes the code less
confusing, and more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D41296
--HG--
extra : moz-landing-system : lando
This patch adds a new Scalar metric `os.environment.is_admin_without_uac` that
indicates the process is lauched with Admin privileges when UAC is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D42047
--HG--
extra : moz-landing-system : lando
This also sets the fission.rebuild_frameloaders_on_remoteness_change=true
preference for some mochitest directories which require it for cross-process
window.opener to work in top-level windows, and makes a minor change to the
hack in browser_temporary_permissions.js to keep it passing reliably in try
runs.
Differential Revision: https://phabricator.services.mozilla.com/D43694
--HG--
extra : moz-landing-system : lando
Also adds a legacy `GetSameProcessOpener()` method for callers which can only
deal with in-process windows and may need to be updated for Fission.
Differential Revision: https://phabricator.services.mozilla.com/D43692
--HG--
extra : moz-landing-system : lando
We currently handler this correctly for the opener stored on the outer window,
but not on the BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D43691
--HG--
extra : moz-landing-system : lando
This is currently only available on the outer window, but needs to move to
BrowsingContext in order from us to remove redundant opener tracking from the
former.
Differential Revision: https://phabricator.services.mozilla.com/D43690
--HG--
extra : moz-landing-system : lando
Compilers have gotten a lot better since the last time we tried this, and the
generated SIMD code for the inlined memcmp is more efficient than our manual
comparison operations.
Differential Revision: https://phabricator.services.mozilla.com/D43802
--HG--
extra : moz-landing-system : lando
Move disconnection message out of Toolbox class in favor of toolbox-init module
as that is specific to Toolbox loaded in a tab.
We do that in order to stop automatically destroying the toolbox when the
attached target is destroyed. This will help support switching to another target
when we navigate between two documents loaded in distinct processes.
We will now destroy the toolboxes for local tabs only when TabClose event
is fired.
Differential Revision: https://phabricator.services.mozilla.com/D40233
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/from a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
Depends on D43639
This will avoid applying High Contrast mode colors to devtools documents even when DevTools are loaded in a frame with type=content
This behavior can be disabled by setting devtools.toolbox.force-chrome-prefs to false
Differential Revision: https://phabricator.services.mozilla.com/D43614
--HG--
extra : moz-landing-system : lando
This is a remnant from the previous implementation of masking. That
implementation was replaced in bug 1447880.
Differential Revision: https://phabricator.services.mozilla.com/D43763
--HG--
extra : moz-landing-system : lando
Now that there is an {IPDL}ParamTraits implementation for nsIPrincipal* and
nsIContentSecurityPolicy*, we need not manually transform it to/form a
PrincipalInfo/CSPInfo ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D36637
--HG--
extra : moz-landing-system : lando
The members of nsIWebProgressListener2 were added to BrowserChild (then
TabChild) in commit 1028814583232487b52b9c20d47e3b38dc1c288a, but the interface
was never added to the interface map.
Differential Revision: https://phabricator.services.mozilla.com/D35134
--HG--
extra : moz-landing-system : lando
This is the last message that WebProgressChild was sending to the
RemoteWebProgress in the parent process, so we can remove the module entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35091
--HG--
extra : moz-landing-system : lando
