Tabs become locked (can't switch tabs)

[Colbix]

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

• Describe the issue you encountered:
  Leaving more than 1 tab open for a variable length of time will prevent other tabs from closing or being selected. Tabs were not split and rejoined. Also tabs were not ghosted as the audio from the tabs continued to produce sound.

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Windows 10

• Brave Version (revision SHA):
  Brave | 0.18.23
  rev | 36ae2ec

• Steps to reproduce:

  1. Open more than 1 tab
  2. Wait for tabs to become unresponsive. The timing is variable but usually not more than 15 minutes.

• Actual result:
  Unable to click on tabs or close tabs. Sometimes clicking to close a tab will exit Brave.

• Expected result:
  User responsiveness to select and close tabs.

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

• Is this an issue in the currently released version?
  Yes.

• Can this issue be consistently reproduced?
  Yes.

• Screenshot if needed:
  http://gph.is/2wQZexy

• Any related issues:

[Colbix]

I've been able to repeat this with my existing Brave install. So another test was to uninstall Brave and delete the AppData Roaming and Local brave folders. After re-installing Brave I've not encountered the issue. I'll report back here if it re-occurs with the new install.

[Colbix]

Since re-installing, after deleting the AppData folders, the problem described is much less frequent however it still exists. The tabs are not detached and re-added but they become unresponsive at random times. Exiting the browser is also a problem when the tab locking occurs, sometimes the browser will exit when the window is closed at other times it requires right clicking the task bar to close.

I'm still exploring a more reliable method of recreating this locking issue.

[cndouglas]

@Colbix Are you using the latest version (0.18.29)? There were several tab-related bugs fixed recently.

[Colbix]

Current version

Brave	0.18.36
rev	7ab85e9

I'm still experiencing the issue, as described in the original comment, however I can not reliably reproduce it due to variance. Reading other reported issues it looks like people continue to experience very similar tab issues. The issue described in 9385 is a good accounting of the problem with the only difference being my use of Windows 10.

I will wait for the next release to see if the additional tab fixes restore the usability of the browser without having to exit and relaunch every 10 to 30 minutes.

[Colbix]

Brave: 0.19.48
rev: de939f6
Muon: 4.4.28
libchromiumcontent: 61.0.3163.100
V8: 6.1.534.41
Node.js: 7.9.0
Update Channel: Release
OS Platform: Microsoft Windows
OS Release: 10.0.15063
OS Architecture: x64

Updated to current version, unfortunately the problem still persists. As another experiment I successfully used the browser with only 1 tab open and never encountered a tab lock or unresponsiveness. However the tabs are managed the problem occurs when more than 1 tab is opened for a variable amount of time.

[cndouglas]

Could you please check ...\AppData\Local\Temp\Brave\Brave Developers Crashes and see if there are any crash logs?

[Colbix]

Yes, several crash logs and an operations log. Here is the most recent crash log:
_companyName:Brave.com
_productName:Brave Developers
_version:0.18.36
platform:win32
process_type:browser
prod:Electron
ptime:4596035
rept:Brave-crash-service
rev:7ab85e97318fef041433b0c3d73b457205fae805
ver:4.3.22

[bsclifton]

cc: @bbondy

[Colbix]

Brave: 0.19.53
rev: e09025b
Muon: 4.4.29
libchromiumcontent: 61.0.3163.100
V8: 6.1.534.41
Node.js: 7.9.0
Update Channel: Release
OS Platform: Microsoft Windows
OS Release: 10.0.15063
OS Architecture: x64

Updated to the recent version again. A Minor change is that while some tabs will remain locked, in this case it's unresponsive with sound still occurring, I can open new tabs and continue using the browser.

[Colbix]

Brave: 0.19.70
rev: d4b94c6
Muon: 4.5.9
libchromiumcontent: 62.0.3202.62
V8: 6.2.414.32
Node.js: 7.9.0
Update Channel: Release
OS Platform: Microsoft Windows
OS Release: 10.0.15063
OS Architecture: x64

Same issue as described, hoping the next update will be the fix.

[Colbix]

Brave: 0.19.80
rev: 7d07299
Muon: 4.5.13
libchromiumcontent: 62.0.3202.75
V8: 6.2.414.36
Node.js: 7.9.0
Update Channel: Release
OS Platform: Microsoft Windows
OS Release: 10.0.15063
OS Architecture: x64

Same issue as described, hoping the next update will be the fix.

[Colbix]

Another encounter with the problem is described in issue #11750 . Although I observe that issue is tagged as a bug and priority/p2.

[Slava]

Happens to me routinely, usually with the first tab, often after my computer goes to sleep. Windows 10.

0.19.105 rev | 51f8ba5

[jonathansampson]

I believe this is related (or identical) to #9242 and #9865.

[jonathansampson]

Possible +1 from Twitter: https://twitter.com/CryptoMktWizard/status/944218235087462402:

"...I just can't click on certain tabs, or toggle to them. I run a lot of tabs, right now―roughly 32, for what it's worth."

[jonathansampson]

Another +1 from Twitter:

"@brave - Fix your fg browser. Why would you launch a browser where thousands of people tell you daily THE TABS ARE STUCK AND YOU CANNOT CLOSE / MOVE BTW. THEM!! FFS. Browser 101 common sense, months of this garbage. Brutal."

https://twitter.com/BarryDutton/status/951658476480102401

[bsclifton]

Assigning @petemill to investigate 😄

[bsclifton]

+1 from @bbondy:

I'm getting into a state sometimes that the browser can't change off of my current tab. I have youtube playing in a background tab, and it continues playing. Tab preview shows the tab playing.

Browser console shows:

index.html:1 Unchecked runtime.lastError while running guestViewInternal.destroyGuest:  Unknown error.
index.html:1 Unchecked runtime.lastError while running guestViewInternal.setSize: Unknown error.
7index.html:1 Unchecked runtime.lastError while running guestViewInternal.destroyGuest: Unknown error.

Could this possibly be created by detaching / re-attaching tabs?

[petemill]

Would be helpful to see when muon has 'discarded' a tab, to see if it's related to this 'dead tabs' issue - I've created an issue to expose such an event brave/muon#443

[petemill]

Some progress... When a tab is discarded we are seeing that the tab is detached, then a new tab (with a different Id) is created and attached. The problems are:

• That the old tab is not destroyed so it is not removed from the webContentsCache or the browser tabState.
• That the new tab is created via the web-contents-created event, but we do not receive the process.on('add-new-contents') event, which is the only place we setup webContentsCache and browser tabState for tabs.
• Meanwhile the frame receives the tab-id-changed event, and so it starts to ask for actions (like setActive) against the new tabId, which does not exist in webContentsCache and browser tabState.

I'm hesitant to change any code to address the events happening like this, because @bridiver mentions that this is not exactly the events that should be received, and this apparently was working successfully with (likely) the current code. So will wait for more info on that.

I reproduced the issue organically on Windows by opening many tabs on a low-memory VM and browsing for 10 - 20 mins, then observing tabs had been unloaded and could not be switched to. The issue can also be artificially reproduced on Mac by opening many tabs, browsing, and then using the 'Debug' -> 'Send memory pressure alert' menu command.

On Mac only, using the above menu command technique, tabs also received the 'crashed' event, although I did not find any crash dumps for those tabs. I did not get the 'crashed' event for any tabs at all on Windows using the organic method above.

Sample log from macOS:

Tab [121] created in window -1
Tab [77] event 'crashed'
Tab [77] event 'will-detach'
[23282:775:0123/184011.786112:ERROR:CONSOLE(103831)] "tab id changed 77 121", source: http://localhost:8080/gen/app.entry.js (103831)
Tab [77] event 'did-detach'
tab [77 via process] chrome-tabs-updated
tab updated from muon { tabId: 77,
  changeIndex: -1,
  changeActive: undefined,
  newIndex: -1,
  newActive: false }
Tab [121] event 'will-attach'
Tab [121] event 'did-attach'
[23282:775:0123/184011.805484:ERROR:CONSOLE(103831)] "tab id changed 121 121", source: http://localhost:8080/gen/app.entry.js (103831)

Similar log from Windows:

Tab [277] created in window -1
Tab [45] event 'will-detach'
Tab [45] event 'did-detach'
tab [45 via process] chrome-tabs-updated
tab updated from muon { tabId: 45,
  changeIndex: -1,
  changeActive: undefined,
  newIndex: -1,
  newActive: false }
Tab [277] event 'will-attach'
Tab [277] event 'did-attach'

[Colbix]

Brave: 0.20.30
V8: 6.4.388.40
rev: 8b78402
Muon: 4.7.9
OS Release: 10.0.16299
Update Channel: Release
OS Architecture: x64
OS Platform: Microsoft Windows
Node.js: 7.9.0
Brave Sync: v1.4.2
libchromiumcontent: 64.0.3282.119

As of the most recent update the problem appears to have been fixed or at least not as immediate and frequent. I'll update if I encounter any further issues.

[petemill]

Closing this as we are not seeing this specific issue on a released version, as the triggering feature (tab discarding under memory pressure) was disabled in #12916. Re-enabling will be addressed in a separate issue.