Closed Bug 1495064 Opened 6 years ago Closed 6 years ago

Refactor the logic of requesting wakelock

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox64 --- fixed

People

(Reporter: alwu, Assigned: alwu)

References

(Blocks 1 open bug)

Details

User Story

Media Wakelock Behaviors

1. media in the foreground tab, playing both video and audio
- request "video-playing" and "audio-playing" wakelock

2. media in the foreground tab, playing only video (audio is muted or volume=0)
- request "video-playing" wakelock

3. media in the foreground tab, playing only video (no audio track)
- no wakelock

4. media in the foreground tab, playing only audio (audio element)
- request "audio-playing" wakelock

5. media in the background tab, playing both video and audio (video is invisable)
- request "audio-playing" wakelock

6. media in the background tab, playing only audio (audio element)
- request "audio-playing" wakelock

7. media in the background tab, playing only video (audio is muted)
- no wakelock

Attachments

(3 files)

Forked from bug1494982 comment0, the logic of requesting wakelock is not clear, we should make it more easier to understand.
HTMLMediaElement::UpdateWakeLock() is responsible for creating and releasing audio wakelock.
HTMLVideoElement::UpdateWakeLock() is responsible for creating and releasing video wakelock.

In addition, each platform would handle system wakelock properly depending on different requests.
If video is short, it's possible a GIF-like video or screen have a low chance to be shutdown during
video playback.

Therefore, we don't request video wakelock for short video.
Priority: -- → P2
Attachment #9012992 - Attachment description: Bug 1495064 - part2 : don't request video wakelock for short video. → Bug 1495064 - part2 : don't request wakelock for video without audio track.
Adding a test to check whether the wakelock state is correct under different situations. However,
the lock state of power manager doesn't equal to the actual platform lock. Now we don't have any
way to detect whether platform lock is set correctly or not, but we can at least make sure the
specific topic's state in power manager is correct.
User Story: (updated)
User Story: (updated)
Comment on attachment 9012991 [details]
Bug 1495064 - part1 : refactor the logic of requesting wakelock.

Jean-Yves Avenard [:jya] has approved the revision.
Attachment #9012991 - Flags: review+
Comment on attachment 9012992 [details]
Bug 1495064 - part2 : don't request wakelock for video without audio track.

Jean-Yves Avenard [:jya] has approved the revision.
Attachment #9012992 - Flags: review+
Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9b3be971c8b0
part1 : refactor the logic of requesting wakelock. r=jya
Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/696f01b5d804
part2 : don't request wakelock for video without audio track. r=jya
Blocks: wakelock
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: