1313233 - Improving media.autoplay.enabled

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, enhancement, P3)

Description

[sworddragon2]

Attachment: testcase.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160928160550

Steps to reproduce:

1. In about:config set media.autoplay.enabled to false.
2. In the attachments is a testcase. Just open it and click on the "Start Video" button (the web console can be opened for additional details).


Actual results:

The playback of the first video gets blocked while it was started by user interaction and after a random time between 5 and 10 seconds another total different video autoplays.


Expected results:

I'm not sure what the correct behavior is but the current one seems to be broken. That the first video doesn't play is probably because it listens for the loadstart event before invoking its play() method so it is actually invoked by a later cycle in the event loop. The second video's play() method is also invoked by a later cycle in the event loop and it seems to be possible to store the user interaction that was done at any time on a website for any amounts of future cycles in the event loop (semi-autoplay).

So the actual behavior does prevent playing videos if they start playing in a later cycle in the event loop even if it originates from the user interaction which might break some applications (for example if they listen to their own media events; if they implement adaptive streaming without MSE to avoid CORS restrictions; other special cases (for example videos on twitch besides being prevented from autoplaying don't even play at all if started as the video stops immediately)) while they can still be autoplayed at any time in any amounts if the user has made at some point only 1 interaction with the website.

Some potential solutions:

1. play() should be restricted more aggressive, eventually blocking any invocations of a video's play() method from any later cycles in the event loop that had no human interaction. This is probably pretty much safe but might have high potential to break applications.
2. The cycle in the event loop that contains the user interaction does internally pass an is_trusted flag to all event handlers that are created within the same cycle. All these trusted event handlers are then allowed to invoke the play() method. This would probably not break applications but could cause unexpected semi-autoplay like the second video in the testcase as soon as the user has interacted with the website.
3. Like 2. but passing the is_trusted flag should maybe limited to the specfic events from HTMLMediaElement. This would only cause a video being semi-autoplayed based of its own events or another video being semi-autoplayed based on another video. Maybe somebody has an idea how this can be done even better.
4. Eventually somebody has an idea how this could be solved in another way.

Comment 1

[sworddragon2]

On having thought about this a bit more: Eventually suggestion 2 needs just a mechanism to revoke the permission to autoplay videos on trusted event handlers to prevent unexpected semi-autoplay. For example an user interaction that results in stoping one of the related vidoes could revoke the permission.

Comment 2

[sworddragon2]

I have thought again about this and while this topic mainly claims about videos any audio source should be considered for this too. Thinking of my second suggestion with the extension from comment #1 audio sources might be more tricky than video sources. This is because an autoplaying video can only annoy the user if it is visible and as soon as it is visible the user could stop it and revoke the permission. While audio sources could also have visible contexts they do not require it and as soon as the user interacted with the site it could spawn at any time any amounts of invisible audio sources which the user can't stop.

This makes me think that this suggestion requires an enhancement to give the user the possibility to always see running multimedia instances. I think the simplest place would be the context menu of the tab. For example it could show in a submenu all running multimedia instances (without live-update until the submenu is reopened to avoid clickjacking) so even invisible instances can be stopped. If an already stopped multimedia instance gets stopped again from this menu it should also revoke all related permissions to avoid exploiting by the site.

Comment 3

[MarjaE]

This is because an autoplaying video can only annoy the user if it is visible and as soon as it is visible the user could stop it and revoke the permission.

Autoplaying video can trigger migraines and sometimes seizures. It can be hard to block the video while getting hit by the videos, the migraine can persist afterwards, and unfortunately, blocking the video is rarely enough to block the video.

For example, here:

https://www.livescience.com/planet-9-sun-twin.html

Using autoplay settings to block audio and video is not enough to block the video pop-up. Closing the video pop-up is not enough to block the video, it continues to fire elsewhere on the page. Closing the page doesn't stop the migraine from the video.

Comment 4

[Alastor Wu [:alwu]]

This bug is filed 4 years ago and our blocking autoplay implementation has been changed dramatically. So I will close this bug, and feel free to file another new bug for new autoplay issue.

Using autoplay settings to block audio and video is not enough to block the video pop-up. Closing the video pop-up is not enough to block the video, it continues to fire elsewhere on the page. Closing the page doesn't stop the migraine from the video.

we won't block the pop-up, which is outside thee resposibility of blocking autoplay. However, you can adjust your global preference to block inaudible video as well, which can prevent pop-up inaudible video from autoplaying.

You can find more details in [1], thank you.

[1] https://docs.google.com/document/d/1p81bYntlLMTxXoANnQXS9KH0TZ4y8aKKeH9x3GVS3eY/edit#heading=h.k7kwgndce3xw

Comment 5

[MarjaE]

docs.google.com inflicts smooth scrolling on page down. please do not ask users to check pages which may hurt us.

Comment 6

[Alastor Wu [:alwu]]

The PDF link [1] is in the top of that document.

https://drive.google.com/file/d/1Lkk37Vq8YhURxPL7UBVy0CuuZJU62PYQ/view