359 bytes, text/html
Try to seek the player in Music app, we will see sometimes the tapped position is not the same as the sought position.
Hi Dominic, I know how this bug happen. Let me take this. Thanks. :)
It's easy to reproduce, about 50 pixel between the tap and seek position. and if users seek too close to the end of a song, it will be very easy to trigger the player to play the next song, which might not a expected result for users, because the users might just want to seek, not skip to next song.
Could we check if it is related to codec format ? Could you check if it's still reproducible ?
blocking-basecamp: ? → -
Hi David, it's not related to the codec format. Please see http://people.mozilla.com/~dkuo/B2G/Gaia/TestMedia/13010008.mp4 You can see the position of the seek indicator is not the same as the user's tapping position. It will jump to a totally different position.
I forgot to mention this is a regression since we have some changes of the seek bar. And it only need to change one line in CSS to fix this issue, so I am re-nom it again, thanks.
Tested with Build ID 20130107105806. It's not about codec and always reproducible. This is UX related. The seeker's position is a little bit right than where I hit. Evan should be able to fix the problem.
I may have broken this with the changes in bug 823619. The music player was using the non-standard event layerX property to get mouse coordinates relative to the slider region itself. I had to switch to clientX (or screenX, I forget which). I thought that I accounted for the offset, but maybe I didn't. It might be necessary to add a getClientBoundingRect() call or somethign to find the boundaries of the seekbar and map the event coordinates within that area.
Feel free to reassign to me if you get stuck on it, since it was probably me who broke it!
We would take a patch for this but we will not block V1.
blocking-basecamp: ? → -
tracking-b2g18: --- → +
djf, It might be the changes recently that broken the slider, but I have checked the changes you made, the logic should be fine. The only thing that we didn't notice is, the target that listened to the mouse events is not always #player-seek-bar, it can also be #player-seek-bar-progress, so target.offsetLeft will be a different value, and after the calculation, the final result is incorrect and caused this issue. So the solution should be simple, we can just add "pointer-events: none" to #player-seek-bar-progress, and the target should be #player-seek-bar only. Evan Tseng is our newbie in Taipei office and I think he already got a patch for this, so it should be a good chance for him to practice how to solve a bug in bugzilla, thanks for pointing this out.
Created attachment 699562 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7410 NOTE: If blocking-basecamp+ is set, just land it for now. [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Testing completed: Risk to taking this patch (and alternatives if risky):
Created attachment 699563 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7410 NOTE: If blocking-basecamp+ is set, just land it for now. [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Testing completed: Risk to taking this patch (and alternatives if risky):
Attachment #699562 - Attachment is obsolete: true
Comment on attachment 699563 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7410 Looks good to me, r+.
Attachment #699563 - Flags: review?(dkuo) → review+
Comment on attachment 699563 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7410 CSS one liner. Sounds safe to me.
Attachment #699563 - Flags: approval-gaia-master?(21) → approval-gaia-master+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.