Some website is really bright and affected others with white background

The problem started in the brave browser dashboard when scrolling the brave news, at a particular section on the news it brightens as if the contrast meter is set to the maximum and is discernable. However, continue scrolling and it is back to normal.

Another website also cause this issue and affected another website on other tabs.
tested with other browsers does not replicate this issue.

1 Like

I’ve had this same exact issue for the past day or so. I tried reinstalling to no avail. The version I am running is on Windows 10 Version 1.40.105 Chromium: 103.0.5060.53 (Official Build) (64-bit).

It is extremely bright to the point that it’s like a flashbang: hurts to look at and is basically unreadable. Not to mention, if it happens on one site, it affects the whole browser.

Here is one site https://www.va.gov/jobs/ which only became like this when I clicked one of the links to a site that had a lot of white.

The site that caused the previous one to get real bright:

Finally, here’s the site that caused this problem yesterday:

The only thing that fixes it is restarting the browser. But you never know if you’re going to encounter a web page that causes it (it could even be just a tab you have up that you reawaken by clicking on it that causes it to happen). Even on here, I can tell the website is way too bright.

I followed this solution, mistaking it for high contrast and not high brightness, but it only showed that restarting the browser temporarily fixes it.

I don’t know if there was a silent update that caused this or what, but I would appreciate it being looked into.

I, too, at first caught this effect from scrolling the Twitter feed. However, the problem manifests itself best if you open a Google search and try to enter abracadabra into the string.
As soon as the spell check red underlines your search, the screen immediately becomes bright contrast. This is clearly a terrible bug and it is a pity that there are still no comments from the developers!

Examples:
before contrast
after contrast

Help ASAP!
This is extremely annoying!

Thank you all for reporting. I’m trying to reproduce on my end but cannot seem to do so. Can anyone provide exact steps they took to produce this issue? @Maax I tried the “abracadabra” search on Google steps you mentioned above but did not see the issue.

I’ve forwarded this information to the team regardless, but having any steps to reproduce would be very helpful. Additionally, knowing what OS (Win 10, 11, 7??) and what Brave version you’re using when you see this issue would also be helpful.

Thank you.

Can any of you try going to brave://flags/#force-color-profile and set the value to sRGB and tell me if the issue still persists?

I did that and it made a small improvement but it is still more bright than it used to be. When I go to a page that is mostly white, such as this one, and then click in the URL I can see the blue background with sRGB, but not with the default setting. This started when I ran an update today. I am running Windows 10 Enterprise version 21H1 build 19043.1706. Brave is Version 1.40.105 Chromium: 103.0.5060.53 (Official Build) (64-bit)

I switched back to the Default color profile and went to https://bonginoreport.com/ and it triggered the ultra bright display again, so this is repeatable for me.

I did it! It is totally help for me now! No any extra contrast with the standard actions. Thanks!

You asked - My hardware is Windows 11
1.40.105 Chromium: 103.0.5060.53 (Official), (64 bit)

This worked for me. Made an account and came here to find a solution.
I would like to point something out, and maybe someone else here can chip in.
I have a three monitor (tv’s actually) setup, and one of them has HDR. I have HDR enabled in windows.

I noticed if I disable HDR, it doesn’t do the weird brightness switching. I’m not going to because heck, I like playing my games with it, but maybe it’s something to look into?

1 Like

Looks like the changing the flag value in my last reply is resolving this issue for some users but not all. Can I get a head count of who sees this issue fixed when changing the flag as instructed here?

1 Like

Tried the brave::/flag-dark mode solution the issue persist…

Apparently switching the " use hardware accelaration when available" off fixed for me not sure for amd gpu, but nvidia gpu affected for me…

Tested with my AMD Laptop and recreate the issue, apparently for me it happen only on Nvidia gpu…

EDIT: it has been fixed by using the “brave://flags/#force-color-profile” set to sRGB
thank you, for increasing the lifespan of my eyes

2 Likes

This was happening to me also, but following your instructions to change the flag to sRGB has fixed it for me so far, completely back to normal. colors and contrast. Will update if it happens again but so far so good.

1 Like

The sRGB setting fixed it for me.

Also, I can set it to “HDR10(HDR where available)” which also fixes the problem.

I have both an HDR and an SDR monitor - and when set to “default” the SDR monitor is very washed out on Brave. This is not the case with Chrome.

2 Likes

The exact same problem started today on my system. The longer the web page, the more the problem shows up. None of my other browsers have this problem. I cleared the cache, but it made no difference. The problem is so bad that I ended up going back to Firefox.

@Achernahr , @JimBland , @Mattches

HDR / SDR Issue - BUG - was in Chromium.

Latest Brave Browser Stable Release for desktop v1.40.113 includes Chromium fix.

Specific commit at Google Git, for Chromium, details:

https://chromium.googlesource.com/chromium/src/+/7db83834068749078991e7953d509b793a41247e

HDR/Windows: SDR displays must have 80 nits

For tone mapping, I changed Windows to treat SDR displays as being 203 nits.

What I didn’t think through in doing this is that SDR displays will use HDR pixel formats, and when they do, setting the SDR white level to 203 nits will result in everything being 2.5x brighter than it should be.

Change the logic to not override the SDR white level for non-HDR displays. This will go back to the default value of 80. Also do not compute the HDR max luminance for non-HDR displays.

Add a TODO to not use HDR formats on non-HDR-capable displays.

2 Likes

Thanks for the update!

@289wk Nice find! :smiley:

A little off-topic but still relates…

Is there a way to tell what Chromium version the fix was released for? I can’t figure it out from the bug report. Help! lol

My logic on determining Brave version where fix was in… following parent directory up in Chromium bug report… pick up benchmark/roll release version. I have no clue if this is accurate or not… logic way off base? Right or Wrong? How the heck can I look this up? lol

Brave v 1.40.107 (Chromium 103.0.5060.66) →
Fix released in Chromium 103.0.5060.101 →
Brave v 1.40.113 (Chromium 103.0.5060.114) →
ergo fix was in Brave v 1.40.113 (and not in v 1.40.107) because chromium x.114 > x.66

@Chocoholic

Method 1

Search for Chromium issues [bug/bug-regression/compat/feature/task]:

For search criteria: hdr sdr tone

Enter / Return key . . . result:

Method 2

Go to: ‘https://github.com/brave/brave-browser/blob/master/CHANGELOG_DESKTOP.md’ Result:

Changelog_for_Chromium_103.0.5060.114_step_01

Click on the (Changelog for 103.0.5060.114) link. Result:

Over on the right, click on the ‘103.0.5060.114’ link. Result:

Over on the right, click on the ‘log’ link. Result:

Scrolling down . . . found:

7db83834 HDR/Windows: SDR displays must have 80 nits by Christopher Cameron · 6 days ago

A course from commit to Chromium release

The HDR/Windows: SDR displays must have 80 nits commit:

https://chromium.googlesource.com/chromium/src/+/7db83834068749078991e7953d509b793a41247e

Scroll down, there, and notice the area of details:

I chose the later (3733217) ‘Reviewed-on’ link. Result, Chromium Gerrit webpage:

Over on the left, notice the ‘refs/branch-heads/5060’ link:

refs_branch-heads_5060

The result is a succession of Subjects (commits/reviews). Latest at the top.

Notice over on the left, the Subjects (commits/reviews):

  • ‘Incrementing VERSION to 103.0.5060.119’
  • ‘Incrementing VERSION to 103.0.5060.118’
  • etc.

Notice in each, the ‘5060’ branch number - that is for Chromium M103. (Thus, you see how the numbers are stitched together, to make a Chromium version number.)

At the lower right corner of the window, click on the Right Arrow, in order to get to Page 2.

Right_Arrow_to_next_page
Page_2

Scroll down to:

Incrementing VERSION to 103.0.5060.114

Scroll down a bit further thru the older Subjects (commits/reviews), and you will find the HDR SDR TONE Subject (commit/review), again:

You might have to go on to Page 3, to find that.

My understanding (of the moment), is that Merged commits lead up to a Chromium version that is incremented; again:

Incrementing VERSION to 103.0.5060.114

Scroll down to . . . the following area in that webpage:

To see the Chomium version 103.0.5060.114 commit itself, click on the ‘a1c2360’ link, upper-left. Result:

In the result if you click on the ‘log’ link, you will again see the sequence of commits that lead up to the Chromium version 103.0.5060.114 commit.

2 Likes

@289wk Thank-you! Haven’t played with yet but Method 1 looks a lot easier! lol

Appreciate the information. Thank-you. :smiley:

1 Like