Tab's first attach is not composited

[petemill]

Description

If we call <webview>.attachGuest(guestInstanceId) for a Tab that has never been attached / displayed before, then 50% of the time it won't be composited within the <webview>, even though did-attach will be received. If we detach and attach again, then it will be displayed correctly.

What would be great is either:

• IF this is a timing issue, know which event has to be received by the tab, before we should call <webview>.attachGuest with that Tab's guestInstanceId, in order to be 100% confidence that the attach will result in composition of the contents with the webview.
• Or, make sure that attachGuest will always result in composition of the contents with the webview, even if the contents has never been loaded yet.
• Or (least preferrably...) know which event, when emitted after did-attach is emitted, means that we should detach and attach again. This is least preferrable due to other timing issues that may occur in-between those stages, possibly greatly complicating the code (e.g. tab is moved to different window).

Steps to Reproduce (1)

1. Start with fresh profile
2. CmdOrCtrl-click all sites on New Tab page
3. Wait for all sites to finish load
4. ctrl-tab to each site 1-by-1
5. Observe some sites do not render when switched to, but the previous Tab for that <webview> is shown.
   Note: the site may display after ~15 seconds

Steps to Reproduce (2)

1. Start with profile from STR(1)
2. ctrl-tab to each site 1-by-1
3. Observe some sites do not render when switched to, but the previous Tab for that <webview> is shown and can be interacted with.

Reproducible on current live release:
No

[petemill]

Updated with 100%-replicable STR and to reflect this is an issue with both macOS and Windows on muon 6.0.4.

I think this is a timing issue as if you create a new active tab, switching to it straight away, it composites 100% of the time when switched to, but if you switch to a

Here's what I can tell:

• The first WebContents a <webview> has attachGuest called with, will always comosite fine ✅.
• The second WebContents attachGuest is called on (which has not been attached to before) will not be composited ❌
  • Any subsequent WebContents will not be composited ❌, until:
• The second WebContents attachGuest is called again after a detachGuest will composite ✅
  • Any subsequent WebContents will be composited ✅

I'm going to check the muon attachGuest and detachGuest code again @bridiver

[petemill]

Should be fixed via muon 6.0.5

[GeetaSarvadnya]

Verified on Windows x64

• 0.22.702 e4a853d* libchromiumcontent 66.0.3359.139
• muon: 6.0.7

Verified with macOS 10.12.6 using

• 0.22.702 e4a853d
• muon 6.0.7
• libchromiumcontent 66.0.3359.139

Verified on Ubuntu 17.10 x64
0.22.703 903b8d0
libchromiumcontent 66.0.3359.139
muon: 6.0.8