b2aa68160a870ab732a7bf34985eb0165391b2b6: Bug 1350226 - Support for loading Editor in Launchpad r?honza draft
Ricky Chien <ricky060709@gmail.com> - Sat, 08 Apr 2017 18:33:07 +0800 - rev 558887
Push 52979 by bmo:rchien@mozilla.com at Sat, 08 Apr 2017 10:45:32 +0000
Bug 1350226 - Support for loading Editor in Launchpad r?honza MozReview-Commit-ID: AHkG0KBQUTA
060b032a2aa199798947e5035d239a693f5db1aa: Bug 1350226 - Support for loading Editor in Launchpad r?honza draft
Ricky Chien <ricky060709@gmail.com> - Sat, 08 Apr 2017 18:33:07 +0800 - rev 558886
Push 52978 by bmo:rchien@mozilla.com at Sat, 08 Apr 2017 10:33:58 +0000
Bug 1350226 - Support for loading Editor in Launchpad r?honza MozReview-Commit-ID: AHkG0KBQUTA
f4a263070d97416d96fe67dc6c47a3a443b1aa62: Bug 1352699 - Fix mochitest failures r?honza draft
Ricky Chien <ricky060709@gmail.com> - Wed, 05 Apr 2017 22:59:57 +0800 - rev 558885
Push 52978 by bmo:rchien@mozilla.com at Sat, 08 Apr 2017 10:33:58 +0000
Bug 1352699 - Fix mochitest failures r?honza MozReview-Commit-ID: 8rhAQw5oflC
2b3f13f79a914f1f85cac2b945f3e30f06f91482: Bug 1352699 - Make netmonitor run on devtools-launchpad r?honza draft
Ricky Chien <ricky060709@gmail.com> - Sat, 01 Apr 2017 23:01:06 +0800 - rev 558884
Push 52978 by bmo:rchien@mozilla.com at Sat, 08 Apr 2017 10:33:58 +0000
Bug 1352699 - Make netmonitor run on devtools-launchpad r?honza MozReview-Commit-ID: 4khCXm2lfzG
bed4ac7fffe9e2c5b95803fcbc620d0ffedd3e0d: Bug 1348252 - Disable buttons and display loading message in Site Data section while loading data, r=Gijs draft
Fischer.json <fischer.json@gmail.com> - Wed, 05 Apr 2017 22:28:30 +0800 - rev 558883
Push 52977 by bmo:fliu@mozilla.com at Sat, 08 Apr 2017 10:28:05 +0000
Bug 1348252 - Disable buttons and display loading message in Site Data section while loading data, r=Gijs MozReview-Commit-ID: 9EfG71hRoDe
61a411f8ae20304e161269c928f82df08833e846: Bug 1352997 - Part 4 - Implement additional startup logic for Web Apps. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Tue, 04 Apr 2017 21:50:33 +0200 - rev 558882
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1352997 - Part 4 - Implement additional startup logic for Web Apps. r?sebastian 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
809edb3acd1b94c0e7a059695b732e23822632b2: Bug 1352997 - Part 3 - Remember the correct tab for CustomTab/WebAppActivities. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 05 Apr 2017 22:38:09 +0200 - rev 558881
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1352997 - Part 3 - Remember the correct tab for CustomTab/WebAppActivities. r?sebastian 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, once tab type switching is implemented, taking over an exisiting) 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. MozReview-Commit-ID: KjFz1qrqWLy
65efb9634daf31b8ce5c57bba8ba4d93635662aa: Bug 1352997 - Part 2 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 11:28:01 +0200 - rev 558880
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1352997 - Part 2 - Re-implement tracking of last selected tab for BrowserApp. r?sebastian 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 are not unique across Gecko restarts, while the savedInstanceState can carry even across (OOM-)kills, we now additionally also store the respective tab object's hash 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 this is less important because on a full startup, this 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 break 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: 9GwTDbzgWF9
4c9e568b7efff53fbb09d8c05e8ebd0b196fc2bd: Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 11:16:13 +0200 - rev 558879
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1352997 - Part 1 - Register GeckoApp's onTabsChangedListener earlier. r?sebastian 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
0f845366833b39ac419fa99ef2106bd4524d66bc: Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 15:43:31 +0200 - rev 558878
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part 6 - Finish the WebAppActivity when closing via onDone. r?sebastian 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
ec832a91a1eb5b4275127c491af9bf72f0fc9797: Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 18:26:45 +0200 - rev 558877
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part 5 - Implement activity switching for web apps. r?sebastian 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 - especially for custom tabs - 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
9b731f5b12ed2354de937a8725527caba6882ccb: Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 01 Apr 2017 17:07:16 +0200 - rev 558876
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part 4 - Handle selected tab temporarily being undefined. r?sebastian I think this can happen if closing a tab (via the back button) simultaneously also triggered an activity switch (by selecting the parent tab). In that case the tab is closed, but formal selection of the new tab only completes after we've switched activities. At the moment activity switching might trigger an application-background/foreground cycle, which means we could hit the selected tab temporarily being undefined in Gecko. MozReview-Commit-ID: 6p4cOqj29HX
ed4cea3a52a86612e7c0ac79be6297b5d16d61a0: Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 05 Apr 2017 21:37:57 +0200 - rev 558875
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part 3 - Switch activities when a custom tab is selected/unselected. r?sebastian On tab selection, the Tabs instance now checks whether the type of the tab to be selected matches the currently selected activity. If it doesn't, the tab switching is aborted and instead, an intent for the correct activity is sent. When the new activity launches, it finds that the intent also includes a tab ID, which means that instead of opening a new tab we retry the tab selection, which will then succeed now that we're in the correct activity. Because for custom tabs the launch intent can contain all sorts of customisations, we now have to save the intent when a custom tab is opened for the first time, so that later on, when switching e.g. from BrowserApp back to a custom tab we can use the correct intent to launch the custom tab activity. MozReview-Commit-ID: KWdkweKBocz
273bcabc35e7f595d588a8ce7b520a86abed0f8f: Bug 1351739 - Part 2 - Convert CustomTabsActivity to SafeIntents. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 14:09:36 +0200 - rev 558874
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part 2 - Convert CustomTabsActivity to SafeIntents. r?sebastian These are potentially untrusted external intents, so we should use SafeIntents for interacting with them. MozReview-Commit-ID: 3nmjg85wbr1
b70b7b5bd3332b2f6a0c74df82ac85dd5df4ebfd: Bug 1351739 - Part 1 - Track the currently active activity. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 02 Apr 2017 11:22:12 +0200 - rev 558873
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part 1 - Track the currently active activity. r?sebastian Required because later on, we'll need to know if we're in the correct activity for a tab or need to switch activities. As a follow-up, we can later also hook up our current manual activity tracking from GeckoApplication to this (we most probably won't be able to get rid of the GeckoActivityStatus shenanigans, though). MozReview-Commit-ID: 5lZrAMsB9Gy
3e5d6b94646e34eac56753aa4fc0d378dcf360bd: Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 06 Apr 2017 21:30:55 +0200 - rev 558872
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part 0 - Use INVALID_TAB_ID more. r?sebastian -1 is probably not all that mysterious as far as magic numbers go, but still... MozReview-Commit-ID: zK3P6HeWzK
fa2998f99295d3b4708950cbb09ad2beb20e1733: Bug 1351739 - Part -1 - Housekeeping. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Fri, 07 Apr 2017 20:51:41 +0200 - rev 558871
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Bug 1351739 - Part -1 - Housekeeping. r?sebastian MozReview-Commit-ID: Ev6jl4N3K0g
6716246511948f857e8960053c23d9f206e389b4: Local Gradle tweaks draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 28 Jul 2016 20:04:34 +0200 - rev 558870
Push 52976 by mozilla@buttercookie.de at Sat, 08 Apr 2017 09:40:44 +0000
Local Gradle tweaks MozReview-Commit-ID: H5pdKja8p2a
e7582f89ad1ea49ab36327a45bc97f7ff140ae75: Bug 1351535 - Part 9: Call StyleSubtreeForReconstruct when doing frame reconstruction. r=bholley draft
Cameron McCormack <cam@mcc.id.au> - Tue, 04 Apr 2017 19:36:09 +0800 - rev 558869
Push 52975 by bmo:cam@mcc.id.au at Sat, 08 Apr 2017 09:24:07 +0000
Bug 1351535 - Part 9: Call StyleSubtreeForReconstruct when doing frame reconstruction. r=bholley MozReview-Commit-ID: HxoGLPKJpnt
06d9b89d08c2e88a4eaf75372ed0e68cfcde1448: Bug 1351535 - Part 8: Add ServoStyleSet::StyleSubtreeForReconstruct. r=bholley draft
Cameron McCormack <cam@mcc.id.au> - Tue, 04 Apr 2017 19:34:30 +0800 - rev 558868
Push 52975 by bmo:cam@mcc.id.au at Sat, 08 Apr 2017 09:24:07 +0000
Bug 1351535 - Part 8: Add ServoStyleSet::StyleSubtreeForReconstruct. r=bholley MozReview-Commit-ID: CovU36o4lAV
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip