Newer versions of the support library do this automatically, but we need to
roll our own implentation for now.
16:9 keyline means that the top of the menu is placed such that a 16:9 window
of application content is still visible above the menu. This is illustrated in:
https://material.io/guidelines/layout/metrics-keylines.html#metrics-keylines-keylines-spacing
(The menu itself is _not_ 16:9.)
MozReview-Commit-ID: FSUdssb5eBN
--HG--
extra : rebase_source : 735cfb9ce7f78e4247780011c76850560f67d40e
This has no benefit right now, but this lets us avoid forgetting to upgrade to the non-deprecated
method once we no longer need to support api 15.
MozReview-Commit-ID: FmRoP5PnGDC
--HG--
extra : rebase_source : 2c5df232fd526f044bd10b3e6cf9920ddb2e4e7b
This seems to be an Android platform bug affecting Android 4.X, which
is visible primarily on tablets (on phones, page titles are often broken
over two lines, which isn't the case on tablets, hence it's easy
to spot if this bug is happening).
MozReview-Commit-ID: AfSw3AJHFqH
--HG--
extra : rebase_source : 125789099f5c7309f2bb049b49341183fa99c3a2
On some devices, ImageView appears to lose it's padding when calling
setBackground[Drawable](). We therefore need to save and restore the
padding on those devices.
Known affected devices are various Asus Transformer tablets,
and also the Motorola Droid 4, running various Android 4.X versions.
We therefore make this workaround conditional on Android 4 to minimise
the number of devices where this workaround is used. (Having the conditional
should also make it easy to notice when we can remove the workaround, i.e.
whenever Android 5 becomes the baseline.)
MozReview-Commit-ID: B88gWwEx48x
--HG--
extra : rebase_source : f22fb850c919a25dd14b46e6dec558e8e8998d7b
Previously we started the DLC service from GeckoApplication. The reason for that was that we wanted to
download content like fonts as early as possible so that they are available the next time we display
a website.
However we do not know whether we are running in automation until the BrowserApp activity is launched.
This patch will start the service from BrowserApp.onCreate() now if we are not running in automation.
MozReview-Commit-ID: C3Ob6S3yve4
--HG--
extra : rebase_source : 3dbe64f6cbc0a90149e9c46849d4b68e5674b532
This patch adds the ability to run SingletonEventManager handlers in
different modes: sync, async, raw (no exception handling, arg cloning,
or asynchrony), or asyncWithoutClone. When you call the handler,
you're required to specify which variant you want.
Existing uses of SingletonEventManager are all converted to async calls.
Note that some of them were previously synchronous, but it didn't appear
to be necessary.
Also added a callOnClose for SingletonEventManager when the last listener
is removed.
MozReview-Commit-ID: ATHO97dWf3X
--HG--
extra : rebase_source : bf02d79e3fbab84892be8a7e52ea7a1caf2e003d
CLOSED TREE
Backed out changeset 2d42350d209a (bug 1203330)
Backed out changeset 3a12c51c3eca (bug 1203330)
Backed out changeset 31fac390e15d (bug 1203330)
Convert events used in PageActions to bundle events. UI thread events
are used because the listeners require the UI thread. The observer
notifications from Java to Gecko are converted to events as well.
Convert events used in AccountsHelper to bundle events. Most events are
kept as Gecko thread events, but a couple events that start activities
are converted to UI thread events.
Convert events used in IntentHelper to bundle events. UI thread events
are used for most events because the listeners perform operations on
Intent objects, which is best done on the UI thread. For
"Intent:GetHandlers", use a Gecko thread event because it's possible we
want a synchronous callback response.
Convert events used in HomePanelsManager to bundle events. Background
thread events are used because HomePanelsManager processes panel changes
in the background thread. Changing to background thread events also lets
us make the change queue a simple ArrayList instead of a
ConcurrentLinkedQueue, because there is no longer multiple threads
involved.
Convert the "HomePanels:Data" event to a GeckoBundle/BundleEventListener
event. UI thread event is used because the listener invokes the callback
on the UI thread.
Convert events used in FindInPageBar to GeckoBundle/BundleEventListener
events. UI thread events are used because the listener performs UI
operations. FindInPageBar also sends some events like "FindInPage:Find"
from Java to Gecko; those events will be converted in another bug.
Convert observers in ActionBarHandler.js to events that go through
WindowEventDispatcher. "TextSelection:Get" now replies through the
callback interface rather than a "TextSelection:Data" event. The patch
also adds new lazy-loading events in browser.js to replace the
lazy-loading observers that ActionBarHandler relied on.
Convert the events used in MediaCastingBar and ChromeCastPlayer to
GeckoBundle/BundleEventListener events. UI thread events are used
because the listener performs operations on the UI thread.
