Okay, this patch is much bigger than I anticipated. However at this point it is impossible
to separate all the interweaved changes.
* Update sizes and colors
* Use a dynamic number of top sites tiles to adjust to the screen size
* Do not keep references (to possible outdated) Cursors from every top sites page
* Remove unused bottom panel
* Add menu button to highlights items
MozReview-Commit-ID: 2CeEGCOXBKl
--HG--
extra : rebase_source : a780ec20fa6f87520c3418403ae4fe259ff39d69
Update path can be null. In this case we fallback to using the last saved path. However
if this doesn't exist either then we just continue with a null path and eventually crash
the service.
MozReview-Commit-ID: Kuihp496TEo
--HG--
extra : rebase_source : 96e2182571f4b2235b3fea25f449b2dbb3e17bb8
The Android version of TouchDelegate never resets the value of its
mDelegateTargeted, which means that once an event is delegated, future events
can get delegated as well, regardless of whether the event occurs within the
TouchDelegate's bounds. Because of the geometry this is more of an issue with
the (future RecyclerView version of) TabsGridLayout, but it can occur on
TabsLinearLayout as well where we use a TouchDelegate to increase the hit size
of the close button on a tab - once a close button is hit by delegation and the
tab is closed, the next time that tab is recycled it will continue to delegate
ACTION_UP events to the close button (in which case they're silently dropped)
even if the ACTION_DOWN was not in the close button's delegation area.
This commit introduces TouchDelegateWithReset, which is simply an override copy
of TouchDelegate with one extra block (commented in the new class) to reset
mDelegateTargeted on each new gesture received.
MozReview-Commit-ID: 5xrPBAdAK6D
--HG--
extra : rebase_source : d1b9c7a443b0590c63433ea6855c8a1ae0662455
extra : source : 0c267676cb0824d916f398155b0d5b7dec6f346c
Use the index in TabsLayout to specify where a tab was inserted instead of just
replacing the entire tabs list on a tab add.
MozReview-Commit-ID: Feft0RlN97r
--HG--
extra : rebase_source : 1ff47946d9e94d08dfcee34364c65ae7f8c02e7a
Also make a temporary testing adjustment to handle the fact that TabsListLayout
and TabsGridLayout don't currently share a common usable base.
MozReview-Commit-ID: HPExAnehKRq
--HG--
extra : rebase_source : 4d9d0ce9fff216090ae676163e22645cd45c92a5
extra : source : 411a8ac7368e3b69e8191812fb53f0d1b8aa3247
TabsListRecyclerAdapter.java will replace TabsLayoutAdapter.java when the time
comes.
Note from the future: the previous tabs layouts did a scroll each time an item
was added or selected, but GridLayoutManager sometimes does scrolls that aren't
necessary (like even when the position being scrolled to is already completely
in view), so we've adopted the approach of only scrolling when RecyclerView
makes it necessary.
MozReview-Commit-ID: JisX974zt88
--HG--
extra : rebase_source : 4105762cdd743d5120385e246350fc4059b6bcfc
extra : source : e4e74d6ae6da7dddda9a95e50c26656b07e67287
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This removes the rest of the usage of nsISupportsArray in MediaManager.
MozReview-Commit-ID: EqXTRNyKiva
--HG--
extra : rebase_source : afc25d91dfcabf6f8f5c9aca6828d41acac9e97e
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
--HG--
extra : rebase_source : 069b6ec173bb98ab08d93279b5e983494184f8c0
Setting an empty view's visibility only for the view corresponding to the current PanelLevel was intended to make sure the empty view doesn't get hidden because of an unrelated status update - e.g. to prevent the history empty view hiding itself because the recent tabs count changes.
This approach however doesn't work for switching between panel levels (the user moving into and out of the sync/recent tabs folders) - in that case we always need to turn off the empty view of the previous panel level, which is not possible with the above approach.
So instead, we revert to always updating the visibility of the empty views, but at the same time initialise the desired state of current PanelLevel's empty view with its current visibility instead of simply defaulting to false.
MozReview-Commit-ID: 6Xsnuo29srk
--HG--
extra : rebase_source : d540c128df51ae0315f9ee05c3fb87cfcf44877a
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This allows us the use of VectorDrawable's (which can be created by converting SVG files) in a
limited set of circumstances.
MozReview-Commit-ID: 4n4dXnZYn9W
--HG--
extra : amend_source : 8fbf2579260590a26ecd0112d6fce1055e929bd7
Also this makes the gScreenWidth/gScreenHeight variables unused, so those can
come out too and the Window:Resize handler can be simplified a bit.
MozReview-Commit-ID: 96iF16jSKBB
--HG--
extra : rebase_source : 01db1de5cc548db107267d84dda5b774cd652883
Bug 1305498 - 1. Remove NotificationClient task queue; r=sebastian
Not sure why we needed a task queue for NotificationClient actions. The
actions all go through IPC and are non-blocking, so it's perfectly fine
to perform them off of whatever thread we're on.
Bug 1305498 - 2. Integrate NotificationHandler et al into NotificationCllient; r=sebastian
There's no reason to have NotificationHandler, AppNotificationClient,
and ServiceNotificationClient all separate from the base
NotificationClient class. This patch adds the functionality of
those three classes to NotificationClient.
The notifications hash map is changed from a ConcurrentHashMap to a
regular HashMap with synchronization because I think the use case here
doesn't warrant the added performance and overhead of ConcurrentHashMap.
NotificationService is changed to match the new NotificationClient. Now
the only job for NotificationService is to set a notification as
foreground, rather than to manage all notifications like before.
NotificationHandler, AppNotificationClient, and
ServiceNotificationClient will be removed in a later patch.
Bug 1305498 - 3. Set NotificationListener in GeckoApplication; r=sebastian
Set NotificationListener once in GeckoApplication.onCreate, instead of
spreading it out in GeckoApp, BrowserApp, and GeckoService. This is
possible because there's no longer a distinction between
AppNotificationClient and ServiceNotificationClient in the new,
consolidated NotificationClient.
Bug 1305498 - 4. Remove obsolete notification classes; r=sebastian
Remove AppNotificationClient, ServiceNotificationClient, and
NotificationHandler, now that they've all been replaced by the new,
consolidated NotificationClient.
Bug 1305498 - 5. Use NotificationReceiver for web notification callbacks; r=sebastian
Previously, web notification callbacks went to GeckoApp directly, but
that presented some problems such as not being able to implement the
on-close callback, because we don't want to launch GeckoApp when the
notification is closed by swiping. This patch makes us use
NotificationReceiver for callbacks, and let NotificationReceiver launch
GeckoApp if necessary.
Bug 1305498 - 6. Don't keep notification cookie in native code; r=sebastian
Keep the notification cookie a single location (in the notification
intent itself), and simplify the native notification handling code.
Bug 1305498 - 7. Use NotificationReceiver for persistent notifications; r=sebastian
Currently, persistent notification callbacks go through a different code
path, but it'd be more consistent and correct to let persistent
notification callbacks go through NotificationReceiver as well.
This takes care of some housekeeping work that was missing for
persistent notifications, such as deleting the mNotifications entry when
the notification is closed.
The fixup migration assumes that there must be a default panel, and sets the history panel as default if not.
This assumption is wrong in the case where no panels are visible: in this case there is no default.
Before this commit, that migration will make the history panel visible for all users who had no
visible panels, with this commit that migration will retain the all-panels-hidden state.
Note: it's impossible for us to recover the all-panels-hidden state for clients that have already
run the migration, however we can at least prevent this issue from happening for users who
have not yet migrated (i.e. in release).
MozReview-Commit-ID: 9JlmltPW2Ly
--HG--
extra : rebase_source : 4e608910775c971ec09c0f9096b8ae36e9f7b877
Sometimes the tab doesn't get its favicon yet when we send the notification.
Therefore, we would listen the FAVICON event and then re-send the notification again if we used the default cover icon in previous notification.
MozReview-Commit-ID: JSphLBEhGy2
--HG--
extra : rebase_source : 55f12e30583480a1d0d7f2743974a05180198ad5
We need to bump the Gradle Deps task, which fetches dependencies, to
include new test dependencies; and use freshly uploaded tooltool
archives (manually uploaded) containing the new test dependencies.
MozReview-Commit-ID: 8bNOVQPHlk6
--HG--
extra : rebase_source : 0c80117fb58e43f9c857027941f0a14f03b97f13
Web Crypto returns an unhelpful "operation failed for an
operation-specific reason" error if the actual decryption fails, but
we can report more useful errors for missing and invalid header
values.
MozReview-Commit-ID: JRdGHBUodmb
--HG--
extra : rebase_source : 8f1b047b6f01c89a852aefbb1349a608f1178ab8
On Windows, the contextmenu event is fired when the finger is lifted after a
long-press. However, there are various bits of code, such as the AccessibleCaret
or potential fixes for bug 1147335, which would benefit from knowing when the
long-press gesture was detected. By moving eMouseLongTap event up we can satisfy
that need. An alternative approach considered was to fire the eMouseLongTap
before the contextmenu on all platforms unconditionally, but that makes it harder
to implement platform-specific text selection behaviour the way we want. In
particular we would have to add an extra message or notification for non-Windows
platforms that initiated text selection if the contextmenu event was not
consumed.
MozReview-Commit-ID: 2lmwxmmGrVD
This patch introduces WebsiteMetadata.jsm which imports fathom and page-metadata-parser.
The code has been slightly modified to not depend on more node libraries.
On DOMContentLoaded the module will extract the metadata asynchronously and send it with
a 'Website:Metadata' event.
MozReview-Commit-ID: LxhYOTvvdsF
--HG--
extra : rebase_source : e31286bd7268ad62d55f1a5318cde79442e9acba
Huge oversight in my original patch. Pressing any hardware button will result
in the history list being shown after the long-press delay (regardless of long-pressing).
MozReview-Commit-ID: KO8u0NzTxaO
--HG--
extra : rebase_source : 6f6932c4f35b9e580a84a2d68a7688abe4da79de
After the splitting of text overlay and the caret images, the caret image should
be placed from the top of #image div.
Delete those "top" style for Fennec since they're not needed anymore in current
setup.
MozReview-Commit-ID: Dn6jgqaFfek
--HG--
extra : rebase_source : 92b697db26cb7311fbd22a63e9f0ed71e6a434f4
It looks like the update (23.4) version of palette returns the actual dominant colour
for a red mock (FF0000). Previously it returned a more muted red (F80000).
MozReview-Commit-ID: 5VpRavyooHY
--HG--
extra : rebase_source : ab55e787a305481f890d00739de2843b87063bed
Make contentDocumentChanged and isContentDocumentDisplayed calls require
the caller to pass in a window object, so that we can get the widget and
GeckoLayerClient from the window object. This way these calls no longer
depend on having a global layer client in AndroidBridge.
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
--HG--
extra : rebase_source : a8beed043989f6e69e89d17c0db1864c6d7258ac
I've also updated espresso versions. For some reason using espress results in test-app
defaulting to annotations 23.0.1 or 23.1.1 (depending on espresso version), but we can
override this with the actual annotations library version to make gradle happy again.
MozReview-Commit-ID: 6rFtvVgceJV
--HG--
extra : rebase_source : 3c9fb20cad396eebbfbd890cc37a4931221488d9
Going forward there will be just one highlights item/layout with an optional image.
MozReview-Commit-ID: BmtUTtanjJr
--HG--
extra : rebase_source : e80edea42af9bdc9c3a79b3bd9588d0a91f8faf7
The UNION operator requires the two result sets to have the columns in the same order.
MozReview-Commit-ID: JRtw0LDZ5ib
--HG--
extra : rebase_source : a2cc6b2a9190cf9fb8ec75351446e0a91e613710
Per bug 1307100 comment 3, we use "height equals to 0" to hide the floating
toolbar so we only need to adjust the handlesOffset when height > 0.
MozReview-Commit-ID: AdIOxIFUrI
--HG--
extra : rebase_source : c62658c19362e5b49b1b36829cd4b1ef81be87e4
CLOSED TREE
--HG--
extra : amend_source : 1f0c7bbb5aa8a3dab38f0785e13e32f59e8f8c79
extra : histedit_source : ca99420cac7019a4b6fd6aab781b93151092a8bc%2C0ef091317a27688c734f20417875406726e35de7
CLOSED TREE
MozReview-Commit-ID: Apt89thqPfX
--HG--
extra : source : 548560e9e76273fa6df17415e9b29bfd0361e61b
extra : amend_source : c8022b27421c033809ce5b543f49c0af2ed91020
extra : histedit_source : 22ec0210605b62ef3990e6ee9007d1816cd2a722
I am open to replacing "constellations" with a different name, but it was the best
I could come up with so far.
MozReview-Commit-ID: 9pljV8nC6O8
--HG--
extra : rebase_source : 781b5e1776adf457c92cacfecc09dc7afe03ad41
Note: we also change the return value of a long-press when the tab history fragment is showing:
we want to completely ignore long-presses in this case, previously we used to return false in this
case, which suggests that we didn't handle the event - however we explicitly consider this a no-op,
so should return a value reflecting that (in reality: no one else handles the long-press, so this
makes no effective difference).
MozReview-Commit-ID: FYrCVsNHfjv
--HG--
extra : rebase_source : d1af525a119264ea820b665198f45ff32898e8e1
This ensures that a DB modification will trigger a refresh of any clients
using getHighlights().
MozReview-Commit-ID: Cauc89ryDHr
--HG--
extra : rebase_source : e70401ba51ea406ab339f02abec73ec9bf1b3332
Distribution.getDistributionDirectories is currently annotated with
@WrapForJNI, but because it's used from JS through JNI.jsm, the
@JNITarget annotation is more appropriate.
We need to ensure we can explicitely close any database connections we open in the TestLegacyLoader,
so we initialize a BrowserProvider instance so that we can then call .shutdown() on it once we're done,
which will close any open connections.
Additionally, we need to make sure to use correct authority when registering (using AUTHORITY_URI produces dual mapping
of providers, from content://org.fennec... and from org.fennec...), and wrap our providers in a DelegatingTestContentProvider,
which will append PARAM_IS_TEST param to wrapped URIs - when present this ensure we won't try to load a per-profile database.
MozReview-Commit-ID: LnzPhGOe6OY
--HG--
extra : rebase_source : 76eaadaa78bed7918b90012f8bdcc996dc3b2024
If the replacement panel was DEFAULT, then the migration should retain the DEFAULT flag.
By trying to ensure visibility of the default panel, we accidentally discarded the DEFAULT flag.
This patch provides a minimal fix for not discarding the default flag. It might be better
to rearchitect the whole method, but a minimal solution is preferred for now since this requires
uplifting to beta.
MozReview-Commit-ID: EkbDD7pipgJ
--HG--
extra : rebase_source : 4d6981feefef988fe2a4cb9d3ec294d71896c2b3
Bug 1251362 can result in there no default panel being set (this happens if the history
panel was the default panel before the panel migration). We can reuse the code from a previous
bug which sets history as the default panel if no other panel is set as default.
A second commit fixes the broken migration to ensure that history remains the default
homepanel, however this cleanup migration will help ensure existing clients get fixed.
MozReview-Commit-ID: EcUb2uUfOeJ
--HG--
extra : rebase_source : 41a313d1c0c55900cd3a075128b1d861a155b52e
It's not obvious how to listen to individual errors in most cases, so
we just link to the reports for now. Progress!
MozReview-Commit-ID: 8nGRJdpzZnO
--HG--
extra : rebase_source : e81c9b29cb03c5ba73e793512525b5c9c68ab655
extra : amend_source : ce1e2368d43d37cab8fe41cd7a978342ad3e2ea6
Provide Fennec's implementation of GeckoAppShell.NotificationListener in
NotificationClient. A lot of the code was removed in an earlier patch
from GeckoAppShell, so combined with this patch, we're essentially
moving code from GeckoAppShell to NotificationClient.
Use string names instead of integer IDs to identify notifications. The
integer IDs came from the hashes of the string names, so they are not
guaranteed to be unique. Because the names from Gecko are a combination
of the site origin and notification tag, there can be unintentional
collisions, or worse, a site can intentionally make its notification
collide with and replace another site's notification.
GeckoService and the notification package have some interdependencies,
so if we want to move the notification package, we have to move
GeckoService also. With that said, it's good to move GeckoService in any
case, because it's a Fennec component just like GeckoApp.
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoService.java => mobile/android/base/java/org/mozilla/gecko/GeckoService.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/notifications/AppNotificationClient.java => mobile/android/base/java/org/mozilla/gecko/notifications/AppNotificationClient.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/notifications/NotificationClient.java => mobile/android/base/java/org/mozilla/gecko/notifications/NotificationClient.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/notifications/NotificationHandler.java => mobile/android/base/java/org/mozilla/gecko/notifications/NotificationHandler.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/notifications/NotificationHelper.java => mobile/android/base/java/org/mozilla/gecko/notifications/NotificationHelper.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/notifications/NotificationReceiver.java => mobile/android/base/java/org/mozilla/gecko/notifications/NotificationReceiver.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/notifications/NotificationService.java => mobile/android/base/java/org/mozilla/gecko/notifications/NotificationService.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/notifications/ServiceNotificationClient.java => mobile/android/base/java/org/mozilla/gecko/notifications/ServiceNotificationClient.java
Instead of using NotificationClient directly from GeckoAppShell, add a
NotificationListener interface, which NotificationClient would
implement. This isolates NotificationClient (and the notification
package) from GeckoAppShell and lets us move the notification package to
Fennec. It also makes a cleaner interface for GeckoView consumers to
implement notification support.
General cleanup patch: make JNI methods in GeckoAppShell private if
possible, because they're not meant to be used in Java from outside of
GeckoAppShell.
We decided to remove it because:
* Modern video controls include an exit fullscreen button
* After bug 1031519, you have to swipe down from the top of the screen to
display the soft back button so the copy does not make sense.
Note that the `MozShowFullScreenWarning` event was removed previously in the
platform in [1] so we remove the listener attachment here without replacing it.
[1]: https://hg.mozilla.org/integration/fx-team/rev/a6a5f79e630d
MozReview-Commit-ID: HwyyUkWkUUH
--HG--
extra : rebase_source : 99b81c1f71aca357c3a9ea34e63fc7d20bed994f
This is only there to silence the linter.
MozReview-Commit-ID: 8zEDsrbjyeo
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/UnusedResourcesUtil.java => mobile/android/base/java/org/mozilla/gecko/util/UnusedResourcesUtil.java
extra : rebase_source : be9a886cc2d28a4336690255279f9cf50e9ed047
extra : histedit_source : 43c4512d56f5a01f04ecada6a493107b6ac9581f
Remove following domains from ua-update.json.in:
auctions.yahoo.co.jp
news.yahoo.co.jp
shopping.yahoo.co.jp
travel.yahoo.co.jp
sports.yahoo.co.jp
mixi.jp
Update bug number inline
ANRReporter is a telemetry tool that belongs in Fennec code.
GeckoJavaSampler is a developer tool that belongs in Fennec code.
SwipeDismissListViewTouchListener is only used in FormAssistPopup, which
is no longer referenced in geckoview code.
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/ANRReporter.java => mobile/android/base/java/org/mozilla/gecko/ANRReporter.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java => mobile/android/base/java/org/mozilla/gecko/GeckoJavaSampler.java
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/widget/SwipeDismissListViewTouchListener.java => mobile/android/base/java/org/mozilla/gecko/widget/SwipeDismissListViewTouchListener.java
Separate compiled JARs into GECKOVIEW_JARS and FENNEC_JARS, and run
AnnotationProcessor separately on each set. The GeckoView bindings are
put into widget/android/GeneratedJNI* (same as before), while the
Fennec-specific bindings are put into widget/android/fennec/FennecJNI*.
Compile geckoview sources into a separate gecko-view.jar file, apart
from gecko-browser.jar. This lets us separate JNI binding generation,
among other things.
Because guest mode is intimately tied to the profile, it'd be hard to
keep guest mode out of geckoview code entirely, But we also don't want
any dependency on GuestSession from geckoview code, so this patch moves
the part of GuestSession that manages guest mode state to GeckoProfile.
Remove references to BrowserDB and its factory from GeckoProfile.
Instead of keeping the DB in mDB, GeckoProfile now keeps an arbitrary
object in mData. Using a data object lets us avoid needing another map
to map profiles to DBs. This feature could be very useful for GeckoView
consumers as well.
The new way to get a BrowserDB from a profile/context is through
BrowserDB.from(Context) or BrowserDB.from(GeckoProfile), which takes
care of creating a local DB if necessary and associating the DB with the
profile.
Remove the input method change notification that GeckoInputConnection
sends to FormAssistPopup, so there's no dependency on FormAssistPopup
from inside GeckoInputConnection or GeckoInterface. Instead,
FormAssistPopup now actively queries the current input method, and
performs blocklisting based on that.
Code in geckoview depends on several string constants in GeckoApp.
This patch moves PREFS_OOM_EXCEPTION and ACTION_ALERT_CALLBACK from
GeckoApp to GeckoAppShell, to reverse the dependency. Ideally, we'd want
those constants to not be used or used differently in geckoview code,
but this is a quick workaround for now. GeckoThread uses
GeckoApp.ACTION_HOMESCREEN_SHORTCUT, but that block of code is actually
obsolete, so this patch removes the code block and the dependency.
This patch includes a small memory optimization of using ArrayList and
`volatile int` for storing the pending thumbnails list and pending
width, instead of using LinkedList and AtomicInteger, respectively.
The patch also fixes a possible race condition due to calling
processNextThumbnail outside of a lock. Now it must be called inside a
lock and its name is changed to reflect that.
Move the "thumbnail:" handler out of BitmapUtils and into
ThumbnailHelper and PromptListItem.
The patch adds two overloads of the getAndProcessThumbnailFor method in
ThumbnailHelper, which handle the tasks of getting a thumbnail for a
specific tab and calling a given BitmapLoader.
Because only PromptListItem makes use of the "thumbnail:" convention,
the actual handling of "thumbnail:" is moved to PromptListItem, which
calls ThumbnailHelper to get the thumbnail.
We no longer send viewport metadata, so we don't actually make use of
the RTL and ZoomConstraints variables we keep in Java. There is a single
usage of an RTL flag in ImmutableViewportMetrics.offsetViewportByAndClamp,
but I think the two branches are equivalent, so the RTL flag is not needed
there either.
Don't actually test doorhanger notifications since they are only on the desktop browser and browser chrome tests already check them.
The Android notifyObservers additions aren't used in this patch but I added them for consistency and because we should start to use them for cross-platform tests that check if a doorhanger appears.
MozReview-Commit-ID: B5wK8oqu0h7
--HG--
rename : toolkit/components/passwordmgr/test/notification_common.js => toolkit/components/passwordmgr/test/chrome/notification_common.js
extra : rebase_source : 741f45a7dd64a1b7043040bec90bef4e5fd86c0e
When pressing the back button reaches the beginning of session history for a tab opened from an external app, we both close the tab and send Firefox into background. Closing the tab leads to some other tab getting selected instead - if that other tab was zombified, this means that we'll then start restoring it.
This behaviour is
- visibly distracting, as that other tab will be visible for a split second while it starts reloading before Firefox finally disappears into the background
- wasteful of resources - while restoring a zombified tab is usually done from cache, at the very least we'll waste some CPU cycles reloading a tab even though we're in background
Therefore, in this situation the UI now alerts the session store that it needn't bother restoring that other tab if it's in a zombie state. Instead, we'll restore it the next time Firefox comes into foreground - if the tab is still selected by then.
MozReview-Commit-ID: 3FcjCZrJ0Ds
--HG--
extra : rebase_source : d071884dd1e78b7da470b042e244093e797dde61
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
When restoring a recently closed tab from the corresponding home panel, we normally directly switch to the freshly recreated tab. However if we've entered the home panels through editing mode (as opposed to opening a new tab with about:home), editing mode takes priority and the restored tab is opened in background instead, because we return to the originally selected tab when exiting editing mode.
To fix this inconsistency, we introduce a new parameter for opening tabs from Gecko that cancels editing mode if necessary to allow for directly switching to the new tab.
MozReview-Commit-ID: 4iqPISmtNIx
--HG--
extra : rebase_source : fab9dc911171deef1a984bd96993287d146b370a
This will crash later anyways but throwing here will allow us to identify code
that creates a response with a null bitmap (This shouldn't happen).
MozReview-Commit-ID: LJMSsW51eXo
--HG--
extra : rebase_source : 22eefdc5ba28d36142b663c03f376045fcc542fd
in create(), only register listener if anchorHandle exits.
in opposite side, only unregister listener in same condition.
MozReview-Commit-ID: HHN23YcmwS
--HG--
extra : rebase_source : bdaa3e7b2a56e8e8d6a7776ff7caf3581e99ff09
