This also updates apilint to 0.2.2 to ensure that future instances of this
problem will be caught automatically.
Differential Revision: https://phabricator.services.mozilla.com/D37812
--HG--
extra : moz-landing-system : lando
There's currently a bug in Android's framework that manifests by placing the
floating menu off-screen if a menu label overflows the menu's width.
https://issuetracker.google.com/issues/137169336
To overcome this we'll manually check and truncate any menu label that could
cause issues based on the floating menu style declared upstream.
Differential Revision: https://phabricator.services.mozilla.com/D37684
--HG--
extra : moz-landing-system : lando
* Add a new optional 'notifySaved' argument to promptToSavePassword
* Give the notification an attention style when showing a login doorhanger for an auto-saved login with a generated password
Differential Revision: https://phabricator.services.mozilla.com/D37661
--HG--
extra : moz-landing-system : lando
Summary:
The share drawable is used in multiple places in code.
Android would cache it and subsequently serve a now dirty version of it with
transformations potentially added.
By mutating it into a new drawable we ensure we'll always have it clean.
Reviewers: VladBaicu
Reviewed By: VladBaicu
Subscribers: emilio
Bug #: 1529557
Differential Revision: https://phabricator.services.mozilla.com/D37734
--HG--
extra : rebase_source : 864946cb3d5a256b26a380fbf6a0cbe70a20ca12
extra : histedit_source : 941d909f040426046d71028b21644d0652fa1238
In bug 1552607/D36382, RemoteDataDecoder always increases session ID but
CodecProxy only performs flush IPC when neccessary. This will cause the
ID numbers out of sync and prevent remote decoder from receiving any
more input. By reading the session ID in dequeued input samples, the
numbers can always be in sync.
Differential Revision: https://phabricator.services.mozilla.com/D37123
--HG--
extra : moz-landing-system : lando
This test is a little slow sometimes and times out (even though nothing is
going wrong). Doubling the timeout seems to be enough.
Differential Revision: https://phabricator.services.mozilla.com/D37673
--HG--
extra : moz-landing-system : lando
Some background information on this change:
DocShell loads about:blank when first starting up. This initial load can be
avoided by setting `nodefaultsrc` on the browser element, but this will still
cause some load events related to `about:blank` to fire anyway, as they are
specified in the DOM spec (see e.g. bz's Comment #2 Bug 1447406). In particular
`onSecurityChange` and `onLocationChange` are still fired, `onPageStart` and
onPageStop` are not.
These messages are unreliable and sometimes do not fire, to unrestand why it's
helpful to look at a timeline of the events when starting up a GeckoSession.
page about:blank ---------------------------------------------------------
nsDocShell --- startup --- onPageStart --- onLocationChange --- onPageStop -----
busyState idle ---------- busy ------------------------------------------ idle-
^ ^ ^ ^ ^
geckoview.js (0) (1) (2) (3) (4)
geckoview.js loads in parallel with nsDocShell startup process (and loading of
about:blank). This means that consumers of GeckoView might start receiving
navigation events at any of the points marked with (0) - (4). E.g. if geckoview
starts up at (4) a consumer waiting for onPageStop for `about:blank` will
actually wait forever (this is what happens before this change for our tests).
As it can be seen there's not really a way to detect in which of the (0) - (4)
state DocShell is when starting up geckoview.js. Checking for the busy state is
not enough as an `idle` busy state might mean that we're in (0) or (4).
Furthermore a consumer of geckoview has no way to know which onPageStop
messages to wait for after an initial loadUri as e.g. the following is what
would happen if geckoview.js happens to startup at (3):
- loadUri(hello.html)
- onPageStop (for about:blank)
- onLoadRequest (for hello.html)
which confuses any code that just waits for onPageStop.
Desktop deals with this in `TabProgressListener.onStateChange` where the
initial `about:blank` navigation is ignored and fake events are triggered at a
convenient time.
To patch implements a very similar behavior for geckoview, we ignore the
initial `about:blank` `onLoadRequest` call, set `nodefaultsrc` so `onPageStart`
and `onPageStop` events don't fire and fire the above calls when the
`GeckoViewProgress` module has finished loading.
This makes `about:blank` events deterministic with the exception of reloading
an empty `GeckoSession`, which will often not fire any extra events. To account
for that we load a dummy html page before the tests that used to rely on this
behavior (which would actually fail occasionally due to the startup race
condition explained above).
This makes the tests pass reliably on x86_64 (20/20 runs passed in try).
Differential Revision: https://phabricator.services.mozilla.com/D32586
--HG--
extra : moz-landing-system : lando
Right now listeners for a given native app receive messages from all
WebExtensions. This is wrong as listeners should be extension specific so that
only the intended extension can send messages to the app.
Differential Revision: https://phabricator.services.mozilla.com/D35948
--HG--
extra : moz-landing-system : lando
Reusing sessions doesn't actually save that much time and avoids a lot of
hard-to-debug intermittents.
Differential Revision: https://phabricator.services.mozilla.com/D32578
--HG--
extra : moz-landing-system : lando
Sometime the geolocation test fails because the position is not retrieved
quickly enough, this is OK as we're just trying to make sure that the
permission is correct.
Differential Revision: https://phabricator.services.mozilla.com/D32576
--HG--
extra : moz-landing-system : lando
