951972 - [fugu][buri][music] cannot change progress bar after long tapping on "Random Play" icon

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Music, defect)

Description

[Peipei Cheng (needinfo if you need my action)]

Attachment: STR.3gp

This can be reproduced on both V1.2 and V1.3.

STR:
1. prepare several music in SD card
2. Launch Music and select one song to play
3. On the music play page, long tap on the "Random Play" icon
4. Try to change the progress on the process bar
   --> You will notice the process cannot be changed for the first time.

Please see attached video for STR details.

v1.2 buri
Gaia      4f53ba8b3628ac311253fc28dfdf66e7ba6832de                         
Gecko                                                                      
http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/129ad3c335a5         
BuildID   20131217004001                                                   
Version   26.0                                                             
ro.build.version.incremental=eng.archermind.20131114.105818     

v1.3 buri
Gaia      358cd74fd2b2ef5d541f71a5d53d65d6a7335424                         
Gecko     http://hg.mozilla.org/mozilla-central/rev/f67feb33a974           
BuildID   20131216040201                                                   
Version   29.0a1                                                           
ro.build.version.incremental=eng.archermind.20131114.105818

Comment 1

[Hema Koka [:hema]]

Jim: please take a look at this.

Comment 2

[Jim Porter (:squib)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/15271

The issue was that we were setting isContextmenu to true when long pressing on things, and it wasn't getting cleared out properly. Since we only used isContextmenu to check when the user is long pressing on the next/previous buttons (so they can fast-forward), I've changed the variable to be called isFastSeeking and fixed the handling for it.

Comment 3

[Hema Koka [:hema]]

Not a blocker for 1.3 (not a regression issue) but if the patch is r+ and seems relatively simple fix, we can look into approving for landing

Comment 4

[Preeti Raghunath(:Preeti)]

Comment on attachment 8349828 [details]
STR.3gp

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:

Comment 5

[Dominic Kuo [:dkuo]]

Comment on attachment 8359401 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/15271

Jim,

The patch looks great! and I have tested it with fingers and AVRCP headset, both works fine as before the patch applied, thanks for working on this.

Comment 6

[Jim Porter (:squib)]

Landed: https://github.com/mozilla-b2g/gaia/commit/8d18b1e2fd06c84a879f99f6e8ca1f104eeacb13

Comment 7

[Andrew Overholt [:overholt]]

(In reply to Hema Koka [:hema] from comment #3)
> Not a blocker for 1.3 (not a regression issue) but if the patch is r+ and
> seems relatively simple fix, we can look into approving for landing

blocking- but uplift approval will be dealt with separately.

Comment 8

[Jim Porter (:squib)]

What's the needinfo for? Should I land this on 1.3 myself, or does that still happen automatically?

Comment 9

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 8d18b1e2fd06c84a879f99f6e8ca1f104eeacb13 to:
v1.3: d30994c8a64cfcc0306c2a4e04dfe53580d9183b