Closed Bug 1350191 Opened 8 years ago Closed 8 years ago

Video doesn't play normally when I change volume

Categories

(Core :: Audio/Video: Playback, defect, P1)

53 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla55
Tracking Status
firefox-esr45 --- unaffected
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 + verified
firefox54 + verified
firefox55 + verified

People

(Reporter: 684sigma, Assigned: ralin)

References

Details

(Keywords: regression)

Attachments

(1 file)

I have a problem with Firefox Beta 53. It doesn't happen in Beta 52 and ESR 45. Sometimes when I change volume in video, it doesn't play. Here's how to reproduce it: 1. Open https://www.w3schools.com/html/HTML5_video.asp 2. Play the video 3. Click near the beginning of timeline, press down/up several times Result: video temporarily stops Expected: video should continue playing
Has STR: --- → yes
Keywords: regression
An audio channel issue?
Component: Audio/Video → Audio/Video: Playback
Flags: needinfo?(alwu)
[Tracking Requested - why for this release]: UX regression, Video playback is interrupted due to volume keyboard shortcut Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ec7fb4f14d3ec23ded7eea40ff49ebbcbec6bde1&tochange=8d2eecb7ea5a16e02862dd326ce4519082ce9901 Regressed by: Bug 1271765 I think the very problematic Bug 1271765 should be backed out from 53 beta.
Blocks: 1271765
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ralin)
Assignee: nobody → ralin
Status: NEW → ASSIGNED
Flags: needinfo?(ralin) → needinfo?(684sigma)
Flags: needinfo?(alwu)
Flags: needinfo?(684sigma)
Priority: -- → P1
Thanks for report. This is another derived issue from focusibility after media controls De-XUL. The problem here is the input[type=range] get focused by first click, so up/down arrow key handler would propagate from inner to outer element which fires the native behavior of input[type=range] first and .stopPropagation latter (in current bubble propagation). I've made a patch change the way to "capture" mode to preventDefault() for focused element inside <videocontrols>.
s/key handler/key events/
Comment on attachment 8851191 [details] Bug 1350191 - Change keypress event propagation to capture to correctly preventDefault if control is focused. https://reviewboard.mozilla.org/r/123564/#review126412 Can you please add a test for this?
Attachment #8851191 - Flags: review?(jaws) → review-
Comment on attachment 8851191 [details] Bug 1350191 - Change keypress event propagation to capture to correctly preventDefault if control is focused. https://reviewboard.mozilla.org/r/123564/#review126412 test added :) Thank you for the review.
Comment on attachment 8851191 [details] Bug 1350191 - Change keypress event propagation to capture to correctly preventDefault if control is focused. https://reviewboard.mozilla.org/r/123564/#review126878
Attachment #8851191 - Flags: review?(jaws) → review+
Pushed by ihsiao@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/85866d2aa9f5 Change keypress event propagation to capture to correctly preventDefault if control is focused. r=jaws
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Tracking for regression for 53/54/55+.
Can you request uplift to aurora and beta if you think the fix is safe for 53? Thanks.
Flags: needinfo?(ralin)
Alice, about your suggestion in comment 2, if we can fix the issues we know about now, and uplift them to 53 beta, I'm hoping we may still be ok for this to move to release. I asked for more evaluation and feedback in bug 1271765.
Comment on attachment 8851191 [details] Bug 1350191 - Change keypress event propagation to capture to correctly preventDefault if control is focused. Approval Request Comment [Feature/Bug causing the regression]: Bug 1271765 [User impact if declined]: pressing up/down arrow key triggers video seek if timeline has just been clicked by user. [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: no [Needs manual test from QE? If yes, steps to reproduce]: better to have, same as comment 0. [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: low [Why is the change risky/not risky?]: Media shortcuts works as-is. This patch only prevents keypress event from propagating inside video. [String changes made/needed]: none Thanks!
Flags: needinfo?(ralin)
Attachment #8851191 - Flags: approval-mozilla-beta?
Attachment #8851191 - Flags: approval-mozilla-aurora?
Comment on attachment 8851191 [details] Bug 1350191 - Change keypress event propagation to capture to correctly preventDefault if control is focused. fix an issue with keypress propagation in video controls, aurora54+
Attachment #8851191 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8851191 [details] Bug 1350191 - Change keypress event propagation to capture to correctly preventDefault if control is focused. Fix for minor regression in a/v controls, includes new tests. Let's take this for beta 9.
Attachment #8851191 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
I reproduced the initial issue on Firefox 53 beta 8, verified that the issue is fixed using Firefox 53 beta 9, latest Developer Edition 54.0a2 and latest Nightly 55.0a1 across platforms (Windows 10 64bit, macOS 10.12.2 and Ubuntu 16.04 32bit).
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: