-
Notifications
You must be signed in to change notification settings - Fork 975
Conversation
1685f5d
to
ab7b6a5
Compare
Codecov Report
@@ Coverage Diff @@
## master #13120 +/- ##
=========================================
- Coverage 56.14% 55.95% -0.2%
=========================================
Files 282 282
Lines 28074 28190 +116
Branches 4615 4639 +24
=========================================
+ Hits 15763 15774 +11
- Misses 12311 12416 +105
|
#13118 was merged, so removing PR blocked label |
ab7b6a5
to
26ba05c
Compare
26ba05c
to
2d576e5
Compare
c817fb0
to
4f80c90
Compare
74e4033
to
4cf22f8
Compare
This is ready for review but not merge until brave/muon#504 is merged, released and referenced in whichever branch this PR should end up in (currently 0.21.x). |
appActions.tabReplaced(tabId, getTabValue(newTabId), getTabValue(tabId).get('windowId'), !isPlaceholder) | ||
if (!isPlaceholder) { | ||
// update in-memory caches | ||
webContentsCache.tabIdChanged(tabId, newTabId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could introduce a race condition because the webContentsCache and activeTabHistory will be temporarily out-of-sync with the app state. Can we make them reducers instead that update on the tabReplaced action?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
activeTabHistory
and webContentsCache[].openerTabId
(openerTabId is the only prop changed here) are only called in response to tab events coming from muon, not app state actions. Is that enough to satisfy your concern @bridiver? My thinking was to change them immediately to actually avoid a race condition, in case we're getting the tab 'detached' / 'destroyed' event quicker than the store can update those values - and we need the values updated then so that the next active TabId can be correctly chosen. Or is your concern that the tabReplaced
action may rely on that data?
Either way, I should test that detaching a tab correctly sets the appropriate parent tab on detach, because there may be an issue with the 'temporary' contents id, in which case even if isPlaceholder === true
we should call webContentsCache.tabIdChanged
and activeTabHistory.tabIdChanged
since that is window-specific and the info is needed on tab.on('will-destroy')
which is fired very soon after tab-id-changed
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ detaching is fine, and we shouldn't change the activehistory / openerTabId tabId for placeholder replacements since tabs.moveTo
directly calls tabs.getNextActiveTabId
passing in the moved tabId (and not the temporary replacement tabId) - so detaching and setting the appropriate next tab active in the departing window, depending on preference, works nicely.
4cf22f8
to
f77e33f
Compare
I added some more test cases |
Looks like the 'Parent Tab 2' discard test isn't working, I'm looking in to it |
Requires brave/muon#504 Ensure that tab/WebContents objects are added to memory as soon as they are created. Use muon's new `tab-replaced-at` event (instead of <webview>.tab-id-changed) to ensure state gets updated correctly when a tab is discarded, as well as communicating temporary contents replacement to a window's frame (such as when detaching a tab to a new window, the tab in the old window gets a temporary WebContents that then gets destroyed). In the case of tabs which get discarded, they are replaced with a fresh, clean WebContents. We were not receiving this new object, so when the renderer asked for this new object's tabId to be made active, the cache did not have that object. We must also handle updating references to the old TabId to the new TabId in state, in the module which remembers opener tab IDs and the module which handles historical tab 'active' history for a window. The guestInstanceId for a tab also changes when a discarded tab is reloaded, so make sure we pass that new value in the frame options when a discarded tab is detached to a new window. Adds more relevant log entries under the `--debug-tab-events` flag.
f77e33f
to
c784d2b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ran through entire test plan - everything working great 😄 Love the extra debugging info too
Thanks for the approval @bsclifton. Looking forward to getting it merged and out on beta release to test auto-discarding in the wild. |
Fix tab auto-discarding ability
Fix tab auto-discarding ability
Fix #13210 (13120 / 13210 - what are the chances...)
Fix #1796
Depends on #13118 (new Debug menu for manually discarding a tab)Depends on new muon version with brave/muon#504Blocking issues
As described in #13210:
Implement chrome.tabs.onReplaced.addEventListener muon#487Tab is destroyed when detached if it has previously been discarded muon#496What this fixes
Ensure that tab/WebContents objects are added to memory as soon as they are created.
Use muon's new
tab-replaced-at
event (instead of .tab-id-changed) to ensure state gets updated correctly when a tab is discarded, as well as communicating temporary contents replacement to a window's frame (such as when detaching a tab to a new window, the tab in the old window gets a temporary WebContents that then gets destroyed).In the case of tabs which get discarded, they are replaced with a fresh, clean WebContents. We were not receiving this new object, so when the renderer asked for this new object's tabId to be made active, the cache did not have that object.
We must also handle updating references to the old TabId to the new TabId in state, in the module which remembers opener tab IDs and the module which handles historical tab 'active' history for a window.
The guestInstanceId for a tab also changes when a discarded tab is reloaded, so make sure we pass that new value in the frame options when a discarded tab is detached to a new window.
Adds more relevant log entries under the
--debug-tab-events
flag.Testing
Verification steps specified on #13210
And in addition, some modified tests from #12193, since now a tab ID can change, and we must update history for which tabs were active with the new tab ID.
Here those modified tests are:
NOTE: on Windows, you should disable tab preview
Closing
Parent tab
Parent tab 2
Next tab
Last active tab
Detaching
Parent tab
Next tab
Last active tab
For reference:
app.on('web-contents-created')
to be fired.process.on('add-new-contents')
event for the tab's new contents / tabId. So we rely on muon's newtab-replaced-at
event which fires on the original tab.