This restores the functionality to close the menu by pressing the hardware menu key.
MozReview-Commit-ID: EKCeALPvFoB
--HG--
extra : transplant_source : %02%7E%E0%98%40%F3%D1%A4C%FC%CA%7E%CB%96%A2%CC%EDkq%D6
They were previously being set to GONE, causing a measure pass when the
animation started.
MozReview-Commit-ID: FKjB2vJmWkd
--HG--
extra : rebase_source : 25a10f5e8121b48883d8673fa2184ab42a341605
Removing these checks causes crashes when trying to upgrade a <= 17 db to >= 23:
(A) upgradeDatabaseFrom17to18 calls createReadingListTable, and we create the table using the new (>=23 schema).
This schema has no "read" column.
(B) upgradeDatabaseFrom22to23 migrates the same table. As part of the migration it tries to select the "read"
column, and we crash because that doesn't exist. This was prevented by an early return if didCreateReadingListTable
was set.
It looks like removing the didCreateTablsTable checks is OK because the migration only adds a foreign-key constraint,
and doesn't depend on any columns that didn't exist in the initial version of the migration. However it seems wasteful
to run the migration on a table that is already in the expected state. Moreover not having table-created checks is
not safe in most cases, and having these checks should be the default pattern - especially in case any future migrations
affecting the same table are added.
MozReview-Commit-ID: 4j1PlQc6LLN
--HG--
extra : rebase_source : c1811061ac3448666730426b353941bfe3d4814e
This patch introduces consistent theming for all supported devices (Android 4+).
Previously we had Jellybean theming on Android 4, and Lollipop theming on 5+.
Note that dialogs will be based on the native device dialogs (i.e. Jellybean on 4,
Lollipop on 5+). This is because we use native Fragments (and not support library
Fragments), which inflate their own (native) Dialogs. Introducing consistent
dialogs would involve replacing the use of native Fragments (and native
PreferenceFragments), and replacing our self-inflated dialogs.
(We have a few self-built dialogs - these could easily be switched to the AppCompat
AlertDialog, but then we'd have a mix of new and old dialogs on Android 4 devices,
since PreferenceFragment constructed dialogs would still be the native Android
dialogs - overall this would be a worse experience.)
It is also usable on 2.3. There, we retain GB theming, however the checkboxes
are replaced with orange checkboxes (as on 4+).
MozReview-Commit-ID: AXbyAfpvfKi
--HG--
extra : rebase_source : 2b80c8f2beb7939e1f556e91bca87b60ebe4368e
This caused a StrictMode violation on startup.
MozReview-Commit-ID: Ip2ywUoexOh
--HG--
extra : rebase_source : 12bb7cc010b82a03f80f8c1b9a01e9acbf67c13c
extra : source : faa74a9297c8476f965a5f9268d5b9095458dd2b
String resources are shared with the main app menu, and will therefore be remove
in Bug 1234319 which aims to remove those items.
MozReview-Commit-ID: 1NUBskBC10l
--HG--
extra : rebase_source : 579955aa6f10322a57105947a0b25065dbe92c55
extra : histedit_source : d09a951b2e661d80c8270dc12f0c08cc1eb62930
We'll kill this panel in a few weeks, hence we don't really care about
duplication here.
MozReview-Commit-ID: 5XSS3ROa5P3
--HG--
rename : mobile/android/base/resources/layout/firstrun_sync_fragment.xml => mobile/android/base/resources/layout/readinglistpanel_gone_fragment.xml
extra : rebase_source : ce339a412d248a51c8d9cf5250a7b91b3876f711
extra : histedit_source : 481e705dc0a75d92e166ff0a5a27206189d4a8f0
We will already switch to the currently open tab, so we need to ensure we
show the "switch to tab" indicator.
MozReview-Commit-ID: 9q1kDM2flSi
--HG--
extra : rebase_source : 6fddaf7da9de4ea5944e4b7c1c5ff43738cce218
extra : histedit_source : 4f2e57c2ce178aecd80a04b1e842b0e2b29b0ac2
This means we can see the readercache availability not only inside bookmarks, but also
in most other parts of the awesomescreen, since we use TwoLinePageRow for most items
(history, bookmarks, topsites, search results etc).
MozReview-Commit-ID: 8SxE8VabIK9
--HG--
extra : rebase_source : b06d945cbe31b93e21c3a171f53cc9f6143de8d8
extra : histedit_source : ab8eab075e3fc6123f9694561140e306df5375db
We hash the page URL to produce a filename for each cached reader view page. For the purposes
of the rl-migration we need a Java implementation, however the canonical implementation
lives in the current JS readercache (which might be removed in future...). This test
should help ensure that we don't lose saved items during the migration.
We could extract getReaderCacheFileNameForURL(), however it seems safer to make it
public instead - this makes it obvious that this is a migration-only method that
shouldn't be modified/reused in future.
MozReview-Commit-ID: GNg20nszMh9
--HG--
extra : rebase_source : 33af7e38fa7e74287515bcf5cf2521978d8978a0
extra : histedit_source : 9fe9fcae7595b450491a0fb482ffdc73b5b6f344
When opening a new tab, there is a small window between tab creation and the DOMTitleChanged event firing where the tab - if it is not created as a delay loaded zombie tab right away - won't have any session store data. However a number of functions (tab zombification and restoring of zombified tabs, undo close tabs) depend on the session store data always being available, so things can fall apart if e.g. a zombification is triggered immediately after opening a new tab.
This also means that a tab which is zombfied immediately after its creation (e.g. when a number of tabs are opened through tab queues on startup) is not included in a session save and will therefore get lost if Firefox is killed.
Therefore, we now always intialise new tabs with some basic session store data.
MozReview-Commit-ID: 9248jJFUaq5
--HG--
extra : transplant_source : %BC%7Ci%20%82%1E7%29%9E%0E7%87%ED-%0B%E0%84%86R%F9
As long as a tab is kept in memory, Gecko handles restoring of the form data during forward/back key navigation internally without involving the session store. After going back/forward, OnTabLoad() is triggered, which throws away the previous session store data for that tab and recreates only the session history part of it. Form data is only captured in OnTabInput(), which means that if Firefox is killed or the tab closed/zombified before the user interacts with the form (triggering input events), form contents won't be captured by the session store and will therefore get lost.
MozReview-Commit-ID: LmZlYrHjw6k
--HG--
extra : transplant_source : %3B%8B%E5%83%CE%EB%FC%25%B7yq%D3%19%10%8F%85%0A%8Do%B7
Previously, when restoring a tab, we made a copy of the whole session data from which we would then extract and restore the form data - if present - after page loading had completed.
With the changes from bug 852267, the original session data - containing any eventual form data - is now always reattached to the restored tab object, therefore we no longer need to make a copy of it. Instead, OnTabLoad() has been adapted to preserve the formdata if it is needed for restoring later on.
MozReview-Commit-ID: D9fQxtVnuZe
--HG--
extra : transplant_source : pl0%21%2C%8C%07Y%8E%5D%D5%F8wa%2A4%DBU%B5%9F
As a follow-up to bug 1259653, fix a few places where we still treat
empty-name profiles as the default profile. That should fix the
testFilterOpenTab perma-failure.
These are mostly used in TestGeckoProfile.
MozReview-Commit-ID: DRNhswTQmOg
--HG--
extra : rebase_source : ef257e395907ce1931afa1376e6b319b6f6a6591
extra : histedit_source : bd9e0d407ee25430aa9df337ec48809b333f1dd2
See https://code.google.com/p/android/issues/detail?id=78293.
MozReview-Commit-ID: HNcSaCEBlwX
--HG--
extra : rebase_source : 06fba8b50cb328ec89dcaba14b484d27be252d66
extra : histedit_source : bae8cce48194be5b4b9d3958400d6d99c0fb5d5d
testAxisLocking, testFlingCorrectness, and testPanCorrectness depend on APZ,
which isn't currently riding the trains. The Android robocop harness doesn't
support using the fail-if annotation, which would be preferable, so we're
just skipping the 3 tests on !trunk instead.
--HG--
extra : rebase_source : 6fb075e376da2a607bf27a01ec3bf885f835eecb
Adding the auto-completion text in the URL bar triggers selection change
notifications on Android 5.0 and above. That led us to think the user
changed the selection, and in turn commit the auto-completion. This
patch makes us ignore this edge case and preserve the auto-completion.
Inform Gecko of the Android process lifecycle by calling
GeckoThread.onPause and onResume, so that Gecko is more likely to be in
a consistent state if Android kills our process.
GeckoThread.waitOnGecko blocks the current thread and waits for previous
events on the Gecko thread to finish executing before continuing. This
is implemented by synchronously running a dummy event on the Gecko
thread. This patch also lets us get rid of sendEventToGeckoSync in
GeckoAppShell.
This bug changed the meaning of profiles with empty names (""). It used
to mean the same thing as a null name, which represents the default
profile. However, the new behavior is that an empty name indicates a
custom profile. So the tests involving empty names are removed from
testGeckoProfile.
Add GeckoThread.initWithProfile that make it easy to target a particular
profile. The method succeeds when GeckoThread has not been initialized
or is already using the specified profile. It fails when the current
profile does not match the specified profile.
Make sure we treat profiles under a custom directory differently. To
simplify things, custom profiles must already exist, and we don't
attempt to cache instances of GeckoProfile containing custom profiles.
Custom profiles are an edge use case (must be passed in via Intent
arguments) so I think it's reasonable to have this behavior change.
Only determine GeckoThread arguments when GeckoThread has not been
started in GeckoApp. Otherwise, if GeckoThread has already started, we
don't need those arguments.
GeckoProfile.get() was reaching into GeckoApp to get and set the current
profile. I think now that GeckoThread is managing the profile, we don't
need that anymore. Also move the GuestSession check to getFromArgs, and
get rid of GeckoApp.getDefaultProfileName and
GeckoProfile.sIsUsingCustomProfile, which are redundant now.
Because Gecko itself can only handle one profile per process, we should
let the GeckoThread singleton manage our GeckoProfile instance on the
Java side, instead of using GeckoApp.
Run checkstyle via:
./mach gradle app:checkstyle
This is intended to be added to automation in bug 1258787 and made more robust
in bug 1261486.
For the addition of future checks, it's worth noting Google's config is
available:
3e4367941c/src/main/resources/google_checks.xml
And this version contains links with descriptions of each of the tasks:
http://checkstyle.sourceforge.net/google_style.html
MozReview-Commit-ID: 5HvtQsyY2JQ
--HG--
extra : rebase_source : ea45bcfb88ec302e9f6e6526d9afdbf2c9c93f01
Since we're now triggering zombification events, we can easily handle resetting the audio playback indicator upon zombifciation by having the tab object listen for the appropriate TabPreZombify event and handle it alongside the normal DOMAudioPlayback events instead of duplicating that functionality within the memory observer.
MozReview-Commit-ID: JSgGyw9g6Lm
--HG--
extra : transplant_source : 1%0D%E5%D2d%E2%23%87%60%96%86m%F1%FA%C8%7E.r%B5%8C
Michael Comella
Mark Capella
William Chen
Wes Kocher
Margaret Leibovic
Jorick Caberio
Mouaad Aallam
bzrd_Sdn
Michael Kaply
Jan Henning
Andrzej Hunt
Sebastian Kaspari
Carsten "Tomcat" Book
Chenxia Liu
Geoff Brown
Andrzej Hunt
johndai1984
Junior Hsu
Ray Lin
Kartikaya Gupta
Ryan VanderMeulen
Nick Alexander
Mike Hommey
Jim Chen
Mihai Pop
Makoto Kato
Randall Barker
Kyle Huey
Alexandre Poirot
Jeff Muizelaar
Dinesh Polathula