Crash about dom storage context while browsing Twitter in private tabs with Tor

[riastradh-brave]

Description

When in a private tab with Tor enabled, clicking on a link summary embedded in a tweet in an expanded Twitter thread in a new tab causes the browser to crash.

Steps to Reproduce

1. Enable Tor for private tabs.
2. In a private tab, open a Twitter feed, e.g. https://twitter.com/nytimes.
3. Control-click on a tweet with an embedded link summary to expand the thread in a new tab.
4. Switch to the new tab.
5. Click on the link summary.

Please also see the following for other reproducible cases:

• Crash about dom storage context while browsing Twitter in private tabs with Tor #14392 (comment)
• Crash about dom storage context while browsing Twitter in private tabs with Tor #14392 (comment)

Actual result:
The browser crashes with the following stack trace.

[18120:18120:0612/164743.717397:FATAL:web_contents_impl.cc(2294)] Check failed: session_storage_namespace_impl->IsFromContext(dom_storage_context). 
#0 0x00000314badc base::debug::StackTrace::StackTrace()
#1 0x000003163743 logging::LogMessage::~LogMessage()
#2 0x000002c0d9cd content::WebContentsImpl::CreateNewWindow()
#3 0x0000029ce794 content::RenderFrameHostImpl::CreateNewWindow()
#4 0x0000022cfdec content::mojom::FrameHostStubDispatch::AcceptWithResponder()
#5 0x0000029d8456 content::mojom::FrameHostStub<>::AcceptWithResponder()
#6 0x000003757f88 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#7 0x00000374f354 IPC::(anonymous namespace)::ChannelAssociatedGroupController::AcceptSyncMessage()
#8 0x00000314ce6d base::debug::TaskAnnotator::RunTask()
#9 0x000003166c77 base::MessageLoop::RunTask()
#10 0x000003167147 base::MessageLoop::DoWork()
#11 0x0000031696af base::(anonymous namespace)::WorkSourceDispatch()
#12 0x7fba4115ffb7 g_main_context_dispatch
#13 0x7fba411601f0 <unknown>
#14 0x7fba4116027c g_main_context_iteration
#15 0x000003169572 base::MessagePumpGlib::Run()
#16 0x000003185c35 base::RunLoop::Run()
#17 0x0000028ba581 content::BrowserMainLoop::MainMessageLoopRun()
#18 0x0000028ba383 content::BrowserMainLoop::RunMainMessageLoopParts()
#19 0x0000028bd112 content::BrowserMainRunnerImpl::Run()
#20 0x0000028b662c content::BrowserMain()
#21 0x0000027fadc8 content::ContentMainRunnerImpl::Run()
#22 0x00000448d815 service_manager::Main()
#23 0x0000026b58e4 content::ContentMain()
#24 0x0000017a53c0 main
#25 0x7fba3bd461c1 __libc_start_main
#26 0x0000017a502a _start

Expected result:
The browser follows the link and opens it.

Reproduces how often:
100%

Brave Version

about:brave info:

Brave	0.23.8
V8	6.6.346.32
rev	06c657b
Muon	6.0.11
OS Release	4.13.0-41-generic
Update Channel
OS Architecture	x64
OS Platform	Linux
Node.js	7.9.0
Brave Sync	v1.4.2
libchromiumcontent	66.0.3359.170

Reproducible on current live release:
no

Additional Information

This does not happen in non-private tabs. This does not happen in private tabs with Tor disabled.

I will neither confirm nor deny whether I discovered this while at work.

[riastradh-brave]

[riastradh-brave]

Fixed in brave/muon@96c2eb7.

[riastradh-brave]

Either something re-broke this or the earlier change I cited as a fix only incidentally papered over the problem. It is back in 0.23.19 and in master.

[kjozwiak]

@bsclifton should we add this into a milestone? Maybe release 4? Crashing is never a good thing, especially with a new feature like Tor.. Thoughts?

[jumde]

@riastradh-brave @kjozwiak can't repro on 0.23.31

[bsclifton]

@kjozwiak sounds good- pulled into release 4

[riastradh-brave]

Still reproduces for me on 0.23.31.

[darkdh]

https://jsfiddle.net/dqokhmsg/
crash because of rel="noopener"

2357   scoped_refptr<SiteInstance> site_instance =
2358       // params.opener_suppressed && !is_guest
2359          params.opener_suppressed
2360           ? SiteInstance::CreateForURL(GetBrowserContext(), params.target_url)
2361           : source_site_instance;

so BraveContentBrowserClient::GetStoragePartitionConfigForSite for tor will get different partition_domain and partition_name

[kjozwiak]

Another case @jasonrsadler mentioned in slack that @riastradh-brave confirmed was the same issues:

STR:

• launch 0.23.31 3148ace
• open Tor PT and load https://community.plus.net/t5/Tech-Help-Software-Hardware-etc/Which-computer-am-I-using/td-p/1061141
• click on http://www.whatsmyip.org/more-info-about-you/ in the second reply in the thread

[darkdh]

Test Plan:

1. Open tor tab
2. Visit site contains rel="noopener" href (https://jsfiddle.net/dqokhmsg/)
3. Click the link
4. Brave shouldn't crash

[srirambv]

Verified on Windows 10 x64 using

• 0.23.70 e63c780
• Muon 8.0.1
• libchromiumcontent 68.0.3440.68

Verified on Ubuntu 17.10 x64

• 0.23.70 e63c780
• Muon 8.0.1
• libchromiumcontent 68.0.3440.68
• verified browser doesn't crash on all 3 scenarios mentioned in the original issue

Verified with macOS 10.12.6 using

• 0.23.72 c3b1cac
• Muon 8.0.2
• libchromiumcontent 68.0.3440.75
• verified browser doesn't crash on all 3 scenarios mentioned in the original issue

[LaurenWags]

Using 0.23.70 with muon 8.0.1 and STR from description still produces a crash on macOS for me. However, the steps from #14392 (comment) and #14392 (comment) do not crash. Requested @kjozwiak to give it a try on macOS as well. @srirambv could not reproduce the crash on Win.

[btlechowski]

The original STR still lead to crash, but I believe this is a different crash(#14806).

Tested 0.23.70 on Ubuntu 17.10

[srirambv]

Need to verify this(original steps) again once #14806 is fixed.

[kjozwiak]

Cleared QA/checked-Linux & QA/checked-Win64 so they can be rechecked as per #14392 (comment) now that #14806 has been fixed and verified.

[GeetaSarvadnya]

Verified on Windows x64 with
• 0.23.73 50bdb6d
• Muon 8.0.3
• libchromiumcontent 68.0.3440.75

Verified on Ubuntu 17.10 x64

• 0.23.73 50bdb6d
• Muon 8.0.3
• libchromiumcontent 68.0.3440.75