The `browser_talltabslistener.js` test verifies that (a) certain
`nsIWebProgress` events occur in the correct order and (b) that the events come
from the correct browser. However, the part of the test that listend for
`onStatusChange` messages did not actually confirm that they were triggered or
that the correct number of them were triggered. The ordering of the
`onStatusChange` events with respect to the other `nsIWebProgress` events is
non-deterministic because `onStatusChange` events are filtered through the
`nsBrowserStatusFilter`, which may or may not put them on a delay timer (due to
the message being repeated often).
The presence of this timer makes for a lovely race condition. Now that the
TabChild's onStatusChange event handler is registered earlier (in
`TabChild::Init` instead of the `WebProgressChild.jsm`) we are getting more
`onStatusChange` messages and the race more frequently results in a failing
test. This is due to one of the test cases swapping browsers *but* not
explicitly waiting for all `onStatusChange` events to come in, so the test case
will run with swapped browsers and a `onStatusChange` event from a previous
test case will leak through, causing the test to fail.
The simplest way to fix these tests is to just remove the `onStatusChange`
listeners, since they do not assert whether or not they are received -- the
tests will pass even if no `onStatusChange` events are sent.
Differential Revision: https://phabricator.services.mozilla.com/D25447
--HG--
extra : moz-landing-system : lando
Now that we have access to the RemoteWebProgress from the TabParent and can
construct RemoteWebProgress and RemoteWebProgressRequests in C++, we can
reconstruct the RemoteWebProgress and RemoteWebProgressRequest in the TabParent
instead of RemoteWebProgressManager. This improves the API for nsIBrowser and
RemoteWebProgressManager, removing the need for the
`callWebProgressContentBlockingEventListeners` method in both. It also means we
won't need to implement `callWebProgress*Listeners` for methods on nsIBrowser
and RemoteWebProgressManager for all other nsIWebProgress events.
Differential Revision: https://phabricator.services.mozilla.com/D24942
--HG--
extra : moz-landing-system : lando
The RemoteWebProgressManager is now implemented in terms of a
nsIWebProgressListener. This paves the way for reconstructing the
nsIWebProgress and nsIRequest passed to the event handlers in C++ instead of in
JS and will alllow for a cleaner overall design.
While here, I also cleaned up RemoteWebProgressManager to use the class
syntactic sugar.
Differential Revision: https://phabricator.services.mozilla.com/D24941
--HG--
extra : moz-landing-system : lando
WindowGlobalChild.cpp was relying on several headers already included by other
files in its unified build translation unit, but the addition of the
RemoteWebProgressRequest in the next change bumps them into another translation
unit and breaks the build.
The missing `#include` and `using namespace` statements have been added,
allowing builds to succeed.
Differential Revision: https://phabricator.services.mozilla.com/D24937
--HG--
extra : moz-landing-system : lando
Due to adding a new CPP file in the next change, the unified build fails due to
files being shuffled around between translation units. This change fixes the
build.
Differential Revision: https://phabricator.services.mozilla.com/D24810
--HG--
extra : moz-landing-system : lando
Changing RemoteWebProgress to a C++ XPCOM object will cause the request being
passed into the `onStateChange` handler in `promiseBrowserLoaded` to become a
wrapped XPCOM object for an nsIRequest, instead of the JS object it was
previously. This results in the attribute lookup for `originalURI` on the
request to fail, leading to cascading failures.
Differential Revision: https://phabricator.services.mozilla.com/D24809
--HG--
extra : moz-landing-system : lando
The implementation of WebProgressChild.jsm filters all nsIWebProgress events
through an nsBrowserFilter. We need to do this in the TabChild as well, but
TabChild currently only handles onContentBlockingEvent, for which
nsBrowserFilter only calls the underlying listener.
We also unregister the progress listener much earlier in TabChild::Destroy as
this method causes OnStateChange event to be triggered later on, which we are
not interested in capturing.
Differential Revision: https://phabricator.services.mozilla.com/D24805
--HG--
extra : moz-landing-system : lando
There is already a AC_HAVE_FUNC(localeconv) in js/src/old-configure.in
on non-Windows, and on Windows, HAVE_LOCALECONV is always set.
Differential Revision: https://phabricator.services.mozilla.com/D25903
--HG--
extra : moz-landing-system : lando
There is no specified limit on the number of inputs or outputs, except that
the webidl parameter is unsigned long, but Gecko has an implementation-defined
limit.
Differential Revision: https://phabricator.services.mozilla.com/D25898
--HG--
extra : moz-landing-system : lando
The configuration file format is YAML and looks like:
```
prefs:
foo.bar.boolean: true
foo.bar.string: "string"
foo.bar.int: 500
env:
MOZ_LOG: nsHttp:5
args: [--marionette]
```
By default, if the consuming App is debuggable, GeckoView will read
configuration from `/data/local/tmp/$PACKAGE-geckoview-config.yaml` at
startup.
For consumers (including browsers) that want to allow the underlying
GeckoView to be remote controlled in some way, the
`GeckoRuntimeSettings.Builder.configFilePath()` method allows to avoid
the default behaviour depending on the `android:debuggable` flag. For
example, release versions of Firefox for Android will want to allow
this configuration when appropriate App-level settings are toggled.
The additional configuration is appended after any existing configuration
methods, e.g., after anything specified using Intent argument extras
or existing `GeckoRuntimeSettings.Builder` methods.
Differential Revision: https://phabricator.services.mozilla.com/D25885
--HG--
extra : moz-landing-system : lando
When SurfaceTexture is single buffer mode, UpdateTexImage() should be called only once for each publish. If UpdateTexImage() is called more than once, it causes hand on puglish side.
Differential Revision: https://phabricator.services.mozilla.com/D24483
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
The Set* functions of nsICertStorage (SetRevocationByIssuerAndSerial,
SetRevocationBySubjectAndPubKey, SetEnrollment, and SetWhitelist) are called on
the main thread by the implementations that manage consuming remote security
information. We don't want to block the main thread, so this patch modifies
these functions to take a callback that will be called (on the original thread)
when the operation in question has been completed on a background thread.
The Get* functions of nsICertStorage (GetRevocationState, GetEnrollmentState,
and GetWhitelistState) should only be called off the main thread. For the most
part they are, but there are at least two main-thread certificate verifications
that can cause these functions to be called on the main thread. These instances
are in nsSiteSecurityService::ProcessPKPHeader and
ContentSignatureVerifier::CreateContextInternal and will be dealt with in
bug 1406854 bug 1534600, respectively.
Differential Revision: https://phabricator.services.mozilla.com/D25174
--HG--
extra : moz-landing-system : lando
`nsPICommandUpdater` is a scriptable interface, but nobody refers it from JS,
and it's implemented only by `nsCommandManager`. Therefore, we can get rid
of this interface.
Additionally, `nsCommandManager::Init()` is called only by `nsDocShell`, which
is the only instantiater of the class, and returns error only when given window
is nullptr. Therefore, we can make the constructor take the window instead.
Differential Revision: https://phabricator.services.mozilla.com/D25729
--HG--
extra : moz-landing-system : lando
`nsIControllerContext` isn't implemented with JS even in comm-central nor
BlueGriffon. Therefore, it can be a builtinclass.
Additionally, it's `init()` returns always `NS_OK`, and always called with
`null` from JS, and always called with an instance from C++. So that its the
only implementation, `nsBaseCommandController` can have 2 constructors which
does what `Init()` currently does.
Differential Revision: https://phabricator.services.mozilla.com/D25728
--HG--
extra : moz-landing-system : lando
There was special case logic to map the win64 platform to win32, for stub
entries. When win64-aarch64 was added no special case was added for that
plaform, so they stub entries pointed at the incorrect place. This changes the
configuration so that all stub entries point at the win32 paths, without
needing special case code.
Differential Revision: https://phabricator.services.mozilla.com/D25841
--HG--
extra : moz-landing-system : lando
In automation, the script is run with `mach python`, and all the dependencies
are vendored, so just use them directly.
Differential Revision: https://phabricator.services.mozilla.com/D25839
--HG--
extra : moz-landing-system : lando
These existed for when bouncer was updated via mozharness, and they are unused in bouncer-check.
By removing the paths, we make the configuration easier to read and update.
Differential Revision: https://phabricator.services.mozilla.com/D25838
--HG--
extra : moz-landing-system : lando
Fennec doesn't have a bouncer check task, and bouncer is update via bouncerscript.
Differential Revision: https://phabricator.services.mozilla.com/D25837
--HG--
extra : moz-landing-system : lando
I beleive these entries date from when bouncer config was handled by mozharness
rather than bounerscript and are now obsolete.
Differential Revision: https://phabricator.services.mozilla.com/D25836
--HG--
extra : moz-landing-system : lando
When adding a new platform, the first release will be at the watershed, and
there will be no update paths. Rather than failing in this case (requiring the
update-verify setup happen after the first release), generate an empty config
which will allow the later tasks to turn green.
Differential Revision: https://phabricator.services.mozilla.com/D25833
--HG--
extra : moz-landing-system : lando
We check that partials as a safety check. But we don't need that for staging builds,
and it is often useful to be able to test things that don't depend on partials.
The shipit UI currently still requires partials, but that can be worked around using
the react dev tools.
Differential Revision: https://phabricator.services.mozilla.com/D24834
--HG--
extra : moz-landing-system : lando
The original code was converting to json, then comparing against `{}`. This switches things
around so that json is only generated where it is directly used a json.
Differential Revision: https://phabricator.services.mozilla.com/D24833
--HG--
extra : moz-landing-system : lando
Enables the list of suites as defined in Bug 1540213.
- added new item in `test-sets.yml` for windows10-aarch64.
- reference the new test-set in `test-platforms.yml`.
Differential Revision: https://phabricator.services.mozilla.com/D25979
--HG--
extra : moz-landing-system : lando
These will run on android-hw against the latest reference browser nightly.
Since they are try-only, they can only be scheduled with |mach try fuzzy
--full|.
Differential Revision: https://phabricator.services.mozilla.com/D25801
--HG--
extra : moz-landing-system : lando
Changes:
- skipped problematic tests in crashtest suite on windows10-aarch64
- removed unnecessary pixel fuzzy values from previous iterations of greening tests
Differential Revision: https://phabricator.services.mozilla.com/D25714
--HG--
extra : moz-landing-system : lando
Barret Rennie
Tom Prince
Mike Hommey
Karl Tomlinson
Nick Alexander
sotaro
Razvan Maries
Masayuki Nakano
Dana Keeler
Chris Manchester
Gijs Kruitbosch
Mellina Yonashiro
Junior Hsu
Ehsan Akhgari
Edwin Gao
Adam Holm
Henrik Skupin
Andrew Halberstadt
Kyle Machulis
Dzmitry Malyshau