When using macOS’s Spoken Content feature, windows in Brave are covered in a translucent green overlay. The feature works by highlighting text and using a keyboard shortcut to start or stop computerized speech. So long as the computer is speaking, windows in Brave will flash with random intervals, from split-seconds to full ones. While reading long passages it will tend to get stuck on the green overlay until speech stops.
The problem persists when text is no longer being highlighted or when switching to a different tab, so long as the computer is speaking (during which it highlights individual words as they are spoken). Sometimes it is able to read with no issues, but because it only starts or stops while speaking I beleive it is definitely related. I have not had this issue in Chrome or various other apps.
I experimented with combinations of the settings below while troubleshooting to no avail:
Turning the “”use graphics acceleration if available option off in System
Changing brave COlors in Appearance between all options (same as OS, Dark, Light)
Turning off all extensions and/or opening incognito window
How can this issue be reproduced?
Enable Spoken Content from Mac System Settings > Accessibility > Spoken Content. This is not related to VoiceOver.
Open page in Brave browser and highlight text.
Use Mac Spokeon Content (default shortcut is option+escape)
Expected result:
Image is from an irrelevant search page that should have a black background with white text. Flashing or hanging on the overlay will become more apparent if longer sentences or passages are being read.
I am colorblind so my mistake if it isn’t actually green. I hope that there is or will be a fix, because otherwise I simply can’t use this browser. Thanks.
@CHastings interesting issue. First, I’d go ahead and update the browser to v1.76.81 just to ensure that updating doesn’t fix the issue on it’s own.
I just tested on my end and cannot reproduce, but I am using Sequoia 15.3.2 which may not have the issue. Can you tell me whether or not you see this same behavior if you were to use another browser (ideally a Chromium based browser)?
Hello, I am already on Brave v1.76.81. I been using Chrome until now, and just tried out Vivaldi. I haven’t seen the issue in both these other browsers with the following versions:
Whereas the behavior consistently appears in Brave, and I first noticed it within a few seconds of using the browser. Updating macOS would be a last resort for me, but if push comes to shove I may try. Still, if other solutions are possible I’d be much obliged. Thanks for your time.
Unfortunately, the same issue pops up in the Brave Beta.
I firmly think that updating the OS is more trouble than it’s worth, with things breaking or resetting and creating a lot of hassle. I’ve also found various appsand accessibility features to go backwards in usability before. Interfaces and behaviors changing are particularly troublesome for me as someone with strong visual impairment, so I prefer to stick to what i’m used to unless there’s no other way.
Thank you for checking. I’ve reached out to our macOS team about this as I am not sure what else can be suggested here other than updating your OS but I want to exhaust all other options before we confirm that this is necessary.
What’s weird is that if it were the OS, I would expect the issue to show in Chrome as well. Will reply back here when I hear back from the team.
I greatly appreciate your help, and I can now confirm that updating macOS didn’t solve the issue. I just jumped to Sequoia 15.3.2 and the same problem persists.
Hello, another update. I seem to have solved the issue.
Go to macos Accessibility settings
Go to Spoken Content and click the button next to the toggle for Speak Selection for specific settings
Change Highlight Content from Words to None
I’m not sure if this option was around on Ventura, but either way changing it as above solved the problem.
In other words, the flashing is somehow related to the computer highlighting text during speech (a seprate kind of highlighting from simply selecting text). I think proper etiquette will have me mark this as solved now, but there’s still some kind of underlying issue that I hope the developers can locate.