Created attachment 8591954 [details] 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
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
QA Whiteboard: [QAnalyst-Triage?]
NI on component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(npark)
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.
Flags: needinfo?(npark) → needinfo?(firefoxos-ux-bugzilla)
Flagging Tif on FM radio.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(tshakespeare)
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 :)
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 )
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.
(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?'
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.
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][priority]
Whiteboard: [3.0-Daily-Testing][priority] → [3.0-Daily-Testing][priority] 2.6UXnom
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.