Some further post-processing happens after loading a page in reader mode, so the pageshow event is too early for restoring the scroll position.
The fix is to do the same thing that desktop does in bug 1153393 and wait for a custom event instead.
MozReview-Commit-ID: DuMA0JxnYEY
--HG--
extra : rebase_source : 4b24fedcea974cef4d916fc7e59768c160728b0c
While passing the cached tabs count to the HistoryAdapter in its constructor greatly simplifies getting the cached count into the adapter before the RecyclerView initialises, this relies on the History panel having the panelStateChangeListener available before the HistoryAdapter is created in onCreate().
MozReview-Commit-ID: 64IbAe6SaEq
--HG--
extra : rebase_source : fd6f9a4f1ca92804cd0bca4a355abf17bb784572
extra : source : cb1b540364d1846b58fb5f6ac329935d3f5201bc
After we've set the cached tabs count to display within the history adapter, we don't want to revise that number downwards as long as the RecentTabsAdapter hasn't yet checked all of its data sources.
MozReview-Commit-ID: BMpiaEb3kGQ
--HG--
extra : rebase_source : 433c041f1073fe8aff1b4dfc5620c4544e8478d8
extra : source : ec7d53dea918724ff888db3327186d6b09a5dfac
Getting the total number of recently closed tabs involves waiting for Gecko to actually send the closed tabs to the Java UI. This means that (unless there are some "Tabs from last time" present) when showing the history panel we always start out with the Recently closed folder hidden and then unhide (and animate) it once we've finally received the closed tabs.
Because this is visually distracting, we should cache the closed tabs count somewhere, so we can decide on the smart folder visibility as soon as the CombinedHistoryAdapter initialises.
MozReview-Commit-ID: 8uYCbM7eiSt
--HG--
extra : rebase_source : 1afe3c8a0f184272d5d05913ef3af8050b6e5d06
This involves making the number of visible smart folders dynamic, so the history adapter can properly display its contents.
MozReview-Commit-ID: 6b4V6IHB7BE
--HG--
extra : rebase_source : fc2e70f5ed0aa1961ffe464fcf67a1488f8eb91b
extra : source : 2b9260c4018b1005dea01e2b2c4548643db4264d
Otherwise Android Studio complains because it doesn't recognise our version switch.
MozReview-Commit-ID: 2QpD3nNSryK
--HG--
extra : rebase_source : 6b82ccf8c3fedee10688b4078882222cf231cb33
Except controlling audio focus from gecko, the MediaControlService can also
decide whether needs to request or abandon audio focus.
MozReview-Commit-ID: G3iSYwd24JZ
--HG--
extra : rebase_source : dd29207d8c08176cd7a57f08d3361e4f29c4095a
Remove 'ACTION_REMOVE_CONTROL' because it's as same as 'ACTION_STOP'.
MozReview-Commit-ID: 6KOj8srEuJA
--HG--
extra : rebase_source : 3b92e0f3d6485af4e9be97b1423804401b1496c7
'ACTION_RESUME' should be more suit for its operation.
MozReview-Commit-ID: 4FRHaydVKu5
--HG--
extra : rebase_source : 76b405bf0b7a27f2ea7f27283230df146b71ccfc
Now the life time of the MediaControlService would be as same as the Fennec app.
To make code flow more easily, requesting/abandoning the audio focus wouldn't
affect the media control.
We would mainly communicate with the media control via TabEvents.
MozReview-Commit-ID: KT59bII0HuN
--HG--
extra : rebase_source : d8f2c810f24ef6ea72a274db2b432ca8f8876d8e
wrap some code into initialize() and shutdown().
MozReview-Commit-ID: AiyABlyDEME
--HG--
extra : rebase_source : e13f4d1eef46207edd9d8d8cc956c2644f3b1e38
The 'MEDIA_PLAYING_CHANGE' is used for controling media control interface and
the 'AUDIO_PLAYING_CHANGE' is used for showing the tab sound indicator.
MozReview-Commit-ID: 8hZjC77Ju71
--HG--
extra : rebase_source : 3699ea482e89a5c2535defce8ca2689a180d5c49
updates.properties uses on Fennec/XUL. But after bug 786380, we use native version for update service.
MozReview-Commit-ID: CREAeLdlrJH
--HG--
extra : rebase_source : 1412c541e4c4f9e7d1bb98e2466ae6cc60c062e0
extra : histedit_source : 7a431e1ed942d9766fcd690e4b01bc7774203ba7
Repacks of upstream builds of rust 1.11.0 stable with std libraries
for the appropriate targets. Remove the separate rust-std package
references since the new repacks include the necessary targets.
Also update clang and hazard builds to the latest toolchain.
MozReview-Commit-ID: K7oBxQZnLPu
--HG--
extra : rebase_source : 9f339ff52e9e2f6c28d4bb7a734b9f0eae43a47a
We use the FaviconView to fill the majority of the card (i.e. full width, and approx 75% of the height)
- in that scenario rounding the corners looks odd.
MozReview-Commit-ID: 1e5HAwfcV5
--HG--
extra : rebase_source : e6c5168025e1ac3ad941e8fd6207960b37442373
Let's try to load from the legacy loader only if there's one icon left and
the other loads have failed. We will ignore the icon URL anyways and try to
receive the legacy icon URL from the database.
MozReview-Commit-ID: Kr7gHXBuAs7
--HG--
extra : rebase_source : 7fbdd507fa2c0a9aa4223db1da6aa5fbc1aa4907
If we are allowed to load the icon from the network then skip loading from the legacy storage and just
load a fresh icon. This will avoid touching the legacy storage (disk) every time before downloading an
icon.
MozReview-Commit-ID: C9hYqISno6U
--HG--
extra : rebase_source : 6f19839c38d37916deb351b3e080e023e532a83f
Running the color extraction algorithm on a smaller image will be much faster.
MozReview-Commit-ID: A42rzuQ3FDQ
--HG--
extra : rebase_source : 560e5e1a6711d8f34f12803e5aabf4f09e769706
The custom executor behaves like the one returned by Executors.newSingleThreadExecutor().
However the created thread will have a unique name ("GeckoIconTask") and this will make
tracing the thread much easier.
MozReview-Commit-ID: 7y0EMGmNLkG
--HG--
extra : rebase_source : 517d329df12ff101816c3a3f8e27f28aeffb6821
