1154083 - [FMRadio] The Favorite Channel star button becomes stuck on when hitting stop when on a favorite station and then scrolling the dial

Status: RESOLVED WONTFIX

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

Description

[Joshua Mitchell (Inactive)]

Attachment: logcat_20150413_1456.txt

Description:
In the radio app you use the star icon in the upper right to add a station to your favorite station list. When you are currently on a station that has been added to the list then the button shows as a yellow star (this is its active look). When you hit the Stop button while on a favorite radio station and then scroll the dial the favorite button maintains the active appearance even though you scroll through non-favorite stations



Repro Steps:
1) Update a Flame to 20150413010203
2) Launch Radio
3) Find a station with some sweet tunes and hit the favorite button
4) Hit the stop button
5) Scroll the dial left and/or right

Actual:
Favorite station button (gold star) is stuck on


Expected:
Gold Star button will maintain same functionality as when app is not stopped (Grayed out when on a non-favorite station)


Environmental Variables:
Device: Flame 3.0
Build ID: 20150413010203
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 0a46652bd992
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Repro frequency: 9/9
See attached: logcat, video clip: http://youtu.be/fC4JVWxbf4g

Comment 1

[Joshua Mitchell (Inactive)]

This issue also occurs in Flame KK 2.2, 2.1 and 2.0

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150413002502
Gaia: cec00d643f517ffd96cde559cd3bbd43ab85816c
Gecko: 5005522fd68e
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150413001204
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: a1b2434ad001
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Device: Flame 2.0 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150413000202
Gaia: 84898cadf28b1a1fcd03b726cff658de470282f0
Gecko: 5c45a15eb2b4
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Peter Bylenga [:PBylenga]]

NI on component owner for nomination decision and assignment.

Comment 3

[No-Jun Park [:njpark]]

technically the last station 'active' was unchanged when the dial is moved after stopping the radio, so I think this may be according to the spec.  Pinging UX for input.

Comment 4

[Stephany Wilkes]

Flagging Tif on FM radio.

Comment 5

[Tiffanie Shakespeare [:tif]]

I further noticed that tapping the star to get it to un-stick will then favorite the station you were on and scroll to the beginning of the tuner - very strange.

The behaviour for when the stop button has been selected should be the same as when those sweet tunes are still playin' - as tuner scrolls, the star icon deselects.

LMK if you have more questions! Thanks :)

Comment 6

[Joshua Mitchell (Inactive)]

Hi Tiffanie

some of the other behavior you mentioned is covered in bug 935086 (Favoriting a station while FM radio is stopped causes the user to move back to 87.5 )

Comment 7

[Tiffanie Shakespeare [:tif]]

Forgive me but I would argue this is not a polish bug. 

Firstly, the  UI is causing confusion because it's unclear if the station is a favorite or not. While the star icon at the top is highlighted - indicating that it would be a favorite - the station does not appear in the list with other favorite stations. So the UI information is conflicting and inconsistent. 

When the user tries tapping on the star icon to "officially" ensure the station is not a favorite, they end up adding the station to the favorite list. So while this does clear up the inconsistency I pointed out above, we have now created more work and another action the user has to take to rectify the situation.

This bug isn't making things look better or prettier but making the UI work in a consistent and clear manner - i.e. not polish but rectifying a behavioural issue.

Thanks!

NI'ing Steph to see if we can get this fixed sooner than a polish would be.

Comment 8

[No-Jun Park [:njpark]]

(In reply to Tiffanie Shakespeare from comment #7)

Thanks for the comment!  it seems that a bug can be either nomed for blocker, or marked as polish bug to avoid flagging it as a 'stagnant' bug.  (One new criteria we decided today is to include enhancement bugs in that category, but this isn't exactly an 'enhancement' either) Since it's not a regression bug, it wouldn't become a blocking bug, but was wondering what I need to mark it as 'non-blocker bug still a high priority one that people won't avoid for an extended period of time'.  So I decided to mark it as polish and wait for the responses, and glad you made the comment.  

Come to think of it, Hema, is there something that I can mark this bug with that would say 'higher priority than back-burner bugs?'

Comment 9

[Stephany Wilkes]

Right now, I'm not aware of anything against which we can base priority. Hema may know if someone is available to take it, but aside from reiterate higher priority, that's all I can do.

Comment 10

[BMO Automation]

Firefox OS is not being worked on