I largerly kept this patch the same as Finkle's initial revision except that
I don't include the engine identifiers due to bug 1272166.
MozReview-Commit-ID: 84672CDOOVX
--HG--
extra : rebase_source : 77c63ad35ec1150400e5bf672043c97f161b9bdd
I didn't pay attention while copying telemetry events. We send cancel when dismissing
the prompt, action when the user selects the suggested prompt action.
MozReview-Commit-ID: IAOMRRemCiz
--HG--
extra : amend_source : 0a940fa3109009c85d81765cd4380cd7c227814d
* urlbar-show-origin-only: Only show origin in URL bar instead of full URL (Bug 1236431)
* urlbar-show-ev-cert-owner: Show name of organization (EV cert) instead of full URL in URL bar (Bug 1249594)
MozReview-Commit-ID: AxbrB1gsobh
--HG--
extra : rebase_source : 185088d363fdfe9ba395caa07f05b9c17201e19a
extra : amend_source : 7879f2f122892a1af93f29c9e64f1076ee20191e
This patch was generated by the command:
find . -name "*.css" -exec sed -i -f mozpropsub {} \;
in the root of a mozilla-central tree, with the file mozpropsub
containing the contents:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
While I didn't manually review all the changes, I did review the list of
files, and manually reviewed the changes in the files that I thought
were more interesting.
Note that there are a few tests that should be fixed up as well, but
I'll do that in a later patch.
MozReview-Commit-ID: EiQTuuV0MNQ
This was prompted in review and was discussed in bug so I didn't request
review.
MozReview-Commit-ID: ERgQ3hQnZai
--HG--
extra : rebase_source : c197b93febf275265e0d13891b241ae93c465a0d
Future patches will change the remaining code - This is not yet expected
to compile.
MozReview-Commit-ID: FpqfThcV7dj
--HG--
extra : rebase_source : e01ea217aadd88853d6643c5642d866ba796aa81
These will be used by the Store in the upcoming patches.
MozReview-Commit-ID: 7sPICagdLMu
--HG--
extra : rebase_source : a7ec0a82f48fde4480ab89ec6f39f6e073c31c71
sessionstore.bak, which powers the "tabs from last time" display, is only updated with the data of the previous session if the user chooses to "never restore" tabs, or if we've temporarily disabled session restoring because of too many successive crashes in a row. In all other cases, we restore tabs automatically so sessionstore.bak is never updated with fresh data, meaning its contents get stale pretty soon.
With this patch, we clean up old copies of sessionstore.bak when doing an automatic restore, so they don't linger indefinitely in the "tabs from last time" section of the recent tabs panel.
MozReview-Commit-ID: DrOx5TNwYMv
--HG--
extra : transplant_source : %2Ac%83%F40i%1Ah%3F%B1QI%D6%84%FF%7B%E8%157%F1
extra : histedit_source : 61cc196e844b26e00cf47363c69e6f1672d90f14
See added comment (and bug it references) for details.
MozReview-Commit-ID: CqS5Oy7MPln
--HG--
extra : rebase_source : a64c5d134d0f2d4bc46ede356a5e8517654e9c62
We already return null if the host is empty and all callers seem to handle null values.
MozReview-Commit-ID: 4utRbvf7To3
--HG--
extra : rebase_source : 3236e7d6c518cf1041699101f8eef34b0ef19609
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
We do this by showing history items in the "share" menu item, and
removing the existing "quickshare" item that showed history items.
We also need to shuffle our icon sizes around: our xhdpi icon size matches
the hdpi icon sizes of the other icons in the top bar (modulo padding, which
we need to add as part of this commit), similarly our xxhdpi icon is shifted to
xhdpi. We don't supply an xxhdpi icon at all for any of the icons in the top bar
of the menu, hence that size is removed (and reused for the xhdpi icon, see above).
MozReview-Commit-ID: 7fabPQ5Tyst
--HG--
extra : rebase_source : 5ef599a8a8a2d2a34555169ab0f56d98f0bc1ab6
extra : amend_source : 620947076e7bf4b02a5c3566240a28dc5d9de2c5
extra : source : e6d92ec5cc178d771a0ef2350a653795cdd198e1
This patch adds a "Read now" action to content notifications. Clicking the button
will behave like clicking the notification. However it will send a different telemetry
extra ("content_update_read_now" instead of "content_update").
MozReview-Commit-ID: 4O24xBhjVF4
--HG--
extra : rebase_source : 4bfb9b714b42f0a0259770e054701a3d4592aa87
This patch will create a single Intent action for all content notifications. The intent will be handled by
ContentNotificationsDelegate exclusively.
MozReview-Commit-ID: 5UVVanLLd32
--HG--
extra : rebase_source : 9c6f93aad7f070a847b5f13ff38bbcabef684cf6
We only care about API >= 14, so there's no need for the pre-v11
menu.
MozReview-Commit-ID: 9DdahLRXzpD
--HG--
rename : mobile/android/base/resources/menu-large-v11/browser_app_menu.xml => mobile/android/base/resources/menu-large/browser_app_menu.xml
rename : mobile/android/base/resources/menu-xlarge-v11/browser_app_menu.xml => mobile/android/base/resources/menu-xlarge/browser_app_menu.xml
extra : rebase_source : 2dc4287a5ca8b3b008ae8a2ae962be9d4568f36b
extra : source : a7203a518ca87199bfe729bdbfc6b368d23b8c5f
After this patch, I still occasionally see the toolbar positioned part
way down from the top of the screen. However, this state looks slightly
less janky without the animation I removed and I can't consistently
reproduce it anymore. Given the DynamicToolbar.setVisible calls I make,
I'd guess this is likely to be a bug caused by BrowserApp.onTabChanged
(and thus DynamicToolbar.setVisible) not getting called instantly and
so the DynamicToolbar is initialized to a different location on screen.
I'd guess it's a bug in DynamicToolbar as to why it's positioned partially
off-screen.
There is a little bit of code duplication, but that is because the code
to load a url on a new intent is duplicated (i.e. once from GeckoApp.initialize
- the initial load - and once from GeckoApp.onNewIntent). This could
potentially be cleaned up if we moved the app loading code into onResume,
but that may not be possible since we need to wait for Gecko to start
up.
Additionally, this patch adds a lot of hard-to-follow global state, which is
also not good.
Preferred solution (bug 1269041): show the toolbar each time onStart is
called (i.e. FF is unhidden). This is good for the user - they'll be
more aware which page they're on - but it's janky with the current
implementation, where the page content does not scroll when the toolbar
is shown so previously visible content is hidden. Thus, I went with the
other approach. fwiw, Chrome does this behavior, but scrolls the toolbar
offscreen shortly after it is shown.
This solution is blocked on bug 1245523.
MozReview-Commit-ID: 7JjCrIf4KTm
--HG--
extra : rebase_source : 803cc3e6f940462168a61f0a12b32a0391611caa
This is a temporary fix. The new plugin is able to find more unused resources.
However we are not ready to remove all of them yet. Some of them will be in
use again soon.
This patch will add those files to UnusedResourcesUtil in order to suppress
the lint error.
MozReview-Commit-ID: 7X9Dee6hWDg
--HG--
extra : rebase_source : b4914b322abeba85238d0fe7b4917c7ef4757925
* GeckoActivity, LocaleAwareAppCompatActivity, LocaleAwareFragmentActivity, LocaleAwareActivity:
Those activities are never instantiated directly. Make them abstract.
* CrashReporter: This activity is only registered if MOZ_CRASHREPORTER is set. Supress warning.
Unfortunately I had to downgrade this lint check from "error" to "warning" because the current
gradle plugin doesn't recognize the SupressLint annotation for the "Registered" check:
https://code.google.com/p/android/issues/detail?id=204846
MozReview-Commit-ID: Hy56pZB8ZdB
--HG--
extra : rebase_source : 2f40d84792baaaffd4093e8cb2b17eb1155df5c3
