876498268f8f06b10af90af25b37d1c874264e3f: Bug 1356008 - Fix inconsistencies with strings in about:preferences#applications. r?gijs draft
Jared Wein <jwein@mozilla.com> - Fri, 14 Apr 2017 00:23:53 -0400 - rev 562937
Push 54173 by bmo:jaws@mozilla.com at Fri, 14 Apr 2017 20:03:07 +0000
Bug 1356008 - Fix inconsistencies with strings in about:preferences#applications. r?gijs MozReview-Commit-ID: 5VN48CyHbvx
4a00517b2444e54f05eb47a7b0ec88ea74357db9: Bug 1356006 - Fix inconsistencies with strings in about:preferences#general. r?gijs draft
Jared Wein <jwein@mozilla.com> - Fri, 14 Apr 2017 00:09:57 -0400 - rev 562936
Push 54173 by bmo:jaws@mozilla.com at Fri, 14 Apr 2017 20:03:07 +0000
Bug 1356006 - Fix inconsistencies with strings in about:preferences#general. r?gijs MozReview-Commit-ID: 8hUKm1DeGgr
bf75b41a80194e5d7847e49b091cc1b10b170ac4: 1344924 - Contextual onboarding for search suggestions in the awesomebar. draft
Marco Bonardo <mbonardo@mozilla.com> - Wed, 05 Apr 2017 15:01:02 +0200 - rev 562935
Push 54172 by mak77@bonardo.net at Fri, 14 Apr 2017 19:47:52 +0000
1344924 - Contextual onboarding for search suggestions in the awesomebar. MozReview-Commit-ID: D4rRMRbdMrW
2d2dde2334c710736f019294fa26b50d5bca05e8: Bug 1355522 - Move scripts for spell-checking, hardware acceleration, and on-screen keyboards to main.js since the prefs moved to the main category. r?florian draft
Jared Wein <jwein@mozilla.com> - Wed, 12 Apr 2017 11:08:46 -0400 - rev 562934
Push 54171 by bmo:jaws@mozilla.com at Fri, 14 Apr 2017 19:28:43 +0000
Bug 1355522 - Move scripts for spell-checking, hardware acceleration, and on-screen keyboards to main.js since the prefs moved to the main category. r?florian MozReview-Commit-ID: ExZDYWx92XD
e3ce8a0f87c61ab3f32c9c6952c23f1a01d984ee: Bug 1355522 - Move Telemetry and Health Report prefs to Privacy & Security section. r?florian draft
Jared Wein <jwein@mozilla.com> - Wed, 12 Apr 2017 10:14:51 -0400 - rev 562933
Push 54171 by bmo:jaws@mozilla.com at Fri, 14 Apr 2017 19:28:43 +0000
Bug 1355522 - Move Telemetry and Health Report prefs to Privacy & Security section. r?florian MozReview-Commit-ID: 1Ybpr68SKC0
52721e85ff92ffd9f8aa0765663c3bde5b6eab47: Bug 1355585 - Streamline the format of "handlers.json", align the implementation, and reorganize tests. r=mak draft
Paolo Amadini <paolo.mozmail@amadzone.org> - Fri, 14 Apr 2017 20:04:09 +0100 - rev 562932
Push 54170 by paolo.mozmail@amadzone.org at Fri, 14 Apr 2017 19:20:13 +0000
Bug 1355585 - Streamline the format of "handlers.json", align the implementation, and reorganize tests. r=mak This patch significantly improves the test coverage for both the JSON and RDF back-ends. There is a clearer separation between tests using predefined data and tests for the injection of default handlers. The predefined data includes more significant property combinations, and the JSON is now formatted. Helper functions are renamed for clarity. Functions like "exists" that have different paths for MIME types and protocols are now tested with both, while behaviors that have a single path are now only tested with MIME types for efficiency. The file format is redesigned to be more compact, and all the data is normalized when saving instead of when loading. Duplicates are now handled correctly when saving. MozReview-Commit-ID: JI4I1M0N3lq
98d17809392a4b5a8fd403a047c29f4eeaeb64d8: Bug 986975 - do_QueryInterface abuse in nsAndroidHandlerApp.cpp. r=mak draft
Paolo Amadini <paolo.mozmail@amadzone.org> - Fri, 14 Apr 2017 18:31:16 +0100 - rev 562931
Push 54169 by paolo.mozmail@amadzone.org at Fri, 14 Apr 2017 19:16:47 +0000
Bug 986975 - do_QueryInterface abuse in nsAndroidHandlerApp.cpp. r=mak This change is tested in detail as part of bug 1355585. MozReview-Commit-ID: 5z4evaUQDFI
3e70d2516749bbb586b419d71c298bc6cfb365c4: Bug 1355582 - Only the most recently added file extension is saved in "mimeTypes.rdf". r=mak draft
Paolo Amadini <paolo.mozmail@amadzone.org> - Tue, 11 Apr 2017 20:38:14 +0100 - rev 562930
Push 54169 by paolo.mozmail@amadzone.org at Fri, 14 Apr 2017 19:16:47 +0000
Bug 1355582 - Only the most recently added file extension is saved in "mimeTypes.rdf". r=mak This change is tested in detail as part of bug 1355585. MozReview-Commit-ID: 74nDQjGlFjA
3cf9e20109cc3827540f83e2675943c87704bf90: Bug 1249263 - add a `removeByFilter` method to filter by host,r?mak draft
milindl <i.milind.luthra@gmail.com> - Mon, 10 Apr 2017 19:56:28 +0530 - rev 562929
Push 54168 by bmo:i.milind.luthra@gmail.com at Fri, 14 Apr 2017 19:03:56 +0000
Bug 1249263 - add a `removeByFilter` method to filter by host,r?mak Added a method in History to filter by host and timeframe, which is designed to act as a replacement for `RemovePagesByTimeFrame` and `RemovePagesFromHost` in the old API. The `filter` object accepts both a host argument, as well as a timeframe, and filters as per one or both of them. MozReview-Commit-ID: 8n2AdCllv4V
8dc6925d4c2e6ccf10c324dbd171646ac14eee53: Bug 1356567 - root icons should still create a page association if the domain differs. r=adw draft
Marco Bonardo <mbonardo@mozilla.com> - Fri, 14 Apr 2017 20:34:27 +0200 - rev 562928
Push 54167 by mak77@bonardo.net at Fri, 14 Apr 2017 18:52:14 +0000
Bug 1356567 - root icons should still create a page association if the domain differs. r=adw Root domain icons are no more associated with their pages, BUT if the page uses a root domain icon from another domain, it should still get an association with it or we couldn't relate the two. This also fixes an overlooked problem in PlacesTestUtils where Date objects cross a boundary and fail instanceof checks. This causes failures in the same test that this patch is modifying. To protect from future similar issues some protection has been added to updatedPlaces so that it will crash in debug builds. MozReview-Commit-ID: 3MTKhGj3ehj
f4b09a813cf4f1d6fa6d27e9b4ac886fcf673ecc: Bug 1356567 - root icons should still create a page association if the domain differs. r=adw draft
Marco Bonardo <mbonardo@mozilla.com> - Fri, 14 Apr 2017 20:34:27 +0200 - rev 562927
Push 54166 by mak77@bonardo.net at Fri, 14 Apr 2017 18:51:07 +0000
Bug 1356567 - root icons should still create a page association if the domain differs. r=adw Root domain icons are no more associated with their pages, BUT if the page uses a root domain icon from another domain, it should still get an association with it or we couldn't relate the two. This also fixes an overlooked problem in PlacesTestUtils where Date objects cross a boundary and fail instanceof checks. This causes failures in the same test that this patch is modifying. To protect from future similar issues some protection has been added to updatedPlaces so that it will crash in debug builds. MozReview-Commit-ID: 3MTKhGj3ehj
6812b546cc63ef4a49d4a3435a1bb8fec41d5c96: Bug 1352997 - Part 7 - Don't switch activities if we're closing a tab while exiting the activity. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 14 Apr 2017 19:58:09 +0200 - rev 562926
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1352997 - Part 7 - Don't switch activities if we're closing a tab while exiting the activity. r?sebastian,walkingice Closing the currently selected tab will select another tab, which can trigger an activity switch if the tab types differ. We don't want that if we're about to close the activity, as that'll bring that activity into the foreground instead of simply walking back along the activity history stack. To give an example: Without this patch, closing the last custom tab will select a normal browsing tab, which will trigger an activity switch, so instead of returning to the user's previous activity, pressing back will send us to BrowserApp. There's one additional catch: If we change our onDone() behaviour and no longer finish() the SingleTabActivity when exiting (in order to avoid a costly restart of Gecko should the user return to us soon), this means that the activity that has just been exited could be brought back into the foreground via the onResume() codepath. In that case the mLastActiveGeckoApp-check won't be triggered if no other GeckoApp-based activity was active in the meantime, so we wouldn't reselect/reopen the activity's desired tab, but instead display the tab that was selected when closing the previous tab. Therefore, we track this via an additional flag that is set for this case. MozReview-Commit-ID: 3jOvBXQUrfo
09a48991654bfb0a1ec4b05d94d9ca3e0397ce07: Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 562925
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1352997 - Part 6 - Switch over web apps and implement additional startup logic for them. r?sebastian,walkingice Web Apps are single task activities, but Android's task switcher will only ever return the intent that originally created the activity and will never ever update its stored intent for subsequent launches via onNewIntent, so we have to do this ourselves. Additionally, web apps have some additional logic when being launched via a new intent that checks whether the currently loaded page matches the scope of the web app intent and then resets it if necessary. We now hook up this logic to the new SingleTabActivity wiring. MozReview-Commit-ID: 9bo4gXbfPNg
afe3bf11e631cb4729b48e00a45281498c0840ce: Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:19:32 +0200 - rev 562924
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1352997 - Part 5 - Implement common behaviour for custom tabs/web apps and switch over the former. r?sebastian,walkingice This implements the common behaviour for restoring the correct tab when switching to/from custom tab and web app activities. Unlike our normal UI, those activities are basically single tab activities, that is each activity is linked to a certain Gecko tab, with no facilities (bugs aside) for the user to directly load/select a different tab within that activity. Therefore, here we basically update the selected tab only when the activity is starting up and initially creating its new (or, especially once tab type switching will be implemented, taking over an existing) content tab. When subsequently restoring, we then check whether the tab is still available. If it is, we select it, if not, we fall back to opening a new tab based on the available intent data. This also means that we no longer have to finish() the activity on closing so the activity state (finished) matches the tab (closed), which means that we no longer have to prematurely kill Gecko as a side effect of that. MozReview-Commit-ID: KjFz1qrqWLy
78f59c2d899b75b156d1f3ee36818c6c5ddb1535: Bug 1352997 - Part 4 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:15:19 +0200 - rev 562923
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1352997 - Part 4 - Remember the tab selected by session restoring if somebody other than BrowserApp is starting up first. r?sebastian,walkingice The first activity to run triggers Gecko startup and therefore session restore. Since the selected tab stored in the session file is only of interest for BrowserApp, we need to store it somewhere safe if some other activity (e.g. custom tab/web app) starts up first. This is because currently everything needs to share the same Gecko browser window, so those other activities selecting a tab of their own when starting up will necessarily override session restore's tab selection. MozReview-Commit-ID: 9GwTDbzgWF9
f0c4166eb945e8ee3b7b816217cb17f540cb9587: Bug 1352997 - Part 3 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:55:10 +0200 - rev 562922
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1352997 - Part 3 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian,walkingice Currently, we basically take a snapshot of the currently selected tab when pausing an activity and then later re-select that tab ID when switching back from another activity within our application. In practice, this doesn't seem entirely fool-proof, so when switching between our normal UI (BrowserApp) and custom tabs or web apps we can eventually end up with the wrong tab being selected in the wrong activity. In this part, we'll rip out the current code and replace it by a new implementation for BrowserApp - following parts will then cover custom tabs and web apps. As BrowserApp is our normal tabbed browsing interface, we can simply track all tab switches for BROWSING-type tabs as they happen, which ensures that our data is always up-to-date. Because tab IDs remain unique only within the same application session and are reused if we're terminated and then later restart, we need to take additional precautions to make sure we're really selecting the correct tab object - the savedInstanceState can carry even across (OOM-)kills. Therefore we now additionally also store and compare the current per-session UUID to make sure that the tab we're trying to select is really the same one it was when the activity was last running. For BrowserApp caring about this is less important because on a full startup, the selection behaviour will be overridden by session restore anyway (although we can still hit it if only BrowserApp gets destroyed while Gecko keeps running, or if BrowserApp is launched after some other activity has already loaded Gecko), but it'll be quite relevant for web apps and custom tabs which don't have that benefit. As it stands, this patch temporarily breaks behaviour around activity restoring for custom tabs/web apps, but tearing the old implementation out in one go was easier and the patch needs to be split somewhere. MozReview-Commit-ID: I0Tq9XZGvpV
b75505fa71f41b872ac36c42a4e10b60a8c8652a: Bug 1352997 - Part 2 - Provide dedicated methods for typical homepage operations. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 09 Apr 2017 19:30:21 +0200 - rev 562921
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1352997 - Part 2 - Provide dedicated methods for typical homepage operations. r?sebastian,walkingice That is figuring out whether a homepage has been set (but not caring about the specific page), or else getting the homepage URL with an automatic fallback (to about:home) if no homepage has been set. MozReview-Commit-ID: D6Uy3A4P4Qc
8f53d816e8d0dcc296f1ed74157d56512a9fa30e: Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r?sebastian,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 11:16:13 +0200 - rev 562920
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r?sebastian,walkingice For BrowserApp we want to switch the last selected tab tracking to use tab selection events instead, so we need to register the listener earlier in order to catch the initial selection of the startup tab as well. MozReview-Commit-ID: F7luIE6oNK
e0d2953200c48a66b55b5fb0d1513789beced357: Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian,nechen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 15:43:31 +0200 - rev 562919
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian,nechen Custom and web app tabs behave as any other externally launched URLs, that is pressing the back button closes not only the activity, but the tab as well when reaching the beginning of session history. Therefore, we should finish the activity in this case (just as the CustomTabsActivity already does), so the next launch runs through the onCreate code path and opens a new tab again. MozReview-Commit-ID: 14AhWkmb5O7
9a672e014d00fdf4b7b9c7161b96c23da0e5da99: Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian,nechen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 18:26:45 +0200 - rev 562918
Push 54165 by mozilla@buttercookie.de at Fri, 14 Apr 2017 18:33:01 +0000
Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian,nechen Differences to custom tabs: - We don't have to store the full intent, just storing the manifest path is enough. - Akin to the LauncherActivity we have to route the request to the correct WebAppActivity instance depending on the manifest path. We also have to modify the intent handling when GeckoApp is starting up - the intent handling of the GeckoApp + BrowserApp combo requires "nulling" out (by setting it to ACTION_MAIN) the current intent if it's not a fresh intent (e.g. the activity is recreated after having been destroyed or relaunched from the task switcher). For web apps on the other hand we want to keep the intent around even in those cases, as it contains state we need even later on. Additionally, we want to make use of GeckoApp's startup code for either selecting the tab from the intent or loading a new tab. Therefore we save the launch intent and restore it once GeckoApp's onCreate() has run. Note that this solution is not entirely correct either, because with this each onCreate() call will open a new tab, even when this is not necessary when only the activity (but not Firefox and Gecko as a whole) had been destroyed. This behaviour will be fixed as part of bug 1352997. This approach is also a bit different than the one chosen in bug 1351605 for custom tabs, which was independently developed in parallel. Bug 1352997 will unify this, too. MozReview-Commit-ID: 94uZ3c8CUVD
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip