If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

media.autoplay.enabled=false prevents click-to-play on straight video files

NEW
Assigned to

Status

()

Core
Audio/Video: Playback
P3
normal
2 years ago
3 months ago

People

(Reporter: gerald, Assigned: gerald)

Tracking

(Blocks: 1 bug)

43 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
Spawned from bug 1231886:
"Set media.autoplay.enabled to false and straight HTML5 videos don't play when you click the large play button (overlay) at the center of the video.
http://video.webmfiles.org/big-buck-bunny_trailer.webm"

This bug will concentrate on straight videos (i.e., not Youtube or others).
(Assignee)

Comment 1

2 years ago
Created attachment 8714170 [details]
MozReview Request: Bug 1244592 - Fix non-autoplay click-to-play - r?cpearce

When media.autoplay.enabled==false, only videos may only be started through
direct user actions.
Unfortunately, for straight video files, the click-to-play handler defers
video.play() to a 0-timeout (to allow other scripts to consume the click if
they wish), which means the play() action arrives *outside* of the user-
interaction window; in which case it will be blocked.

The easiest solution is to send a play() then pause() immediately in the click
handler, so that the play() is not blocked; a side-effect is that the media
element remembers that user interaction has started, and will not block future
play()'s.

// If not already started, send a quick play then pause,
// so the media element thinks user interaction has happened
// when calling play() again in the timeout below (otherwise
// media.autoplay.enabled==false might block it).

Review commit: https://reviewboard.mozilla.org/r/32963/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/32963/
Attachment #8714170 - Flags: review?(cpearce)
(Assignee)

Comment 2

2 years ago
(In reply to Gerald Squelart [:gerald] from comment #1)
> // If not already started, send a quick play then pause, [...]

Sorry for the pasted code comment in the patch comment in comment 1, I'll remove it from the patch comment.

(And sorry for the overuse of the word 'comment' in this comment.)
(Assignee)

Updated

2 years ago
Summary: media.autoplay.enabled prevents click-to-play on straight video files → media.autoplay.enabled=false prevents click-to-play on straight video files
(Assignee)

Comment 3

2 years ago
Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2a491099c464
(Assignee)

Comment 4

2 years ago
Comment on attachment 8714170 [details]
MozReview Request: Bug 1244592 - Fix non-autoplay click-to-play - r?cpearce

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/32963/diff/1-2/
(Assignee)

Comment 5

2 years ago
(In reply to Gerald Squelart [:gerald] from comment #4)
> Review request updated; see interdiff:
> https://reviewboard.mozilla.org/r/32963/diff/1-2/
Small change, much better way to do the sneaky play-then-pause only once per media element.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4d4e9cb3bafc
(Assignee)

Comment 6

2 years ago
Boris and/or Olli, Chris suggested that I contact you to find a better way to fix this issue.

Quick summary:
http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/videocontrols.xml#1093
The straight-file video controls' "play" button does video.play() in a timeout handler (to allow user scripts to intercept the click and set defaultPrevented on the event). But a side-effect of that is that the delayed play() call appears to come from a non-user-initiated script and therefore is blocked when media.autoplay.enabled==false.

My attempt at fixing this was to immediately send a play() (then pause), so the media element thinks it's been interacted with, and won't block the play() in the timeout.
It worked, but it may also introduce side-effects from the extra play() that could confuse some websites.

So, would you have ideas on how else we could perform the 'play()', *after* other scripts have had a chance to intercept the click, but such that it will still appear as a user-initiated action?
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bugs)
The right theoretical way to do this is to use a system event listener, I would think.  But I'm not sure XBL can add those in this case, since it has no access to the nsIEventListenerService.

Olli, maybe we should add a way for it to be able to?  For example, adding something IsChromeOrXBL on EventTarget or something?
Flags: needinfo?(bzbarsky)
(Assignee)

Comment 8

2 years ago
https://reviewboard.mozilla.org/r/32963/#review30247

Closing review, will work on better patch.
(Assignee)

Updated

2 years ago
Attachment #8714170 - Flags: review?(cpearce)

Comment 9

2 years ago
Not sure where you want to add the event listener, but group="system" in xbl's <handler> element?
That should work when we're dealing with native anonymous content, like we should here.

You can of course check event's .originalTarget or it ancestors in handler to make sure you're dealing with the right target, if you need to add the listener somewhere higher up in the (composed) dom tree and not to the expected target.
Flags: needinfo?(bugs)
(In reply to Boris Zbarsky [:bz] from comment #7)
> Olli, maybe we should add a way for it to be able to?  For example, adding
> something IsChromeOrXBL on EventTarget or something?
Yeah, we could add [IsChromeOrXBL] addSystemEventListener to EventTarget. I think that shouldn't be too scary.
(Assignee)

Updated

2 years ago
Assignee: nobody → gsquelart
Mass change P2 -> P3
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.