This folder can be opened and closed to get back to the history view, however it doesn't contain any actual content (closed tabs) yet. Its empty view is based on the original empty view of the Recent Tabs panel.
For displaying the recently closed tabs count within the smart folder similarly to how we display the number of synced devices, two new strings need to be added.
MozReview-Commit-ID: IAL0yDrc2Ld
--HG--
extra : transplant_source : %A1%80jZ%1Eg%14p%7D%DD%DD%EA%E8%7E%CA%0E%CD%28%99%3C
Bug 1277277 will track getting this icon used for the search term history, too, so we can remove the old resources (icon_most_recent_empty.png) completely.
MozReview-Commit-ID: GFFovwiRokc
--HG--
extra : transplant_source : %5C%E5%EA%E4%D5%B7%F7%11%8E%DDSG%3C%93%13%DE%18%14%0E%03
OnPanelLevelChangeListener.PanelLevel.CHILD_SYNC really is a mouthful.
MozReview-Commit-ID: 3uEHQjUlTxf
--HG--
extra : transplant_source : %C8%E3%7E%D3%DB%84%92%0DPQ5/a%23%18%8F%8D%FD%BB7
Otherwise, depending on the device's display dimensions, a second smart folder would be overlapped by the empty view message that is displayed when no history is present for the history panel to display.
Once we've updated to a newer version of the support library (see bug 1267884), we should revisit this and see if using "wrap_content" is working properly instead.
MozReview-Commit-ID: 1xBCeiST9n4
--HG--
extra : transplant_source : %E5%A6%C7%DB%8E%DCQ%3D%B29%94%9BZ%EC%0CbJ%0F%08%B0
Because I don't know much about the build system, this may not be an optimal
fix. See the added code comments for more details.
Since this is an annotation processor and they tend to be self-analyzing, my
one concern is that this code uses the classpath in some way to identify which
files need to be kept. That being said:
1) I don't think it makes sense to use the classpath in this way, particularly
when the files we want to operate on are passed as a command line argument.
2) My build did not warn me that the generated JNI wrappers have changed so I
expect no side effects from this change.
MozReview-Commit-ID: 5mm6TClO1Su
--HG--
extra : rebase_source : c1ae4f0e9972f9efd8d6593fcbf27a500a6e0b63
See the added code comments for motivations.
Note that this is a speculative patch - I was unable to reproduce the crash and
thus do not know if it fixes it, however, I did test that the appropriate
toolbar configuration is created on vanilla Android for phone & tablet.
MozReview-Commit-ID: 2v1Ix8X68LH
--HG--
extra : rebase_source : ee32c374d9e2daf1a75975b657cb173dd1432fc3
If we cannot display all search engines then we want to show a smaller number so that the last one is
cut-off (we only display half of it). The previous version did not calculate the next smallest half
correctly: Instead of displaying 3.5 engines if we have space for 3.7 engines, we only displayed 2.5.
MozReview-Commit-ID: KfopL9td3ba
--HG--
extra : rebase_source : 22534e56a0b9668921fc7bc0d5c2f874823645ed
On Android N, the tab button flickers when drawing animations such as the loading progress bar,
or even the tab count increment, over the tabs button. Using hardware layers appears to fix
this. For consistency we could use this across most devices, except those running 4.4 or earlier.
There the button background (light gray) is drawn black with hardware layers, so we should stick
with the default on such devices.
MozReview-Commit-ID: H5VWEkrRbVf
--HG--
extra : amend_source : bf1973e336f9bfc0cdface27b1d2038bf616a45a
We add URL metadata based on the base URL, we should retrieve it this way too.
MozReview-Commit-ID: ICP54V5vRgv
--HG--
extra : rebase_source : ba9444683883f47fe7fa7b5fb7bbca1201ac2f5d
We already pass the URL inside the JSON object.
MozReview-Commit-ID: J4RjxLAzdI
--HG--
extra : rebase_source : 9a4c365fbd2ce4321c84a994db680f8906c13bea
(Backed out changeset 9575e608cabe)
loadUncachedFavicon allows loading favicons from the internet, whereas
getSizedFaviconForPageFromLocal restricts itself to the favicon cache.
(LoadFaviconTask's last parameter is (boolean) onlyFromLocal, which is
set to true in getSizedFaviconForPageFromLocal.
We could probably replace this with an Enum to make the parameter's purpose
more obvious.
MozReview-Commit-ID: C9uwcG0h0N
--HG--
extra : rebase_source : 291dd46988bcbe2dd307bdc3f030daca6bd154bf
Previously the "next" link was hidden on devices such as the Nexus S.
Reducing the size of the top image seems to be the most efficient way
of ensuring that all content fits on screen.
MozReview-Commit-ID: JFCYbXTEKp1
--HG--
extra : rebase_source : 22e0ed9a3a3038a5f8c397a3b575f6aa9449dfdb
extra : histedit_source : 8e66bebb93235670ca0c4262c68d43a19333806d
Apparently this code can crash despite the nullcheck, let's completely
remove it since we don't use the results.
MozReview-Commit-ID: CzHn8kABLYd
--HG--
extra : amend_source : d254ee112a10a115d6a9c44f95a6713931cd4509
By default CalendarView doesn't receive sufficient height on pre-lollipop
devices, in fact the entire dialog won't even appear unless we manually
assign height. This is slightly hacky, but necessary to ensure correct
layouting. (We previously assigned both height and width to the CalendarView,
however that results in all kinds of odd behaviour - this change is necessary
only to have acceptable behaviour on older devices.)
MozReview-Commit-ID: H7wzHsrOJy4
--HG--
extra : rebase_source : 9d3a6c3aab6958b45459a36045ccb8f7f7b165e1
extra : amend_source : 3a7e289e5e237f2cad725b73bd2e5399f5052c70
extra : histedit_source : 03c1b50843e1724058061faad267ce41880123a1
Squashing CalendarView makes it look bad and hard to use - by allowing
it to expand to the dialog width we get a usable CalendarView.
Note that this breaks on Android 4.x. On these devices CalendarView is
implemented using a ListView, which for some reason isn't given
any space during layouting - this results in the actual days in the month
being hidden (we do however see the weekday titles / month title).
MozReview-Commit-ID: wHNx1xG3JK
--HG--
extra : rebase_source : 6eb01c3cd4d9a38d7df516875201ab1eea265828
extra : histedit_source : c99960cd21663875f826894433ba57d99cf0facd
Our current decision criteria is arbitrary: there's no good reason not
to use a CalendarView here. Moreover our previous criteria would result
in small tablets showing different views depending on orientation (Nexus 7:
CalendarView in landscape, pickers in portrait mode).
MozReview-Commit-ID: 8H0HTmCnzfP
--HG--
extra : histedit_source : 70cac01314055881370cf342614c18c2eafceba3
If the src is too long, we crash!
To test this, you can use my test page:
https://people.mozilla.org/~mcomella/test/base64.html
An alternative approach would be to prevent users from sharing base64
images altogether because the experience is slightly jarring (since the
base64 string is copied to the application rather than the image).
MozReview-Commit-ID: AQeQ0Ff6ZMB
--HG--
extra : rebase_source : f265c9c474adaeaef9dd50bde5b9f80c6d5b0f53
On pages that aren't "width=device-width" or similar, Gecko adjusts the resolution when the display dimensions change, e.g. because the device has been rotated. The session store needs to do something similar when restoring a page if the device orientation has changed since the moment the tab state was captured.
Therefore, we now include the width of the browser window in the saved zoom data and use it to scale the zoom level as necessary when restoring a tab.
MozReview-Commit-ID: LBbEquO1bZ9
--HG--
extra : rebase_source : 38465ee3f16dded1d1e953fd3cdbf31b821d4777
Since we're now recording the scroll position in the session data, it makes sense to store the zoom level as well.
To do this, we make use of the new facility introduced in bug 1270019, which allows us to provide a desired initial resolution to the MobileViewportManager. For this to work, we need to send our desired zoom level before the MVM calculates the initial page resolution, i.e. before first paint/page load. Therefore, we now have browser.js notify us of location change events, so we can set the zoom level to restore early enough.
This also means that we can no longer restore the scroll position on load, because the MobileViewportManager applies the resolution we provide it via utils.setRestoreResolution() only after the first paint or page load ( whichever happens earlier). In the latter case, our JS load event handler will run shortly before the MVM has applied the desired zoom level in its own event handling code, which means that any scroll attempt which depends on the page already being zoomed in will fail to apply.
Therefore, the scroll position restoring needs to be moved to a later point in time, i.e. in this case the "pageshow" event.
MozReview-Commit-ID: 6NtYqc8pm3N
--HG--
extra : rebase_source : a6737e5c047ab2327e3a0e52c2a1176e9248a361
This copies the approach we've taken for form data saving and applies it to recording the current scroll position of the page, too.
This means that after receiving a scroll event, we capture the scroll position for the top level document and all direct child frames and include it in the session store data. Because compared to the form data input events the scroll event can fire at a relatively high rate, we throttle the scroll position capturing using timeouts to run at most twice per second.
MozReview-Commit-ID: C0lBxzHav7Z
--HG--
extra : rebase_source : 325c0f92ce003ea9026e3206b4bb101db1f037a7
Parsing the session store JSON data to restore the last session's tabs is both
- computationally relatively expensive
- involving disk I/O
therefore, we shouldn't be doing it on the main thread.
To make sure the session data is actually ready, subsequent code running from a different thread that needs to access it (loading the startup tab, the Recent Tabs panel reading the "Tabs from last time") checks that session store data processing has actually finished and waits if necessary.
MozReview-Commit-ID: EYf1fdglIrA
--HG--
extra : transplant_source : %0D%60F%B0%16%DF%7E%03%CEL%F9%15G%E0%8E%8Fl%21%EEZ
For session data parsing, we need to know whether we were invoked with an external URL or not. Since we want to move session data parsing forward to an earlier point in time, but also continue needing that external URL info during initialize() as well, we'll factor out those calculations into their own functions which can then be called from both places.
MozReview-Commit-ID: HFlT8uxC9yz
--HG--
extra : transplant_source : %A4%AE/%F5%00P%89%95N%033%F3%C6%0E%98%A4%8A%9F%B6%2A
Android Studio doesn't recognise our version guards and is consequentially always showing two errors in GeckoApp, which makes it more difficult to spot when you've introduced an actual error.
MozReview-Commit-ID: LpNIwHOhEWE
--HG--
extra : transplant_source : %22%86%80q%1E%CE%FE%B1%16%BF%40%DF%C0%0F%5D%CB%E0%F8%A0%8A
Delay initialization of PushService and DLC in GeckoApplication to after
the Gecko:Ready message. That way, hopefully they give up some CPU time
to other initialization tasks.
Restoring a tab from the Recent Tabs panel, which goes via the session store's _restoreTabs() function and ultimately via BrowserApp.addTab() and a Tab:Added message back to the Java UI requires the value for isPrivate to be present in the session store data for the respective tab - if it isn't, we end up sending isPrivate as "undefined", which breaks the process of adding the new tab in our UI.
When the session store collects the full tab data for a browser, it always includes the values for isPrivate and desktopMode, therefore we now include those values in the basic session store data we use in initialising a new tab object, too.
MozReview-Commit-ID: 5BZ9PL7xDWA
--HG--
extra : transplant_source : %01%8B%E7%1Asg%FF%D8%DC%07%21Ly%F4%9A9Q%B9%00O
As seen in bug 1274273, the build system is running adb uselessly.
Moreover, on automation, adb doesn't even run, because it requires a
more recent glibc than available, adding confusing error messages to the
logs.
Note: this is currently an experiment, which was previousl de-facto disabled.
MozReview-Commit-ID: 3BfyMD6E3b3
--HG--
extra : rebase_source : 60513a9e78ab88c51f5c28f6ac8d26d0c52b72b7
extra : histedit_source : ff3c66aa8740df5c0fc873f60adb16819265a431
Switchboard might not have any data during onCreate, instead we should query
switchboard when actually deciding whether to show the prompt.
MozReview-Commit-ID: DdulFoWHiF9
--HG--
extra : rebase_source : 0f47a6ae7bccbe0b6ccd88396aa6467df9945ba6
extra : histedit_source : 092b80cf6b096b5b175c24f5d35377aecceaf168
The concept of "background data" (as it exists in the Android options menu)
doesn't exist in the Android APIs - I think it should be covered under
isConnected. Thus, I removed our `isBackgroundDataEnabled` method.
One other network consideration, however: we may want to consider stopping
uploads on roaming.
In the previous implementation, we did not queue the ping for upload if
the network was not connected (in order to conserve disk space). However,
this doesn't allow us to see all of the days the user interacted with
the device (e.g. for engagement) so in this implementation, we always
queue the ping and stop in the UploadService if we're not connected.
MozReview-Commit-ID: 1mjnHq3l7Jj
--HG--
extra : rebase_source : 4640aad21783f8e8edc568ea341a6e910a066d01
These values are what are actually used UI telemetry (perhaps because the enums were added after the strings?). They're also a little less obnoxious than the enum names.
MozReview-Commit-ID: K5i2Hr4DR4J
--HG--
extra : rebase_source : 5750fe71960616ad8014b473c6a5d99c2d3b2dc3
For pending push messages, we used to check for correct profile when the
message is received, but it's better to check for correct profile when
the message is delivered to Gecko.
This fixes a crash in headless mode that the previous patches
introduced.
This patch restores the previous behavior of restoring to guest mode if
Fennec is killed during a guest session. Instead of using a separate
lock file or an Intent argument, this patch uses shared prefs to keep
the guest mode setting.
The patch also introduces the behavior that, for headless mode, the
profile must agree with the guest mode setting. For example, in guest
mode, push messages under a regular profile will not be processed; this
is necessary to avoid profile mismatches.
Treat the guest profile as a custom profile with a special profile
directory. This lets us get rid of a lot of the guest profile handling
code. This patch does not attempt to restore to guest mode if Fennec is
killed during a guest session. A later patch will fix that behavior.
Patch renames GeckoProfile.getFromArgs to GeckoProfile.initFromArgs,
because the method now has possible side-effects (i.e. deleting stale
guest profiles). The new name also differentiates the method from the
GeckoProfile.get family of methods. initFromArgs now always returns a
profile (using the default profile if necessary), to make it easier for
its callers.
When getting a profile with a specific profile directory, we used to
require the directory to already exist. This patch makes sure the
directory is created if necessary. It lets us treat the guest profile as
an ordinary custom profile at a specific location.
This does a few things. First, it makes non-official builds use the
Adjust sandbox. Second, I observe that the fake sandbox key no longer
sends anything, so it's no longer valuable; this patch instead
requires an Adjust token if install tracking is enabled, since we
can't provide a default any more. Third, it removes a spurious
default in configure.in; without this default, builders can easily
enable Adjust locally using the following in their mozconfig:
ac_add_options --with-adjust-sdk-keyfile=/path/to/adjust-sdk.keyfile
export MOZ_INSTALL_TRACKING=1
With the default, the "export" had no impact, because it was
overwritten immediately.
MozReview-Commit-ID: Cn62fmrgwJL
--HG--
extra : rebase_source : 3b817c815043e0339e65125f6d6963ddd3f4570e
This patch changes two things:
* Check if the URL is http/https after stripping the about:reader URL.
* Always call updateAndColorTitleFromFullURL() as fallback for URL formatting (like in previous versions)
MozReview-Commit-ID: 1Zgf12FsOQe
--HG--
extra : rebase_source : d23c2d2d2392be9ae6e9fdaf8d560d5af07f387d
We were experimenting with this on phones, however we decided this
was unnecessary.
MozReview-Commit-ID: LSJILxFO3a
--HG--
rename : mobile/android/base/resources/drawable-hdpi/ic_menu_share_icon.png => mobile/android/base/resources/drawable-hdpi/ic_menu_share.png
rename : mobile/android/base/resources/drawable-xhdpi/ic_menu_share_icon.png => mobile/android/base/resources/drawable-xhdpi/ic_menu_share.png
rename : mobile/android/base/resources/drawable-xxhdpi/ic_menu_share_icon.png => mobile/android/base/resources/drawable-xxhdpi/ic_menu_share.png
extra : rebase_source : a889bf9e1faf5c3c894c28950e8ef7654f38fbb1
extra : amend_source : 130383a287249d0b67701b7d6a1815c7c88fbc5c
For privacy, custom search engines are "other".
MozReview-Commit-ID: GTM7d9k8JFZ
--HG--
extra : rebase_source : c7a1f8ba5694bb05680ea768110eb346dae91be0
This tells the app chooser dialog that appears when downloading a file to use the "Just once" button when two successive taps in a row on the same app have been detected.
MozReview-Commit-ID: Iejs1ROvt6n
--HG--
extra : transplant_source : %D3Y%C4%5D%DB%BC%26%C1Tr%8D%82%1Cmy%A5B%08g%D8
extra : histedit_source : e0e0eb9e7d0a64d86384515c2d93ac527d45e967
On newer Android versions, double tapping an entry in the app chooser is equivalent to tapping it once and selecting "Just once". To enable this functionality for our own app chooser when downloading a file, this patch enables passing a button index to the prompt dialog which will be chosen by default if a double tap has been detected.
To do this, we track the input value we receive in onChange. If we receive the same value twice in a row and a button has been configured, we close the dialogue and pass the result with that button back to the caller.
MozReview-Commit-ID: EVs2x3OtHmB
--HG--
extra : transplant_source : %85Td%83%0D%DD%D0%1D%F48a%5D%A0%CF%B4%A5%CE%5E%22%7E
extra : histedit_source : 190cf52e481b637172ea3b49ccec606f31dc86cf
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
