Moving component:Internals>Media>Controls to Blink>Media>Controls

Test page:
https://mounirlamouri.github.io/sandbox/media/force-hide-controls.html

STR:
1. Right click on video to show context menu
2. Select "show controls"
3. Controls appear
4. Click Pause

Expected result: controls stay

Actual result: controls are hidden

I was able to reproduce on Firefox and Chrome: both browsers inject the controls attribute when "Show controls" is selected. Need to check other browsers.

Safari does the same.

I wonder if this behaviour could be on purpose.

+foolip@, do you have any background on this?

I don't think this is really intentional, it's just the simplest way to implement the context menu. However, it would be hard to uphold a principle of explicit user choice in the general case. If the user plays from the context menu, should the page also not be allowed to pause again? Should it be allowed to seek to another position?

The loop option in the context menu presumably works in the same way.

In this specific case, I'd suggest reaching out to the imgur developers to find out if this was intentional or accidental. If intentional, they'd still be able to override it using ::-webkit-media-controls { display: none }, so if we didn't also plug that hole we'd risk increasing usage of ::-webkit-media-controls, which I think we should try to get rid of.

I don't think the cases of "show controls" and "play" are parallel.  "Show controls" feels like a permanent state toggle.  "Play" does not, at least not as much.  Part of this is that playing is a thing you do with pretty much all videos and is part of the normal course of watching a video.  "Show controls" is something exceptional, and if you choose to do it, you presumably have a specific reason.

By comparison, long ago when implementing spellchecking in Firefox, we went out of our way to make it so that user toggles of whether a field should be spellchecked would override whatever the page did.  This was because manually toggling spellchecking on and off for a specific field was an unusual case and the user's intent should override the web author's.

My feeling is that because all browsers behave the same, our current behaviour is clear and simple and for it to be broken, websites need to do things we shouldn't really expect and the feature is unlikely widely used, it should probably be low priority.

This said, we don't know the usage of the feature so I would like to record ContextMenu.SelectedOption.Video on desktop so we could figure out usage. If usage is not significant, I think we should bump this down to P3. Though, as foolip@ suggested, we should probably ping imgur about the bug.

I REALLY disagree that browser behavior alignment here is a signal that we're doing it right and we shouldn't change.  This is simply something that hasn't been thought about a lot yet.  A few years ago Chrome didn't even have the ability to show controls on a video.  Imgur's wacky "gifv" format didn't exist.

We've been trying to move people off of animated GIF and over to real video formats.  But along the way we (the image decoder folks) have found that there are a whole bunch of challenges to that in the video stack, at all levels.  This is one of those cases where we have the opportunity to provide a good experience and the site is breaking it.  The team lately has started to think more about what "interventions" the browser should do on the user's behalf, and I think this is a good example of one.

I don't contest the idea that less-used features are lower-priority, and I think the idea of reaching out to Imgur is good. (Who, specifically, is on the hook for that?  Do we have a dedicated outreach subteam that does this sort of thing?  Because if it isn't assigned to anyone, it won't actually happen.)  But it seems like the implementation here would not be so onerous that it wouldn't be worth doing this (and we as a team have a tendency to never get around to fixing P3 feature requests).

My thinking here is really: what would be the impact of the feature? how many users will be impacted? A highly impacting feature for a few users is interesting, a low impact feature for a large number of users is great too. However, I'm afraid this feature might be a low impact feature because it merely fixes an annoyance on some websites that do things a bit weirdly and I would guess that it would impact a low number of users.

I'm going to ping a few folks who might help to contact imgur.

FWIW, at the end of the day I agree that this is a bug, one that I have known about but never filed an issue for because I never encountered it in the wild. (My main concern was actually breaking assumptions of the page, when a controls attribute suddenly appears.)

I think that step 1 is to find out if this is intentional behavior on the part of imgur or not. If it's accidental, then the tri-state fix would be enough to avoid future instances of that. But if it's intentional, then there's also ::-webkit-media-controls to worry about.

FWIW, I've started poking around to get in contact with imgur.

 Issue 570886  has been merged into this issue.

mlamouri: Were you able to get in contact with imgur?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still valid