90f79b6f4a2d8d925dd20eb0bf6ab96262c227d5: bug 1318143 - add support for detecting Visual Studio 2017 to configure. r=gps draft
Ted Mielczarek <ted@mielczarek.org> - Wed, 26 Apr 2017 15:18:48 -0400 - rev 569661
Push 56244 by bmo:ted@mielczarek.org at Thu, 27 Apr 2017 19:20:04 +0000
bug 1318143 - add support for detecting Visual Studio 2017 to configure. r=gps This patch adds a copy of vswhere.exe to build/win32, downloaded from the current latest release (1.0.62): https://github.com/Microsoft/vswhere/releases/download/1.0.62/vswhere.exe It changes toolchain.configure to invoke vswhere.exe instead of reading the registry, since that no longer works for VS2017 (but vswhere can locate VS2015). It also removes a layer of complexity in that code by dropping support for non-64-bit host systems, since we don't really support building on 32-bit Windows anymore anyway. There's a little bit of fixup in windows.configure where some LIB paths have changed in 2017. MozReview-Commit-ID: 5XLWjidS6W4
ef367f4e261274f4cecd8ec7c487e5e22cdbe4b8: Bug 1331915 Add Telemetry probe to Graphite library usage draft
Tom Ritter <tom@mozilla.com> - Thu, 27 Apr 2017 14:14:07 -0500 - rev 569660
Push 56243 by bmo:tom@mozilla.com at Thu, 27 Apr 2017 19:14:37 +0000
Bug 1331915 Add Telemetry probe to Graphite library usage MozReview-Commit-ID: 1aU5ddQoLnV
c50793a0a9199680688fb2c9871f576a93b9a4ae: Bug 1336763 - Wait for the browser to say it can go back before going back in browser_grouped_shistory_dead_navigate.js test. r?mystor draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 15:07:55 -0400 - rev 569659
Push 56242 by mconley@mozilla.com at Thu, 27 Apr 2017 19:13:31 +0000
Bug 1336763 - Wait for the browser to say it can go back before going back in browser_grouped_shistory_dead_navigate.js test. r?mystor This test was accidentally taking advantage of the fact that closing a tab will result in a nested event loop while waiting for the permitUnload messages to be sent back and forth from the content process. This meant that the message that tells the parent that the browser (which is having its history set) can now go back had a chance to be received by the parent. With the patches in bug 1336763, we're no longer spinning the event loop if the closing tab doesn't have a beforeunload event handler in it, so we need to wait for the browser to report that it can go back before actually sending it back in order to avoid a test failure. MozReview-Commit-ID: Lpl55iErrvf
aa33ddf70a25effd2aadaaafd1d53130921c0e1c: Bug 1336763 - Don't wait for response from content process in browser_closeTab.js UITour test to avoid a timeout. r?MattN draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 15:04:46 -0400 - rev 569658
Push 56242 by mconley@mozilla.com at Thu, 27 Apr 2017 19:13:31 +0000
Bug 1336763 - Don't wait for response from content process in browser_closeTab.js UITour test to avoid a timeout. r?MattN The closeTab API call from UITour tells the parent process to close the current tab, and doing so might end up disconnecting the message manager. This means that the Promise that the ContentTask returns may never resolve. Instead of waiting for it to resolve, we just wait for the TabClose event in the parent process. MozReview-Commit-ID: Ci7ck9j4llK
619ba8b2b9becde047570a94728b9517a4c69a20: Bug 1336763 - Update browser_beforeunload_between_chrome_content.js to use ContentTask. r?jessica draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 12:46:59 -0400 - rev 569657
Push 56242 by mconley@mozilla.com at Thu, 27 Apr 2017 19:13:31 +0000
Bug 1336763 - Update browser_beforeunload_between_chrome_content.js to use ContentTask. r?jessica By using ContentTask, we get a Promise that resolves once we've heard confirmation from the content process that the ContentTask function has completed running. This means we can be certain that browser_beforeunload_between_chrome_content.js has had the beforeunload event handlers added before attempting to unload the page. MozReview-Commit-ID: DhoTsOZ4BNk
510b80c7257cf89c92d871b49a48afaff50fed96: Bug 1336763 - If browser.permitUnload times out in CanCloseWindow, make sure to check the rest of the browsers belonging to other processes before returning a result. r?dao draft
Mike Conley <mconley@mozilla.com> - Wed, 19 Apr 2017 14:29:42 -0400 - rev 569656
Push 56242 by mconley@mozilla.com at Thu, 27 Apr 2017 19:13:31 +0000
Bug 1336763 - If browser.permitUnload times out in CanCloseWindow, make sure to check the rest of the browsers belonging to other processes before returning a result. r?dao MozReview-Commit-ID: D59PVfsbDV0
801db5cd7176775dbc5861cc81e5a8ae44c03afd: Bug 1336763 - Wait for the browser to say it can go back before going back in browser_grouped_shistory_dead_navigate.js test. r?mystor draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 15:07:55 -0400 - rev 569655
Push 56241 by mconley@mozilla.com at Thu, 27 Apr 2017 19:09:21 +0000
Bug 1336763 - Wait for the browser to say it can go back before going back in browser_grouped_shistory_dead_navigate.js test. r?mystor This test was accidentally taking advantage of the fact that closing a tab will result in a nested event loop while waiting for the permitUnload messages to be sent back and forth from the content process. This meant that the message that tells the parent that the browser (which is having its history set) can now go back had a chance to be received by the parent. With the patches in bug 1336763, we're no longer spinning the event loop if the closing tab doesn't have a beforeunload event handler in it, so we need to wait for the browser to report that it can go back before actually sending it back in order to avoid a test failure. MozReview-Commit-ID: Lpl55iErrvf
6ea38e946c2f0a1a04398a45f76d083e9a68ce53: Bug 1336763 - Don't wait for response from content process in browser_closeTab.js UITour test to avoid a timeout. r?MattN draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 15:04:46 -0400 - rev 569654
Push 56241 by mconley@mozilla.com at Thu, 27 Apr 2017 19:09:21 +0000
Bug 1336763 - Don't wait for response from content process in browser_closeTab.js UITour test to avoid a timeout. r?MattN The closeTab API call from UITour tells the parent process to close the current tab, and doing so might end up disconnecting the message manager. This means that the Promise that the ContentTask returns may never resolve. Instead of waiting for it to resolve, we just wait for the TabClose event in the parent process. MozReview-Commit-ID: Ci7ck9j4llK
a42766bd22f7d020cf10a228e5713311eb62424a: Bug 1336763 - Update browser_beforeunload_between_chrome_content.js to use ContentTask. r?jessica draft
Mike Conley <mconley@mozilla.com> - Thu, 27 Apr 2017 12:46:59 -0400 - rev 569653
Push 56241 by mconley@mozilla.com at Thu, 27 Apr 2017 19:09:21 +0000
Bug 1336763 - Update browser_beforeunload_between_chrome_content.js to use ContentTask. r?jessica By using ContentTask, we get a Promise that resolves once we've heard confirmation from the content process that the ContentTask function has completed running. This means we can be certain that browser_beforeunload_between_chrome_content.js has had the beforeunload event handlers added before attempting to unload the page. MozReview-Commit-ID: DhoTsOZ4BNk
fe56e6bc55518e37e15dfea331668cf32ee3d5a3: Bug 1336763 - If browser.permitUnload times out in CanCloseWindow, make sure to check the rest of the browsers belonging to other processes before returning a result. r?dao draft
Mike Conley <mconley@mozilla.com> - Wed, 19 Apr 2017 14:29:42 -0400 - rev 569652
Push 56241 by mconley@mozilla.com at Thu, 27 Apr 2017 19:09:21 +0000
Bug 1336763 - If browser.permitUnload times out in CanCloseWindow, make sure to check the rest of the browsers belonging to other processes before returning a result. r?dao MozReview-Commit-ID: D59PVfsbDV0
5d925b0e43c83c04eed80f0c523621a1972ce945: Bug 1336763 - Don't ask content process for permission to unload a window if it never set an onbeforeunload event handler. r?dao draft
Mike Conley <mconley@mozilla.com> - Thu, 13 Apr 2017 19:13:34 -0400 - rev 569651
Push 56241 by mconley@mozilla.com at Thu, 27 Apr 2017 19:09:21 +0000
Bug 1336763 - Don't ask content process for permission to unload a window if it never set an onbeforeunload event handler. r?dao MozReview-Commit-ID: JfNz5SdKRTN
bda272ead572bed1ed6100b4563c9f57dfade144: Bug 1353857 - Include the tab ID when notifying about leaving/entering a web app's scope. r?daleharvey,walkingice draft
Jan Henning <jh+bugzilla@buttercookie.de> - Mon, 17 Apr 2017 16:37:58 +0200 - rev 569650
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +0000
Bug 1353857 - Include the tab ID when notifying about leaving/entering a web app's scope. r?daleharvey,walkingice We only want to process the AppEntered/Left message if it actually concerns our currently displayed tab. MozReview-Commit-ID: EJ8RzRzDNAz
d6f503a85b1ea485d9eea370da27b6b59de571eb: Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 13:43:09 +0200 - rev 569649
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +0000
Bug 1351808 - Part 2 - Exclude non-standard tab types from session store. r?sebastian Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs - don't appear in our normal tabs UI - are opened in separate activities - when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data. Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997). Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk. Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab. To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them. Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work. MozReview-Commit-ID: 1q5Jtv0DKrE
ccc6b46199c0c6d31aae6801927c2a3ae826b359: Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 14:18:23 +0200 - rev 569648
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +0000
Bug 1351808 - Part 1 - Replace some magic numbers in session store. r?sebastian MozReview-Commit-ID: BzqieZVi7h4
ab682c5082e907eabf685cde8430b3ece79555b5: BrowserApp startup tab selection debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 22:59:16 +0200 - rev 569647
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +0000
BrowserApp startup tab selection debug logging MozReview-Commit-ID: 79QnUF1Edg3
c04c3d99f68d1edc339f6b1dd8d1cc69a873fcc1: debug logging draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sat, 08 Apr 2017 19:16:31 +0200 - rev 569646
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +0000
debug logging MozReview-Commit-ID: FoUd4cklLKs
0de317bc41cf2e8c9e310dd82798e128c9472a7f: 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 569645
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +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
eec886a795e5cfc4c526dd77ec8ae9ef6bc0f5b7: 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 569644
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +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
89d681b6d97d36e032c57522b56f1d49a18ed848: 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 569643
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +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
9008f40418255ca88a2faf303bf60d10445f6d5d: 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 569642
Push 56240 by mozilla@buttercookie.de at Thu, 27 Apr 2017 18:44:39 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip