See attached screenshot.
OS: Windows 10 on Lenovo C630. Default Windows theme (AFAIK).
The urlbar/searchbox background color is, if not identical, very close to the color of non-selected tabs. They don't have borders, and the toolbar they are in is only a slightly lighter shade of grey, making them hard to distinguish. Even the selected tab might be difficult to distinguish from the other tabs.
The alpenglow theme is much clearer.

As highlighted with attachement #9216334, attachment #9216335 [details] and attachment #9216336 [details], I can confirm the same behavior of low contrast on a ubuntu 20.10 system when using both Light and Dark theme (although in my opinion it is a bit less sensible with Dark) ; System theme is better.

I had to use a few other system yesterday (Windows 10 and macOS Big Sur) and the rendering (different screen, different but good lighting condition) was the same with low contrast. Just to be clear, I have no problem with my vision, and feedback from third parties was the same.

I agree, I don't have accessibility issues and I had to disable Proton due to poor contrast...

The Tracking Protection icon in the URL bar (when content is being blocked) is also more difficult to see in Proton when using the default dark theme.

In particular, the dark-blue of the bottom left of the shield blends in with the dark grey background of the URL bar.

Meanwhile, in Photon, the icon had better contrast despite being coloured similarly, due to being thicker & being against a lighter shade of grey.

Perhaps the colour of the icon in Proton should be brightened to be more visually striking against the darker URL bar.

Another low-contrast item in Proton's dark theme is the bookmark star.

Compared to Photon, Proton uses a darker shade of blue for the star and a darker shade of gray for the URL bar, resulting in dark-on-dark colouring that is difficult to see.

Oh, silly me--the colour scheme I was using isn't the Dark theme, but the System theme (with a dark desktop theme on GNOME 40 + Fedora 34). I forgot that the System and Dark themes can differ.

And happily, the Dark theme gives much better contrast to both the Tracking Protection icon and the bookmark star.

With that said, the System theme contrast is still worse in Proton than it was in Photon. Yet in some cases (such as in Comment 6), the System theme can offer better contrast for some UI elements.

Is the specific colouring of the System theme decided by the desktop environment?

My first two images were unfair comparisons between Photon Default & Proton Dark, so here is a 1:1 comparison of the Default/System, Dark, and Light themes. (Alpenglow is mostly identical between both versions.)

Takeaways:

• System/Default has weak contrast for everything except Photon's bookmark star. This is probably more of an issue with desktop theme colouring, though.
• Dark has strong contrast in all versions.
• Light contrast is strong, though the "active" colouring of Proton's Tracking Protection icon is a bit harder to distinguish now that it's thinner than before.

Overall, URL icon contrast isn't as bad as I thought.

Of course, none of this has any bearing on the tab strip / toolbar / the URL bar itself.

(Oops, that first sentence should have said Photon Dark & Proton System. Apologies for the spam.)

Bug 1714803(now closed??!?) is a different issue than 170572: Firefox Windows Version 89.0 changes Windows System Wide Grab Bar Color to no-contrast "white" (very light gray). Before Version 89.0 the Title Bar/Grab Bar was ok.
Maybe there's a problem communicating Grab Bar which is sometimes, usually?, called the Title Bar although Firefox doesn't put a title in the top Title Bar. Bug 170572 does not mention the Title Bar, the place at the top of a window where an application's name can be placed.

This is the reason the Title Bar is sometimes called the Grab Bar:

1. when a window is maximized you can grab it with the mouse cursor and move the window, the window "un-maximizes.
2. you can grab a grab bar using the mouse and move the window, if it's moved to the top of the display it will maximize
3. if maximized double-clicking the grab bar will have the same effect as clicking the small rectangle at the upper right corner of the grab bar (the window will un-maximize)
4. if the window is not maximized double-clicking the grab bar will maximize the window the same as clicking the little rectangle at the upper right corner of the grab bar (the window will maximize).
5. clicking the - at the upper right corner of the grab bar minimizes the window
6. clicking the x at the upper right corner of the grab bar closes the window
7. the grab bar/title bar is the reference for the rest of the window
   By the way this is essential functionally, don't mess it up.

I know everyone knows this, or should know: Why screw it up??? The grab bar is a windows universal system-wide GUI standard, all of its elements must be distinguishable and legible. No contrast fails to meet that requirement. This is NOT PART OF A FIREFOX THEME, at least I hope not!

I think the bug 1717750 has been inappropriately marked as duplicate to this bug.
While this bug is dealing with changing the color contrast, 1717750 is dealing with the missing separator. Unless the bar is really the very same color with the background I would say the separator is missing.
This might be the design intent, and I learned my protest is futile but if this is the case the bug 1717750 should be closed as "Won't fix" rather than duplicate of fixing something else.

The attachment https://bugzilla.mozilla.org/attachment.cgi?id=9225430 show both issues:

• one can assess the contrast of icons and ask for improving the contrast.
• one can observe the missing separators - unless is a "no contrast whatsoever" separator - and ask for bringing back the separators.

So, is the separator coming back?

On my Linux desktop with the dark theme, the darker gray address bar and the lighter gray panel have a contrast ratio of 1.2:1, I think WCAG says it should be 3:1 for UI elements. https://webaim.org/resources/contrastchecker/

Is this a duplicate of (or at least closely related to) bug 1704347?

Going from comment 0 in that bug, it's not a dupe, since I first noticed it on Windows, without a high contrast theme.

(In reply to Mike Hommey [:glandium] from comment #26)

Going from comment 0 in that bug, it's not a dupe, since I first noticed it on Windows, without a high contrast theme.

Yeah, it's a bit confusing. High contrast is indeed how the reporter experienced the issue. However, the issue of being unable to visually distinguish the current tab (largely due to poor contrast) isn't at all specific to high contrast, so that bug was never high contrast specific. I'll leave it to Asa as to whether he wants to dup this.

This bug is also not exclusively about distinguishing the current tab.

Hey Misha - is this something you've been working on or is your focus different?

(In reply to Josh Berman from comment #29)

Hey Misha - is this something you've been working on or is your focus different?

Yup! this is what i've been working on. https://mozilla-hub.atlassian.net/jira/software/c/projects/FXCD/boards/414?modal=detail&selectedIssue=FXCD-52

(In reply to James Teh [:Jamie] from comment #27)

(In reply to Mike Hommey [:glandium] from comment #26)

Going from comment 0 in that bug, it's not a dupe, since I first noticed it on Windows, without a high contrast theme.

Yeah, it's a bit confusing. High contrast is indeed how the reporter experienced the issue. However, the issue of being unable to visually distinguish the current tab (largely due to poor contrast) isn't at all specific to high contrast, so that bug was never high contrast specific. I'll leave it to Asa as to whether he wants to dup this.

I asked Asa, he thinks we can dupe.