Tab content should be discarded when memory usage is too high

[petemill]

Description

Muon / Chromium has a feature whereby a tab's contents will be disposed and the memory freed when under memory pressure.

This was previously enabled, but disabled in #12916 due to #10673.

However, performance is hindered by not having tabs discarded, so we should do two things:

1. Fix tab discarding
   a. The ability to switch to and away from discarded tabs
   b. The ability to detach previously-discarded tabs
2. Re-enable automatic discarding

This issue tracks both the re-enabling of the feature and the fixing of the underlying issues which led to the feature being disabled.

Prerequisites

• TabState is not updated for the new discarded WebContents. This happens in add-new-contents event which isn't received for discarded replacement WebContents. Therefore if the window has 2 tabs, one being discarded, the state reports 1 tab and the detach will not be allowed.
  Status: Issue Implement chrome.tabs.onReplaced.addEventListener muon#487. Muon tab event tab-replaced-at implemented in Fix/tabs discard dead tab muon#504

• When a discarded tab is detached, it seems to be destroyed immediately, and the 'did-detach' event never fires. Therefore the handler which adds the frame to the new window never fires. Even if the handler is forced to run, the tab in the new window is dead, since it has been destroyed.
  Status: Issue Tab is destroyed when detached if it has previously been discarded muon#496. Fix in Fix/tabs discard dead tab muon#504

• When a discarded tab is detached, attached to a new window, and loaded, it does not remember its scroll position. The new webview has a src element (unlike when detaching and attaching non-discarded tabs) even though browser-laptop is not setting it, but does use the existing tabId.

• New muon version with above changes integrated with browser-laptop

Steps to Reproduce

The problems with tab discarding can be viewed with the new Debug menu option 'Allow manual tab discarding'
Please turn off the preference for tab previews whilst testing!

Tab discarding works

1. Open some tabs with websites (not about:... pages)
2. Visit each tab to ensure it is loaded
3. Right-click an inactive tab and choose 'Discard'
4. Switch to the discarded tab

Actual result:

Cannot switch to tab

Expected result:

Tab is made active and tab's contents are loaded again

Tab detaching works

1. Open some tabs with websites (not about:... pages)
2. Visit each tab to ensure it is loaded
3. Right-click an inactive tab and choose 'Discard'
4. Right-click the same tab and choose detach (be careful not to hover over tab and cause a tab-preview as this will load the tab contents)

Actual result:

Tab either disappears or attaches to a new window but is blank and not loadable / useable.

Expected result:

Tab detaches to a new window with its contents intact.

Tab detaching after reloading after discarding works 😮

1. Open some tabs with websites (not about:... pages)
2. Visit each tab to ensure it is loaded
3. Right-click an inactive tab and choose 'Discard'
4. Switch to the discarded tab to load its contents
5. Switch away from the discarded tab
6. Right-click the same tab and choose detach

Actual result:

Tab either disappears or attaches to a new window but is blank and not loadable / useable.

Expected result:

Tab detaches to a new window with its contents intact.

More test conditions not neccessarily connected to this issue, but there because of some changed code, are specified in the PR #13120

Brave Version

about:brave info:
0.21.x source

Reproducible on current live release:
No, since automatic discarding is disabled

[LaurenWags]

Verified on macOS 10.12.6 x64 using the following build:

• 0.22.7 8bb7e77
• libchromiumcontent: 65.0.3325.181
• muon: 5.1.1

Verified on Windows 7 x64

• 0.22.7 8bb7e77
• libchromiumcontent: 65.0.3325.181
• muon: 5.1.1

Verified on Mint 18.3 x64 using the following build:

• 0.22.11 56de947
• libchromiumcontent: 65.0.3325.181
• muon: 5.1.2