Tab opened with Cmd+Click doesn't load the content

[kittipatv]

Description

On MacOSX, using Cmd+Click to open new tab would open a new tab but the page wouldn't load, even after hitting Cmd+R to refresh on the new tab. Copying the URL and paste on a new tab would work. This only happens on certain pages.

Steps to Reproduce

1. Go to https://techcrunch.com/
2. Cmd+Click on any article
3. Switch to the new tab;

Actual result:

Blank tab

Expected result:
The tab should be loaded

Reproduces how often:
100% on techcrunch.com

Brave Version

about:brave info:

Brave: 0.22.810
V8: 6.7.288.43
rev: 8f30eeb
Muon: 7.0.6
OS Release: 17.5.0
Update Channel: Release
OS Architecture: x64
OS Platform: macOS
Node.js: 7.9.0
Brave Sync: v1.4.2
libchromiumcontent: 67.0.3396.71

[LaurenWags]

Reproduced with version 0.22.727 on macOS on techcrunch.
Note - right click on article and select 'Open Link in New Tab' does work as expected. Cmd+click on other sites (nytimes, etc) does load the article in a new tab.

[cndouglas]

Looks like a duplicate of or related to #14222

[darkdh]

I saw the same thing by

1. pasted https://cs.chromium.org/chromium/src/chrome/browser/permissions/permission_context_base.h?type=cs&q=PermissionContextBase&l=43 into your urlbar
2. cmd+click PermissionContextBase and you will see an empty new tab
3. And no matter how you refresh or slightly modify the url, it is still white unless you navigate to other sites

 
Brave: 0.22.810 
V8: 6.7.288.43 
rev: 8f30eeba0c2d6cccf1920a360b4774f820adbc58 
Muon: 7.0.6 
OS Release: 17.6.0 
Update Channel: Release 
OS Architecture: x64 
OS Platform: macOS 
Node.js: 7.9.0 
Brave Sync: v1.4.2 
libchromiumcontent: 67.0.3396.71

[bridiver]

@LaurenWags which chromium version does 0.22.727 have? Does it repro on pre-c67 single-webview?

[LaurenWags]

@bridiver - here's the info for 0.22.727
Brave | 0.22.727
V8 | 6.6.346.32
rev | 2c94bba
Muon | 6.0.12
OS Release | 16.7.0
Update Channel | Release
OS Architecture | x64
OS Platform | macOS
Node.js | 7.9.0
Brave Sync | v1.4.2
libchromiumcontent | 66.0.3359.170

Issue does not reproduce in 0.22.721:
Brave | 0.22.721
V8 | 6.6.346.32
rev | bfe7cdd
Muon | 6.0.12
OS Release | 16.7.0
Update Channel | Release
OS Architecture | x64
OS Platform | macOS
Node.js | 7.9.0
Brave Sync | v1.4.2
libchromiumcontent | 66.0.3359.170

[petemill]

@LaurenWags are you sure you did not reproduce in 0.22.721. I can reproduce on all recent versions of 0.22 (c67 / c66):

• 0.22.810 with muon c67 7.0.6 - cmd-click: blank & unloaded tab when inactive, blank but loaded tab when active
• 0.22.727 (2c94bba) b-l with muon c66 6.0.12 - same issue
• 0.22.721 (bfe7cdd) b-l with muon c66 6.0.12 - same issue
• b-l source of 0.22.721 (bfe7cdd) with muon c67 - same issue

[LaurenWags]

@petemill - I'm not sure what I did before but I can reproduce it on 0.22.721 now. sorry for the confusion!

[petemill]

After investigation, this is likely a muon issue. Would be good to triage and decide whether this is priority enough for @bridiver to look at before brave-core.

Sites reported affected so far:

• techcrunch.com
• cs.chromium.org

...but perhaps it causes some other reports of permanently-white tabs.

[BrendanEich]

I think we need to fix this in Muon and soon. @bridiver any ideas? Thanks.

[bridiver]

This is very likely not going to be easy to fix. We had several problems like this when working on single-webview and every one of them was extremely painful. Most cmd+click links work just fine so it's something different that is happening on these sites

[bridiver]

is that macos only?

[petemill]

I can reproduce on Windows @bridiver

[bridiver]

so this appears to only happen when a tab with a connected opener is opened in the background. Background tabs without connected openers work fine as do new active tabs

[bridiver]

updated test case - https://mathiasbynens.github.io/rel-noopener/ last link opens in active new tab and is blank so the issue is tabs with openers that open in the same window. Tabs with openers in new windows (https://feedly.com/i/welcome click login) work fine

[petemill]

To summarize a bit of investigation that was done over DM:

None of these hacks work:

• delaying attach (by a few seconds even)
• not detaching the parent tab
• hiding and showing via css (or inspector anymore for some reason)

This does work, only for the techcrunch.com cmd-click case:

• create a new webview each time we attach to a different tab and hide / show the webview via css immediately after attach
  However, @bridiver provided a new muon build that fixes the techcrunch.com cmd-click tabs not loading in the background. With this build this workaround doesn't work even for that case. It never works for the mathiasbynens.github.io/rel-noopener case (which I have not found any workarounds that work for).

[LaurenWags]

Verified with macOS 10.12.6 using

• 0.23.19 178c3fb
• Muon 7.1.3
• libchromiumcontent 67.0.3396.87

Verified on Windows 10 x64 using

• 0.23.19 - 178c3fb
• Muon - 7.1.3
• libchromiumcontent - 67.0.3396.87

Verified on Ubuntu 17.10 x64

• 0.23.19 178c3fb
• Muon 7.1.3
• libchromiumcontent: 67.0.3396.87