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
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
The new Onboarding process will have updated imagery and strings.
It will also not show the "Customize" screen anymore.
It will only be shown if the new Strings are localized;
Differential Revision: https://phabricator.services.mozilla.com/D28863
--HG--
extra : source : 035da268a5d5585c2d7d5996ca7c73263ffdbbc8
The new Onboarding process will have updated imagery and strings.
It will also not show the "Customize" screen anymore.
It will only be shown if the new Strings are localized;
Differential Revision: https://phabricator.services.mozilla.com/D28863
--HG--
extra : moz-landing-system : lando
Handle 2 specific edge-cases:
- The user presses to change default browser, when he returns to the app the
app settings button to do so should not be displayed anymore.
- With the app in background showing the app settings the user changes to a
different default browser. When resuming the app it should show the option to
set Fennec as default.
All this without otherwise requiring the user to close app settings and opening
them again.
Depends on D28831
Differential Revision: https://phabricator.services.mozilla.com/D28832
--HG--
extra : moz-landing-system : lando