* Description: This case happened on b2g18_ril(20130515230207-ril01.01.00.019.096) and reproduced on inari device. I cannot drag the indicator to any place when the media is playing. The following is the demo video. https://dc1.safesync.com/LMkdgRSg/VIDEO0081.3gp?a=tDb_ipV7RME * Reproduction steps: 1. Launch browser app. 2. Visiting a streaming media provider (such as YouTube). 3. Clicking on a video streaming. 4. When the media is playing, drag the indicator to any place of the playing progress bar * Expected result: The media starts to play from the selected place. * Actual result: I cannot drag the indicator to any place. * Reproduction build:(inari-mozilla-b2g18-20130515230207-ril01.01.00.019.096) + Mercurial-Information - Gecko revision="4b5fe47ad76c" - Gaia revision="" + Git-information - Gecko revision="dd60c168dc409bc44196d86907dcfef84c7367fb" - Gaia revision="fbb9a3febbc81dc4c290b6a3bc095495fa19484c" Thanks!
Is this a dupe of existing work/known issues?
I normally use buri device for debugging and I did not see this problem. One problem about using Inari/unagi for v1.1 debugging is ics_chocolate is out side the support of qualcomm. And around OMXCodec and seek, there is a following problem. - Bug 878981 - [Video] Caf ics_chocolates' OMXCodec does not handle seek failure correctly
(In reply to email@example.com [:lsblakk] from comment #1) > Is this a dupe of existing work/known issues? From the video, it seems that Bug 878981 is not related to the problem.
In the case of Leo device, seek doesn't working as reporter said. I cannot drag progress bar at any position. And it occurs only in streaming case. (There's not any problem in local play)
This bug only occurred while playing video from streaming server, like YouTube. You can open any YouTube videos in Browser and Video app opens for playing. In this case, Video app can't drag, but you can use click to change the position of playing.
This bug only occurred at Video app handles view activity. I had check both implementation in video.js and view.js. They are the same. But view.html lacks the inclusion of mouse_event_shim.js.
Created attachment 760339 [details] patch for this bug Add mouse_event_shim.js to support mouse events.
Attachment #760339 - Flags: review?(dflanagan)
Comment on attachment 760339 [details] patch for this bug r=djf for github commit 98d8db1 Its a one-line fix. I've tested it and it works for me. I'll file a followup bug to remove mouse_event_shim.js from all of our media apps. And, in testing this, I see a problem with the recently-landed patch for bug 856122. If the video is paused and we drag the slider, then the spinner starts spinning and never stops. I'll also file a followup for that.
Attachment #760339 - Flags: review?(dflanagan) → review+
merged to master: https://github.com/mozilla-b2g/gaia/commit/2bbae6bd0bf539656eba7e22e17765e1a90c9aa0
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Uplifted 2bbae6bd0bf539656eba7e22e17765e1a90c9aa0 to: v1-train: ed03198858dc8c231821444a93951d556806afee
status-b2g18: --- → fixed
status-b2g-v1.1hd: --- → fixed
Thanks for your help! Good job! I cannot reproduce this bug on unagi device now. Verifed on fillowing build. * Mozilla-b2g18-unagi-eng/2013-06-17-07-02-09 + Mercurial-Information: - Gecko: "f1b84d841ced" - Gaia: "" + Git-Information: - Gecko: "24aedf8ebbc56886f0e28e1d5aaba0f9b02e3a0f" - Gaia: "9dd0acc74c8e04218749917c85367a8080fa3cb1"
Status: RESOLVED → VERIFIED
A related test case - #6230
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.