We want to have equal paddings for the top and right hand side of the
menu, whereas we previously had 24dp padding for the top, and only 8dp
on the right.
Note: the padding is defined in the 9-patch files, this commit simply
removes empty vertical space from the top of the menu background images.
MozReview-Commit-ID: Db0hXsPOVpp
Note: this commit alone results in the menu looking slightly odd
due to different top and right paddings. These are fixed in the
next commit.
MozReview-Commit-ID: AWzYU067K0W
The icons in the first row require more padding. In the second
row the share icons should have more padding, but only on phones,
and all other icons should remain the same size. (On tablets
the share icon can be shown beside the bookmark star, hence
we use an inset drawable to add padding on phones, and then
provide an alternative 0-inset on tablets to avoid any changes
there.)
MozReview-Commit-ID: 54NzYtUpzuV
--HG--
rename : mobile/android/base/resources/drawable-hdpi/ic_menu_share.png => mobile/android/base/resources/drawable-hdpi/ic_menu_share_icon.png
rename : mobile/android/base/resources/drawable-xhdpi/ic_menu_share.png => mobile/android/base/resources/drawable-xhdpi/ic_menu_share_icon.png
rename : mobile/android/base/resources/drawable-xxhdpi/ic_menu_share.png => mobile/android/base/resources/drawable-xxhdpi/ic_menu_share_icon.png
These images were incorrectly saved, leading to the loss of the smooth
edges they should have. This commit replaces the edited bookmark stars
with higher quality versions.
MozReview-Commit-ID: 1Z8FfWrvl8H
BrowserApp has a snippet that tries to restart in guest profile if we're
supposed to be in it, but are currently not. This is vestigial code from
lock screen widget support, and should not be needed anymore.
When we try to restart Fennec immediately after launching Fennec, it's
possible for onPause to be called without a corresponding onResume being
called first. This patch guards against registering events twice due to
this quirk.
This allows us to restore the previously opened bookmarks folder when returning to
the bookmarks panel. I.e. when you open a bookmarks folder (including the smartfolders),
select a bookmark, and then return (via the back button, or quick-history via long-pressing
the back button), we will return to the bookmarks folder that was opened.
We don't persist the scroll position, that's a separate issue, in Bug 993552.
MozReview-Commit-ID: 3EhIvlXOgAU
--HG--
extra : rebase_source : 17e903622d20a922d46c1319191b051cf592a4c0
All home panel state is currently discarded when you navigate to another page.
We want to be able to restore state (e.g. to return to the currently opened bookmarks folder,
instead of returning to the root of the bookmarks folder). This commit adds storage and a framework
to allow homepanels to persist data.
MozReview-Commit-ID: GWDX7UZrIZs
--HG--
extra : rebase_source : d0959196e14496b7970ad14df39937c67013624f
I initially wrote the "ForGivenDate" variant for testing purposes - so I could
verify the daylight savings time APIs worked the way I expected them to.
However, I ended up using it in my next patch and leaving in the generic "for
current time" variant because it seems useful.
MozReview-Commit-ID: 4hNGD4uDuOj
--HG--
extra : rebase_source : 56cd92c7ef95aa5ca54daa27d93f56a053f7b4df
The format we chose comes from Desktop - bug 1144778.
MozReview-Commit-ID: 9eXb78d70pM
--HG--
extra : rebase_source : 937e121be41bb587764029d8abcc72bd183e7328
This patch restores our previous <activity-alias> with all intent filters. Changing the alias
will cause that existing home screen shortcuts disappear.
I tested this patch with:
* Upgrading old state (2016-02-06) to current state: Icon disappears (expected)
* Upgrading old state to fixed state (this patch): Icon remains
As this patch changes the activity-alias again, releasing this patch will lead to the home
screen shortcut disappearing once more for all released version with the current state:
* Upgrading current state to fixed state: Icon disappears (expected)
MozReview-Commit-ID: 1crKmkp4G1L
--HG--
extra : rebase_source : d6e84902fd8f763676ed315d8da9f9da96eb5c8c
extra : histedit_source : 6e715c605f43a463cc04f069d62f9d4ca17587f4
Without the bfcache, the inner value will not be restored after a page navigation, therefore we need to make sure that the bfcache isn't disabled by a stray memory pressure event before or during the test.
MozReview-Commit-ID: 3k1EgGDEPb
--HG--
extra : transplant_source : %E7%C9%BCD%E3%A4P%7F%A8%04%F4%CE%96bw%D6PU%97%01
During tests that open additional tabs, the main test tab controlling the test is at risk of being zombified if a memory pressure event arrives, which breaks the test and leads to the test timing out. Therefore, we now disable background tab zombifications during tests.
This means that there's a slightly increased risk of being OOM killed instead, however
- the tabs opened by the tests themselves are normally relatively short-lived anyway
- we're no worse off than if the tab containing the test harness code had been zombified.
MozReview-Commit-ID: 1Ntvn4yjWlZ
--HG--
extra : transplant_source : %E78%93%3B%0F%5DnX%BC%E6G%10%B2%B5%1B%3A%9F%CE%F9%DD
- specifying states, events and transition side-effects explicitely makes this code easier to read/maintain
- move bunch of network state helper methods into NetworkUtils
- ensure to update both network state (up/down/unknown), as well as connection type/subtype every time we need to update network state
-- this should fix the buggy behaviour when we'd miss certain network state transitions
- tests for the FSM transition matrix, and everything in the NetworkUtils
MozReview-Commit-ID: LvrfHyFdkpB
--HG--
extra : rebase_source : 4429d80f78435205915f27e738e4886f1c46d3fa
Opening/navigating within/restoring a tab seems to be relatively slow on the emulator and as we want to test whether form data is preserved by the session store after closing and restoring a tab, quite a bit of time is accumulated that way.
MozReview-Commit-ID: 3LhLuZIZ2z7
--HG--
extra : transplant_source : %C7%22%90%DFy%97%BCD%B3%17%FE%F0%09%7FQ6V%D4%0E%1B
There is no window in the normalData when clearing browsing history on quit with tab restore set to "never restore", which breaks the assumption made in the logging function. It also means that in that case, the current session will show up as "Tabs from last time" on next startup despite wanting to clear the history on exit.
MozReview-Commit-ID: Ft4jdomopFL
--HG--
extra : transplant_source : %A5as%14%06%1F%BD%B7c%28%3Bb%A6%A7%19U%2C%1C%2CA
This simplifies some old code. We get rid of a whitelist of services, and rely on the face that accessibility and explore by touch is enabled to enter our internal accessibility mode.
The whitelist methode held 2 assumptions that are not true anymore:
1. There are some non-accessibility accessibility service apps in the wild that read notifications.
In later Android versions this has been made into a non-a11y use case with NotificationListenerService. So the cases of non-a11y accessibility services has shrunk.
2. Not all screen readers (Gingerbread TalkBack, for example) supported explore by touch. Today, we
exclusively support accessibility services that use explore by touch, and we should not activate our
accessibility mode in any other case.
MozReview-Commit-ID: LMeCedoIGbb
This should guarantee that any reader view page will also be successfully saved offline.
MozReview-Commit-ID: 4J8cY6hYeyU
--HG--
extra : rebase_source : 689a2db7a7d81dbe89e5e58c170afe473563b2f6
Note: some delegates might live in other packages, e.g. our HelperUI
related promotions (HomeScreenPromotion, ReaderViewBookmarkPromotion)
live in org.mozilla.gecko.promotions.
BookmarkStateChangeDelegate previously lived in promotions, however
it isn't really a promotion (we're just showing snackbars, and showing
one helper UI to explain offline reader view bookmarks _after_ such
a bookmark has been created), hence it seems a better fit for delegates.
MozReview-Commit-ID: 6fQD3FWzqnm
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/promotion/BookmarkStateChangeDelegate.java => mobile/android/base/java/org/mozilla/gecko/delegates/BookmarkStateChangeDelegate.java
rename : mobile/android/base/java/org/mozilla/gecko/BrowserAppDelegate.java => mobile/android/base/java/org/mozilla/gecko/delegates/BrowserAppDelegate.java
rename : mobile/android/base/java/org/mozilla/gecko/ScreenshotDelegate.java => mobile/android/base/java/org/mozilla/gecko/delegates/ScreenshotDelegate.java
extra : rebase_source : 1c0286e6074233bdd2e32fd7309e7eddf01cfb13
extra : histedit_source : 1ade7d494a373895629e0fa7cf786510524f08d0
This simplifies some old code. We get rid of a whitelist of services, and rely on the face that accessibility and explore by touch is enabled to enter our internal accessibility mode.
The whitelist methode held 2 assumptions that are not true anymore:
1. There are some non-accessibility accessibility service apps in the wild that read notifications.
In later Android versions this has been made into a non-a11y use case with NotificationListenerService. So the cases of non-a11y accessibility services has shrunk.
2. Not all screen readers (Gingerbread TalkBack, for example) supported explore by touch. Today, we
exclusively support accessibility services that use explore by touch, and we should not activate our
accessibility mode in any other case.
MozReview-Commit-ID: LMeCedoIGbb
--HG--
extra : rebase_source : 69dd7ab6868fd09b0b6529efacd215157305b1c9
This overwrites a commit I did at the beginning, but fixing the version control
would have been a waste of time.
MozReview-Commit-ID: Ry9WRpTf8s
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/telemetry/core/TelemetryCorePingBuilder.java => mobile/android/base/java/org/mozilla/gecko/telemetry/pingbuilders/TelemetryCorePingBuilder.java
rename : mobile/android/base/java/org/mozilla/gecko/telemetry/TelemetryPingBuilder.java => mobile/android/base/java/org/mozilla/gecko/telemetry/pingbuilders/TelemetryPingBuilder.java
rename : mobile/android/tests/background/junit4/src/org/mozilla/gecko/telemetry/TestTelemetryPingBuilder.java => mobile/android/tests/background/junit4/src/org/mozilla/gecko/telemetry/pingbuilders/TestTelemetryPingBuilder.java
extra : rebase_source : 55ff9e25b8ba49ba29a3111b92b77a16a4ffc788
I would have folded this but I screwed up but the version control is getting
messy.
MozReview-Commit-ID: 3LaYkrao4dD
--HG--
extra : rebase_source : 2fe2f6ced974b6fe55ecaed0c34caef58ed8c11a
Ideally, we'd just not run the service but skimming, I see no clean way to do
that with the existing code.
MozReview-Commit-ID: HRU1PAmYoil
--HG--
extra : rebase_source : 63074ae8dcd2613ff90d3f431fe2e58f51364e03
I would have done this sooner but it's a version control nightmare.
I made the change because it's harder to grep for logs when the logtag doesn't
include "Telemetry".
MozReview-Commit-ID: GD8Cb8D5CRy
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/telemetry/stores/JSONFilePingStore.java => mobile/android/base/java/org/mozilla/gecko/telemetry/stores/TelemetryJSONFilePingStore.java
rename : mobile/android/tests/background/junit4/src/org/mozilla/gecko/telemetry/stores/TestJSONFilePingStore.java => mobile/android/tests/background/junit4/src/org/mozilla/gecko/telemetry/stores/TestTelemetryJSONFilePingStore.java
extra : rebase_source : 754912d199c84ab166b58a3ddd7c4f0e8d80bde3
There is less to store on disk and it's probably more correct.
MozReview-Commit-ID: KAJAE1M7Fzv
--HG--
extra : rebase_source : ef226ea7b7d0ce03e216eb640dff30245551cc55
Note: this is the first commit expected to compile.
MozReview-Commit-ID: Fc8uRkJAXgB
--HG--
extra : rebase_source : c34096f6123fa898b3b3553b2914122f4ff92143
Thoughts:
* An alternative design put this code in a CorePingUtil but I decided these
methods are tied closely to the TelemetryCorePingBuilder.
* Adding these methods makes it less clear what the class is about (without
filtering on public methods that is).
I'm not sure what the best trade-off is.
Note: this is not yet expected to compile.
MozReview-Commit-ID: FQYFP3ioewN
--HG--
extra : rebase_source : 660c66cb5bb38928b9e532e1861ff7c8c3169187
Note: for version control and review simplicity, this does not yet compile.
MozReview-Commit-ID: EvccGtseOKT
--HG--
extra : rebase_source : 9572d2df3a306ca4b51b1af464a21161db66ba78
I'm thinking it's better to have constants with the classes they're most
closely associated with rather than one giant constants file because it becomes
hard to find anything in a large constants file.
MozReview-Commit-ID: D3SCkW3vbRM
--HG--
extra : rebase_source : 37611c82f84ba011c763554c6793bef63c093faa
Since the history restore code now apparently supports restoring subframes, too, we should let the mobile session store capture frameset navigation as well, so we can preserve the full browsing history.
MozReview-Commit-ID: 5SM8eMTfgIH
--HG--
extra : transplant_source : IO%1Bz%CA_%14%D0D%F9Q%FBA%E5S7%85%90%AE%C0
