2020233 - Blocking autoplay isn't respected on YouTube if control is pressed while video is loading

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[James Teh [:Jamie]]

STR:

1. Ensure autoplay is blocked for youtube.com.
2. Paste this address into the address bar: https://www.youtube.com/watch?v=L076ngGbBRc
3. Press enter to load it.
4. Immediately hold down the control key.
   • Expected: The video should not play automatically.
   • Actual: The video plays automatically.

7:45.83 INFO: Last good revision: 0428c2bbe4b0ec8121e25f275a37f70d75748e49
7:45.83 INFO: First bad revision: 617aa8f27e89a7c20253d0d425bb11f7e0854a0f
7:45.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0428c2bbe4b0ec8121e25f275a37f70d75748e49&tochange=617aa8f27e89a7c20253d0d425bb11f7e0854a0f
This implicates bug 2001938.

This disproportionately impacts screen reader users because they are more likely to press the control key while a page is loading to silence screen reader utterances. Worse, the video auto playing might clobber screen reader speech, making it difficult or overwhelming to get out of this situation, especially for less experienced screen reader users.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:sfarre, since you are the author of the regressor, bug 2001938, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Simon Farre [:sfarre]]

Patch fixed so that ctrl generates user activation.

I wonder why blocking of autoplay is respecting user activation, at all? Since that patch is the regressor it seems like blocking autoplay is respecting user activation, when it shouldn't?

:edgar do you know?

Comment 3

[Edgar Chen [:edgar]]

autoplay uses the stick user activation, and after bug 2001938, modifier is also considered user activated (which matches with the spec).
Or perhaps we don't want to do that for the screen reader users.

:Jamie, do you know if there’s any way to know whether a screen reader is in use?

Comment 4

[James Teh [:Jamie]]

It's generally not ideal to change behaviour based on screen reader detection. In this case, given how disproportionately it impacts screen reader users, if it were the only path forward, we might make an exception.

That said, I'd argue that modifiers alone are not a sufficient signal of user activation. That is the keyboard equivalent to treating a mouse wiggle (that isn't necessarily even in the page viewport) as user activation. The user might be holding down control because they're about to press control+t to open a new tab, control+tab to switch tabs, control+shift+escape to open the Windows Task Manager, control+escape to open the Windows Start Menu, etc. Or maybe they're holding down alt because they're about to press alt+tab to switch apps, alt+f to open the file menu, alt+d to focus the address bar, etc. Or maybe they're holding down shift because they're about to press shift+escape to open the Firefox Process Manager, shift+alt+tab to switch apps, shift+f12 to open the Accessibility Dev Tools, etc. Not a single one of these actions indicates user activation (or even the slightest bit of interaction) with the page itself.

Comment 5

[Anna Yeddi [:ayeddi]]

This is a high access-S3 because while it is not fully blocking a user of a screen reader from using the browser, but it makes it drastically worse / difficult.

Comment 6

[Donal Meehan [:dmeehan]]

The planned Fx148 planned dot release builds on Monday, 2026-03-09 with reelase uplift requests due by eod Friday 2026-03-06.
:sfarre/:edgar, do you plan on investigating in time for Fx148?

Comment 7

[Edgar Chen [:edgar]]

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

It's generally not ideal to change behaviour based on screen reader detection. In this case, given how disproportionately it impacts screen reader users, if it were the only path forward, we might make an exception.

That said, I'd argue that modifiers alone are not a sufficient signal of user activation. That is the keyboard equivalent to treating a mouse wiggle (that isn't necessarily even in the page viewport) as user activation. The user might be holding down control because they're about to press control+t to open a new tab, control+tab to switch tabs, control+shift+escape to open the Windows Task Manager, control+escape to open the Windows Start Menu, etc. Or maybe they're holding down alt because they're about to press alt+tab to switch apps, alt+f to open the file menu, alt+d to focus the address bar, etc. Or maybe they're holding down shift because they're about to press shift+escape to open the Firefox Process Manager, shift+alt+tab to switch apps, shift+f12 to open the Accessibility Dev Tools, etc. Not a single one of these actions indicates user activation (or even the slightest bit of interaction) with the page itself.

I agree with that, however, there is no good way to predict user intention or whether the page will call preventDefault() :(.
Web applications usually expect the user activation to already be set when handling the keydown event, so we can not delay setting the user activation. We have had several bugs due to behavior inconsistencies with other browsers, we tried to improve that in bug 1641171, but there are still others.

Since this causes significantly worse behavior for screen reader user, :sfarre, could you help to revert bug 2001938? For the Google slide case (bug 2001938), I don't have a better solution than adding ctrl+F5 into white list. :(

Comment 8

[Simon Farre [:sfarre]]

I'll revert it right away, and we can address the white listing in a follow up.

Comment 9

[Pascal Chevrel (relman team) -> :pascalc]

Bug 2001938 Reverted for Beta, I am adjusting the flags accordingly. We can test that the issue here is fixed with 149.0b4 which builds and ships later in the day. I'll let Donal decide on what he wants to do for the 148 planned dot release.

Comment 10

[James Teh [:Jamie]]

Just a quick note to say I really appreciate the swift and decisive action here to sort this out for screen reader and other keyboard-heavy users. Thank you.

Comment 11

[Donal Meehan [:dmeehan]]

The regressor Bug 2001938 was backed out on all channels

Comment 12

[Raluca Popovici, Desktop QA]

I was able to reproduce this issue on Ubuntu 24 using Firefox 149.0b3.
Verified as fixed on Ubuntu 24 using Nightly 150.0a1 (2026-03-09), Firefox 149.0b6, Firefox 148.0.2.