Starting from Android O, more fine-grained control over which notifications
should be displayed is available through Android's notification channel system.
To aid discoverability, we add a link to the corresponding settings screen from
inside our own settings menu.
Differential Revision: https://phabricator.services.mozilla.com/D29973
--HG--
extra : moz-landing-system : lando
We're not going to change this for now and otherwise Android Studio shows an
error for that file.
Differential Revision: https://phabricator.services.mozilla.com/D29971
--HG--
extra : moz-landing-system : lando
This is more related to telephony than anything else, and are more suited to
real telephony app.
Differential Revision: https://phabricator.services.mozilla.com/D30071
--HG--
extra : moz-landing-system : lando
This image was initially parts of the new Onboarding UX assets but
it is unused at the moment.
Differential Revision: https://phabricator.services.mozilla.com/D30193
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
This allows Gecko to react to network link/status changes events as needed.
Differential Revision: https://phabricator.services.mozilla.com/D28942
--HG--
extra : moz-landing-system : lando
2019-05-06 22:41:10 +00:00
Eugen Sawin ext:(%2C%20Chris%20Pearce%20%3Ccpearce%40mozilla.com%3E)
This patch introduces a new type of content process, which has a dynamic name.
This type of content process is labeled as `webIsolated=${SITE_ORIGIN}` and is
used within fission-enabled windows.
To enable this, additional information about the fission status of the target
window must be passed into E10SUtils. This was done by updating every call site
manually to pass an extra boolean. A better solution perhaps should be used in
the future.
With this patch enabled, we now perform process switches, but only when
navigating to HTTP URIs. If we navigate to a non-HTTP URI in an iframe with
fission enabled, it will not behave correctly. This must be done in a
follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29570
--HG--
extra : moz-landing-system : lando
Make sure we continue to leave JS un-minified for Nightly builds and add a missing FENNEC_NIGHTLY to AppConstants.jsm which got missed in bug 1547710.
Differential Revision: https://phabricator.services.mozilla.com/D29724
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
This allows Gecko to react to network link/status changes events as needed.
Differential Revision: https://phabricator.services.mozilla.com/D28942
--HG--
extra : moz-landing-system : lando
2019-05-03 02:43:22 +00:00
Eugen Sawin ext:(%2C%20Chris%20Pearce%20%3Ccpearce%40mozilla.com%3E)
This issue was caused by the updating of the caret position after the paste occurs firing an `updateposition` event resulting in an `GeckoView:ShowSelectionAction` message to reposition context menu without any attempt to close the context menu. The solution is to hide the context menu before the repositioning of the caret occurs such that the `updateposition` event doesn't trigger a redisplay.
I tried several versions of this trying to trigger the menu close from inside `GeckoViewSelectionActionDelegate`, including making the call to `docShell.doCommand("cmd_paste");` asynchronous and firing `ACTION_HIDE` before firing `ACTION_PASTE`, but the result is always the same - one of the events is processed before the other and so the second event is rejected as a stale response.
Therefore we are firing the `pagehide` from inside the code that performs the paste. This has to be done before the paste occurs otherwise the `updateposition` event is fired before the page hide event and the context menu redisplays before being hidden.
Differential Revision: https://phabricator.services.mozilla.com/D29665
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
This allows Gecko to react to network link/status changes events as needed.
Differential Revision: https://phabricator.services.mozilla.com/D28942
--HG--
extra : moz-landing-system : lando
2019-05-01 23:45:53 +00:00
Eugen Sawin ext:(%2C%20Chris%20Pearce%20%3Ccpearce%40mozilla.com%3E)
For TV devices, it is useful to have mouse events automatically
interpreted as touch events. On other devices, such as more desktop-like
Android devices, we want to treat mouse events as mouse events. This patch
makes this behaviour controllable by a pref, but keeps the existing default
behaviour of treating mouse events as touch events.
Differential Revision: https://phabricator.services.mozilla.com/D29188
--HG--
extra : moz-landing-system : lando
