Closed Bug 1113881 Opened 7 years ago Closed 7 years ago
[Music][Song View] Player can reach a state of perpetual fastforward/rewind/play-pause
89.48 KB, text/plain
46 bytes, text/x-github-pull-request
|Details | Review|
46 bytes, text/x-github-pull-request
|Details | Review|
4.09 MB, video/mp4
3.13 MB, video/mp4
Summary (title) Field: [Music][Song View] Player can reach a state of perpetual fastforward/rewind/play-pause Description: When performing multiple hold taps on the user play-control buttons [play-pause/fastforward/rewind], the Music app can reach a state where the song is constantly fast forward, constantly rewinding (essentially staying at 0:00 with the first tick of music playing repeatedly). A state was also seen where the song was constantly ticking between play and pause, causing the song to play extremely slowly as it is only able to play a fraction of a second every second: the time does slowly progress though. The most common (and demonstrated in the video) results from these steps is breaking the ability to pause while in a song. Song is always playing and cannot pause. Repro Steps: 1) Update a Flame device to BuildID: 20141219040202 2) Open the 'Music' app. 3) Begin playing a song. 4) Hold tap on the 'Play' button. Observe highlighted button. 5) Hold tap on the 'Fastforward' button. 6) Hold tap on the 'Rewind button'. 7) Repeat steps 4, 5 and 6 continously. Actual: Music playing breaks and constantly rewinds, fastforwards or trying to play when paused or pause when playing breaks. Requires restart of app to fix. Expected: Music plays normally according to button presses. Environmental Variables: Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash) BuildID: 20141219040202 Gaia: deb90229734e5397cda806fb11f2e001fba83399 Gecko: 021b09e92d30 Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442 Version: 37.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Repro frequency: 4/8 See attached: video- http://youtu.be/kybP2sqflQ8 [demonstrates pause button not working] logcat
QA Whiteboard: [QAnalyst-Triage?]
From the youtube video, I only see the play-pause button was unable to pause the music player, but didn't enter a perpetual fastforward/rewind state.
Demonstration of fast forward being held. After leaving the song focus, it appears to have resolved itself. http://youtu.be/vyfUdEDHyQU
qawanted for branch checks.
QA Whiteboard: [QAnalyst-Triage?]
I was able to reproduce the pause button not working issue (though it fixes itself on the next song), but NOT the perpetual fastforwarding/rewinding issue on Flame 2.1. Device: Flame 2.1 (shallow flash 319MB) BuildID: 20141222071650 Gaia: 1a58335917b23c170d85bf821f658e964c935b23 Gecko: 5509822354a9 Version: 34.0 (2.1) Firmware: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ----- This issue does NOT reproduce at all on Flame 2.0. Play/Pause button, Fastforward button, and Rewind button all work as expected regardless of how I tap hold or tap on them. Device: Flame 2.0 (shallow flash 319MB) BuildID: 20141222071429 Gaia: ce83ea7b8e3fa2d1c3fd771fc22b654c18b3c381 Gecko: 7d0adaf6c447 Version: 32.0 (2.0) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ------- Marking 2.1 as affected even though only 1/3 of the bug reproduces on the branch.
NI Music owner for blocking decision / assignment
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(npark)
[Blocking Requested - why for this release]: Blocking since it is relatively easy to reproduce (by holding the button icons)
blocking-b2g: --- → 2.1?
dominic/hema, Do you need any additional QA help to move forward here ? I need your input in blocking a blocking decision here because i tried reproducing and seeing the impact but was unsuccessful. But when I read the description if the user ends up hitting this bug, he may have to restart the app, which isn't that pretty :-/
Jim or Dominic, Please take a look at the "Non-functional Pause button issue". From the comments it looks like the other issue of perpetual fast forward is not easily reproducible. THanks Hema
Assignee: nobody → squibblyflabbetydoo
I think this might be a hard to reproduce race condition. Would it be possible to get some ideas in what race conditions might cause something like this so QA can reproduce this better?
Ok, this patch does two things: 1) It ensures that we update our internal state correctly when we stop seeking. I think there was a Gecko change that caused us to no longer see the "play" event after we stopped seeking, so `playStatus` was always FWD_SEEK (or REV_SEEK). Now, we handle that ourselves. 2) It changes the play/pause button so that it plays or pauses based on what the button looks like, not what the playStatus is. That way, if we ever get into an inconsistent state again, tapping the play/pause button will still do what you'd expect. With this change, a bug like what I fixed in part 1 couldn't cause any problems. I didn't write any tests, since this is kind of hard to reproduce programmatically. I could try to write some if we think this is really important to test, but I'm not sure of the best way to trigger it consistently. I can usually trigger the bug by rewinding while playing, but not always. This might be the sort of thing that just needs a manual test.
Attachment #8552606 - Flags: review?(dkuo)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #9) > I think this might be a hard to reproduce race condition. Would it be > possible to get some ideas in what race conditions might cause something > like this so QA can reproduce this better? You should be able to reproduce it fairly consistently if you rewind while a song is playing, but I think you need to 1) rewind for a second or more, and 2) make sure you're not rewinding all the way to the beginning of the song. That's what I did, and it seemed to cause the bug most of the time.
Decided to put it to 2.1.
blocking-b2g: 2.1? → 2.1+
Comment on attachment 8552606 [details] [review] Fix it Jim, thanks for working on this issue and the patch looks good to me, though I was unable to reproduce it but those changes make sense to me, also it should fixes some other potential bugs if gecko has more changes on the timings of the media events.
Attachment #8552606 - Flags: review?(dkuo) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S5 (6feb)
Please request Gaia v2.1 and v2.2 approval on this when you get a chance.
David, this has been waiting on approval requests for ~2 weeks now. Can you please help?
I have to rewrite the patch for 2.1, and I haven't had a chance to do that yet. I'll do it today or tomorrow.
Comment on attachment 8552606 [details] [review] Fix it [Approval Request Comment] [Bug caused by] (feature/regressing bug #): Whatever it regressed from, it's pretty old. Probably when we enabled seeking by holding the fast-forward/rewind buttons. [User impact] if declined: See bug title [Testing completed]: Manually tested against master [Risk to taking this patch] (and alternatives if risky): Low-risk; this just fixes the bug and hardens some logic to make it easier for users to escape similar bugs, if any exist. [String changes made]: None
Attachment #8552606 - Flags: approval-gaia-v2.2?
Comment on attachment 8565745 [details] [review] [gaia] jimporter:bug-1113881 > mozilla-b2g:v2.1 See previous comment. This is just the 2.1 port of the above patch.
Attachment #8565745 - Flags: approval-gaia-v2.1?
Attachment #8552606 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Comment on attachment 8565745 [details] [review] [gaia] jimporter:bug-1113881 > mozilla-b2g:v2.1 Requesting QA verification on branches.
Attachment #8565745 - Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
This problem is verified pass on latest build of Flame2.1/Flame2.2/Flame3.0 (men: 319MB) See attachments: Verify_Video.MP4 Rate: 0/5 Flame 2.1 build: Build ID 20150225001618 Gaia Revision 86af0ca427adad12c3109124f31bef2fd9614e47 Gaia Date 2015-02-24 02:22:26 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/a275f2c05ca6 Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150225.034947 Firmware Date Wed Feb 25 03:49:58 EST 2015 Bootloader L1TC000118D0 Flame 2.2 build: Build ID 20150225002505 Gaia Revision ca64f2fe145909f31af266b1730874051ba76c78 Gaia Date 2015-02-24 22:06:53 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/16804008c29f Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150225.041814 Firmware Date Wed Feb 25 04:18:25 EST 2015 Bootloader L1TC000118D0 Flame 3.0 build: Build ID 20150225010244 Gaia Revision f6bfd854fe4746f21bc006eac145365e85f98808 Gaia Date 2015-02-24 21:10:44 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/0a8b3b67715a Gecko Version 39.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150225.043702 Firmware Date Wed Feb 25 04:37:14 EST 2015 Bootloader L1TC000118D0
This problem is verified pass on latest build of 2.1S (men: 319MB) See attachments: Verify_Video2.MP4 Rate: 0/5 2.1S build: Build ID 20150226161204 Gaia Revision a43d64ae01ef108aa4dcc971c770fecd8416a764 Gaia Date 2015-02-26 09:24:39 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2437280c634f Gecko Version 34.0 Device Name scx15_sp7715ga Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150226.193307 Firmware Date Thu Feb 26 19:33:19 EST 2015
You need to log in before you can comment on or make changes to this bug.