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
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
