entire Brave UI becomes unresponsive

[kjozwiak]

• Did you search for similar issues before submitting this one?
  Yes

• Describe the issue you encountered:
  Detaching/Attaching tabs right after Brave has been installed might cause the entire UI to become unresponsive. When this happens, Brave is unusable and needs to be closed using either the Task Manager or the Taskbar under Windows. When clicking on "Print" or "Find in page" via the menu, you'll receive console errors which are outlined under the screenshot section of the bug.

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Windows 10 x64 Build: 10.0.15063 (can't check other OS's right now as MBP being repaired)

• Brave Version (revision SHA):

Brave | 0.18.14 - Reproduced
rev | ad92d02
Muon | 4.3.6
libchromiumcontent | 60.0.3112.78

Brave | 0.18.22 - Reproduced
rev | d850e28
Muon | 4.3.9
libchromiumcontent | 60.0.3112.90

• Steps to reproduce: (this needs to be done fairly quickly)
  1. Launch a clean install of Brave (either 0.18.14 or 0.18.22)
  2. Close the about:welcome tab
  3. Load duckduckgo.com within the remaining about:newtab
  4. Open a new tab using the "+" button and load about:preferences
  5. Detach the about:preferences tab into it's own separate window
  6. Quickly attach the about:preferences back into the original window where duckduckgo.com is still opened

You'll notice that the entire UI becomes unresponsive.

• Actual result:
  The entire Brave UI becomes completely unresponsive. Basically bricks the browser.

• Expected result:
  The Brave UI should never become unresponsive.

• Will the steps above reproduce in a fresh profile? If not what other info can be added?
  Yes

• Is this an issue in the currently released version?
  Yes, 100% reproducible using Brave 0.18.14 | rev: ad92d02 (currently live)

• Can this issue be consistently reproduced?
  Yes, 100% reproducible with both 0.18.14 & 0.18.22 using the above STR.

• Screenshot if needed:

Example of the issue occurring:

Error message when attempting to select "Print" or "Find on Page" when the UI is unresponsive:

[LaurenWags]

Could not repro on MacOS.

[LaurenWags]

On Win10 VM, didn't repro exactly. Sometimes this worked without any problems, and twice the tab I re-attached was bricked, but other tabs and the 3 dots menu worked fine.

[kjozwiak]

I managed to reproduce the same issue on two different Win 10 machines that I remote accessed. I'll try getting a VM running on my desktop once I get back. I'll add more info once I've investigated further. Unless one of the developers manages to reproduce this in the meantime via a VM/physical machine.

[LaurenWags]

+1 from community using 0.18.14: https://community.brave.com/t/tab-ui-becomes-completely-unresponsive-when-detaching-and-reattaching-tab/5631

[ghost]

I've seen this issue as well.

Brave | 0.18.14
rev | ad92d02
Muon | 4.3.6
libchromiumcontent | 60.0.3112.78
V8 | 6.0.286.44
Node.js | 7.9.0
Update Channel | dev
OS Platform | Microsoft Windows [7 Ultimate]
OS Release | 6.1.7601
OS Architecture | x64

EDIT:
Updated to Windows 10 and no longer experience this issue.

[bbondy]

@kjozwiak could you attach your app.entry.js? I'd like to inspect the line numbers in the screenshot with the call stack

[ghost]

I have been able to reproduce the bug reliably on win10. When you drag an drop the undocked tab inside of another tab it causes the browser to not function. If you drag it to the right of any open tab it works fine.

[kjozwiak]

@kjozwiak could you attach your app.entry.js? I'd like to inspect the line numbers in the screenshot with the call stack

app.entry.js.zip

[bbondy]

I think this will be fixe din 0.19.x with my index changes, so moving there. I do have a couple of cleanups I'll push that will make it less likely though.

[binhonglee]

Happened to me on both Windows 10 and macOS.

Couldn't repro on MacOS as it just works when I "close it and open it again".

As for Windows 10, it work on my 3rd attempt reopening the browser. Here's a walkthrough on what I found in each attempts.

1. Refreshed, closed.
2. Disabled and reenabled Shields. Still can't see anything (white blank screen like OP) but I did realize that I can highlight the page and click on links if they are positioned so on the page.
3. Moved my mouse around. Select the only tab opened from the tab bar. Shows everything.

Not sure what does this add to the process but I hope it helps.

[LaurenWags]

+1 from community https://community.brave.com/t/browser-tabs-open-up-in-a-new-window-far-too-easily/5850

[LaurenWags]

+1 from community https://community.brave.com/t/detaching-reattaching-a-tab-makes-it-inaccessible/6099

[LaurenWags]

+1 from community:
https://community.brave.com/t/brave-becomes-unresponsive-randomly/6343

[davidgxue]

I can confirm that I am experiencing the exact same issue. Right now I have to avoid detaching tabs to prevent this...
I am using Windows 8.1 Pro Version 6.3 (Build 9600) 64 bit
UI becomes unresponsive

[kevinp2]

The same thing appears on Windows 7 with Brave 0.18.23 Unsure about the root cause.

[kjozwiak]

BTW, I managed to reproduce this a few times on macOS while using Brave v0.18.23 a few days ago so it's definitely an issue macOS and not isolated to Windows.

[kjozwiak]

Once #10749 is fixed, I'll retest this and see if it was fixed. If not, I'll move this back to the 0.19.x (Beta Channel) milestone.

[bbondy]

I narrowed this down more.

Window 1
  Tab 1
  Tab 2

The key thing here is if you close window 1 for a tab that originated in window 1 then it reproduces.

So if you keep window 1 open and tear off tab1 and 2 into a new window, but always return to Window 1, then it will never reproduce.

if you Move the tabs to a Window 2, and Window 1 closes (or even close it yourself without tearing off last tab), then it will always reproduce.

It seems like there's some link to the originating window that isn't updated and when the originating window is closed it causes problems like crashing and dead tab.

[bbondy]

Fixed in muon 4.3.16
brave/muon@3fccef6

Please wait to test this until you have a build with muon 4.3.16

[srirambv]

Verified on 0.18.27 with steps mentioned here #10436 (comment). No issues found.