Actual Result (gifs and screenshots are welcome!):
After reading the PDF document for a while, Brave freezes with the beachball of doom spinning on Mac. This forces me to force quit Brave.
Expected result:
Brave continues working.
Reproduces how often:
It seems like it may depend on how often I view PDFs. It has happened 7 times over the past 2 hours, but usually happens once every few days.
Operating System and Brave Version(See the About Brave page in the main menu):
OS: MacOS Sonoma 14.2.1 (23C71)
Brave: v1.62.156
Additional Information:
This has been happening for several months, since I was using MacOS Ventura.
This sometimes happens when I am not focused on a tab with a PDF. It may be possible that I am viewing PDFs in other open tabs.
This happens even when there’s barely any tabs open.
I’m not sure this is a CPU or memory issue, as all other apps are fine, and Activity Monitor indicates there’s lots of idle CPU (e.g. ~80%) and several GBs left of free memory (e.g. 8-10GB).
This is easily reproducible on my laptop even with a brand new profile with no extensions installed or any other settings modified.
This seems to be independent of the type of PDF being viewed. The types of PDFs I’ve faced this issue on include: papers (e.g. from arXiv), slides (e.g. converted from PowerPoint or Google Slides), instruction manuals for furniture and electrical appliances.
Thank you for the report; my apologies for the poor experience. I have shared this report (and crash ID) with our team for further immediate consideration. Please do let us know if you run into any other related issues, or have more to share on this issue. I hope to have either a fix in place, for further information to share, soon.
Their current suggested workaround is to launch Chromium browsers with --disable-renderer-accessibility. They have more technical details in a Google Doc (including more permanent fixes they’re considering in future versions), but they’ve taken the link down from the thread, so I’m not sure I should share it here publicly, but I could potentially share it privately?
What I can do now:
Reproduce the crash a few more times and share the crash IDs
Check if disabling accessibility at every launch stops the issue
Regarding item 1: Reproduce the crash a few more times and share the crash IDs
I’ve been able to consistently reproduce the crash. Clicking on the PDF in the Brave browser, then switching between another app and the Brave browser several times causes the crash within a few seconds. However, while I have been able to consistently reproduce the crash, I have struggled to generate crash reports. Therefore, I only have a few more crash report IDs (one of them is likely generated from a profile that has several extensions, but that shouldn’t be relevant):
2a111000-dba3-700b-0000-000000000000
91101000-dba3-700b-0000-000000000000
690e1000-dba3-700b-0000-000000000000
Regarding item 2: Check if disabling accessibility at every launch stops the issue
I ran Brave with open -a "Brave Browser.app" --args --disable-renderer-accessibility and have been unable to reproduce the issue. It may be the same issue that Chromium browsers are facing (mentioned above).
Tremendous work, @tattling5325. It does indeed sound like the issue is deeper, within Chromium. I’ve shared these details with our team for further consideration. I hope to see this resolved soon, such that you no longer need to run with --disable-renderer-accessibility.
Additionally, for anyone who may be facing this issue and chance upon this thread, this is what I’ve done to make the workaround less inconvenient. In the “Shortcuts” app, I created a new shortcut to run the command open -a "Brave Browser.app" --args --disable-renderer-accessibility (shown below).
As such, I can now open “Run Brave.app” rather than run the full command to open Brave with accessibility switched off. The shortcut can also be pinned to the dock at the bottom of the screen, so you can just click to open Brave with accessibility switched off.
