Tab is destroyed if switched during first attach

[petemill]

First attach of a tab seems to cause the WebContents to attach, then detach, then attach again very quickly. If the active tab is switched during the 'detach' phase, then the WebContents will not be properly detached and will be destroyed when the new Tab is attached. This is because the WebContents does not report as attached, even though it is about to automatically attach again.

@bridiver do you know if muon is to blame for the attach -> detach -> attach initial repeat, or somewhere deep in Chromium? It complicates things when there is no trustworthy event or property for whether it is attached or detached, or even attaching or detaching, since when we receive did-attach, we have no way of knowing if the WebContents will emit did-detach and did-attach very quickly again ...and we do not want to attach another guest to the view if the WebContents is reporting it is not attached but is actually about to attach again (automatically).

I encountered this by pinning a tab, and then opening a new window (which at the moment causes active tab to switch very quickly from the new non-pinned tab to the new pinned tab). It usually repeats once within 10 new windows, as it's a timing issue.

[petemill]

This could be worked around by instead of working out whether we need to detach and attach to another WebContents after did-attach, we wait for render-view-ready. Unfortunately, whilst this works well for subsequent attaches for a Tab, the first attach only fires render-view-ready if we "bump" the webview by hiding and showing it. This in itself would be good to fix inside muon before launch because of the apparent flimsiness of our display workarounds.

Here's what's going on when a tab is setActive, and has it's guestInstanceId passed to a webview's .attachGuest for the first time:

tabs.setActive: 84
Tab [84] event 'set-active'
tab [84 via process] chrome-tabs-updated { active: true, highlighted: true, selected: true }
Tab [84] event 'will-attach'
Tab [84] event 'did-attach'
tab [84 via process] chrome-tabs-updated { height: 972, width: 1451 }
Tab [84] event 'preferred-size-changed'
Tab [84] event 'ipc-message-host'
Tab [84] event 'preferred-size-changed'
Tab [84] event 'did-detach'
Tab [84] event 'will-attach'
Tab [84] event 'did-attach'
Tab [84] event 'render-view-ready'
Tab [84] event 'guest-ready'

[petemill]

The attach -> detach -> attach is actually caused by our code hiding and showing the <webview> for the webview's first attach in order to force it to paint.

[petemill]

Should be fixed in 0.22.109

[petemill]

This is definitely fixed, since I removed the code that was hiding and showing the webview after C66 (as it was no longer required in order to force the tab to display without just being blank) - since the code is removed, it won't cause the issue. But the STR was to ctrl-tab through tabs very quickly at startup (with a profile that has a few tabs in it), and some of them would be removed.