This should be fixed as of backplate landing, :dholbert do you know what the original STR for that screenshot in #c1 were?

I think this is still an issue, actually, though it doesn't look as bad as the original screenshots here. (But still kinda unusable.)

The STR are just to view & interact with the controls for any <video controls> element. A trivial reduced testcase (with no actual video data) is data:text/html,<video controls>. And some examples with actual video content are http://camendesign.com/code/video_for_everybody/test.html and https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video .

And the "Actual results" at this point (for me, in Linux nightly with high-contrast mode activated via about:preferences "Override the colors...: Always"):

• the icons are all invisible unless hovered (play/pause, mute/unmute, fullscreen)
• the slider tracks are invisible
• the picture-in-picture overlay (which appears on the right side of video when I hover it) is white-on-lightgray

(In reply to Daniel Holbert [:dholbert] from comment #22)

• the icons are all invisible unless hovered (play/pause, mute/unmute, fullscreen)

Note: it looks like these icons are actually just always white (regardless of my chosen foreground/background colors), so they may or may not be visible depending on the background color.

I think these icons are SVG, so this might really end up depending on bug 1616916 (and could require some opt-in markup in the SVG, if opt-in is needed).

• the slider tracks are invisible
• the picture-in-picture overlay (which appears on the right side of video when I hover it) is white-on-lightgray

These ^^ issues still happen regardless of my choice of background color, FWIW.

The styling for these controls is e.g.

.playButton {
  background-image: url(chrome://global/skin/media/pauseButton.svg);
}

https://searchfox.org/mozilla-central/source/toolkit/themes/shared/media/videocontrols.css#168

You can take a look at the button itself (in isolation) by just directly visiting chrome://global/skin/media/pauseButton.svg , or you can see it in searchfox at
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/media/pauseButton.svg

Its fill-color is set via fill="context-fill" in the SVG source, which uses a mozilla-internal way to pass in a custom possibly-browser-theme-controlled color from an external document to an embedded SVG document. (The outer document opts in to passing in the value by setting e.g. -moz-context-properties: fill; as you can see elsewhere in videocontrols.css, and the inner document opts in to using that value via the special color keyword context-fill. This only works for the svg-specific properties fill and stroke, as I recall, because we don't want it to become a generalized thing.)

Anyway, I say all that just to clarify how these icons are drawn right now. Ideally we should have them do whatever is necessary to honor the high-contrast requirements, via bug 1616916 or whatever other high-contrast-for-SVG work ends up happening.

Thanks for taking a look and adding all that info! :)

This patch gets us most of the way, but with this patch applied, the control bar icons color is always forced to ButtonText due to bug 1625036. With bug 1625036 fixed, everything should work fine.

HTML5 video from https://www.w3.org/2010/05/video/mediaevents.html doesn't display the progress bars (video and sound) on Windows 10 and HCM. This also reproduces on older Firefox versions, so not a recent regression. Please let me know if I should file a new bug for this.

Mac OSX 11.6 and Ubuntu 21.04 are not affected.

(In reply to Petruta Horea [:phorea] from comment #28)

Created attachment 9266227 [details]
video controls.png

HTML5 video from https://www.w3.org/2010/05/video/mediaevents.html doesn't display the progress bars (video and sound) on Windows 10 and HCM. This also reproduces on older Firefox versions, so not a recent regression. Please let me know if I should file a new bug for this.

Mac OSX 11.6 and Ubuntu 21.04 are not affected.

Yes, please file a new bug.

Thank you!(In reply to :Gijs (he/him) from comment #29)

Yes, please file a new bug.

Thank you! I've created bug 1758081 for the mentioned issue.

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Hi Morgan - I'm no longer seeing any contrast problems with our native video controls on Windows 10 High Contrast Mode and Windows 11 High Contrast Themes. Do you think this issue can be closed?

Yep! Sounds good :)

Thanks! Closing this bug as resolved - fixed.