[FMRadio] The Radio Dial automatically returns to the most recently used frequency setting when panning the dial while the app loads



Firefox OS
3 years ago
3 years ago


(Reporter: Joshua Mitchell (Inactive), Unassigned)


Gonk (Firefox OS)

Firefox Tracking Flags

(tracking-b2g:backlog, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)


(Whiteboard: [3.0-Daily-Testing][polish][priority], URL)


(1 attachment)



3 years ago
Created attachment 8582015 [details]

 When loading the Radio app, the user is able to scroll the radio dial while the app initializes. After the app fully initializes it ignores this user input and sets the dial to the most previous setting from when the app was closed. If it is the first launch it sets it to the far left of the dial (87.5). Users will most likely not wait until the app is fully initialized to start scanning to their favorite frequencies and then their effort is wasted which creates poor UX. 

Repro Steps:
1) Update a Flame to 20150323010204
2) Launch Radio App
3) While app is loading, scroll the radio dial to the right

When the Radio app is done loading, it ignores the current frequency and returns to 87.5

The dial will remain at the point where the user has panned it to
The user will not be able to scroll the dial until the app is fully loaded

Environmental Variables:
Device: Flame Master
Build ID: 20150323010204
Gaia: 9b6f3024e4d0e62dd057231f4b14abe1782932ab
Gecko: e730012260a4
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (Master)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Repro frequency: 7/7
See attached: logcat, Video: http://youtu.be/C2xCUgxGPL0

Comment 1

3 years ago
This issue also occurs on Flame 2.2, 2.1 and 2.0

Device: Flame 2.2 (KK - Nightly - Full Flash - 319mem)
Build ID: 20150323002504
Gaia: 7f367fc98ffdd183f21d2cdfe20556ab877ece34
Gecko: 3ea0eaeda353
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (Master)
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: 20150323001203
Gaia: 13c85d57f49b4bfd657ff674f2b530c141c94803
Gecko: aeabf85a622c
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
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: 20150323000204
Gaia: 896803174633fc6acd3fd105f81c349b8e9b9633
Gecko: 9f233fc1a3d4
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?]
Flags: needinfo?(pbylenga)
NI on component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(npark)
I don't think this is necessarily a blocker, but this does sound quite annoying if the user wants to quickly set the station. 

Although this isn't a regression, I think it's worth it to nominate as blocker. Hema, what do you think?
Flags: needinfo?(npark)
actually, I forgot to ni? Hema above.
Flags: needinfo?(hkoka)

Comment 5

3 years ago
[Tracking Requested - why for this release]:

Agreed that this is not a pleasant experience for the user. It would be nice if app does not ignore the scrolled in channel. 

Marking this a polish priority issue. 

tracking-b2g: --- → backlog
Flags: needinfo?(hkoka)
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][polish][priority]
You need to log in before you can comment on or make changes to this bug.