Speaker Mode UI should not be present if device hardware doesn't support speaker mode

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
5 years ago
7 months ago

People

(Reporter: jsmith, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
In bug 947720, we saw a case where turning on speaker mode failed on a particular device. However, the UX provided no feedback to the user that speaker mode failed to turn on. We should make sure that we fire an error if speaker mode fails to turn on.
(Reporter)

Updated

5 years ago
Blocks: 912317
If HW can't support this function, IMHO we may need to disable this button on UI on specific devices.
(Reporter)

Comment 2

5 years ago
(In reply to Randy Lin [:rlin] from comment #1)
> If HW can't support this function, IMHO we may need to disable this button
> on UI on specific devices.

Good point. Actually, that means this is pretty important to do, as testing on Buri already showed that we could have a possibility of vendors not supporting speaker mode on their device. If we don't do this, then device hardware that doesn't support speaker mode will have a broken UI displayed in the FM Radio app.

That makes this worth noming for 1.3.
blocking-b2g: --- → 1.3?
Summary: When turning on speaker mode in the FM Radio app fails, indicate an error to the user → Speaker Mode UI should not be present if device hardware doesn't support speaker mode

Comment 3

5 years ago
Pin since the gaia work for this feature was done by you, can you please take of fixing this UI issue with speaker mode.

Thanks
Hema
Flags: needinfo?(pzhang)
(In reply to Hema Koka [:hema] from comment #3)
> Pin since the gaia work for this feature was done by you, can you please
> take of fixing this UI issue with speaker mode.
> 
> Thanks
> Hema

OK.

Hi Randy, how can we know if the hw supports or not?
Flags: needinfo?(pzhang) → needinfo?(rlin)
Hi Macro, 
Do we have any experience for gaia size to do such customize?
Flags: needinfo?(mchen)

Comment 6

5 years ago
(In reply to Randy Lin [:rlin] from comment #5)
> Hi Macro, 
> Do we have any experience for gaia size to do such customize?

As I know that normally we can do feature detection first then decide whether mozSpeakerManager should be returned or not. Then Gaia can base on the returned object to decide the UI.

But the speaker can be used to convey "FMRadio", "Telephony Voice" and "Any Other Audio".
In buri's case now, only FMRadio didn't work well but other's are ok.

1. In current Web API design, Gaia didn't specify which case (FMRadio or ...) it tried to use.
2. Web API can't report which case is not supported from Gecko.
3. Currently Gonk level didn't export such query to Gecko.

--------------

For third point, the easy way is that vendor noted what capability it can't support via Property System (moz.speaker.fmradio = false). But it still need new change from Web API level to report this.

--------------

Finally I do think this is a vencom issue and ask Buri vendor to support it.
Flags: needinfo?(mchen)
Thanks Macro,
Maybe request partner to have a build script to hide this icon for this kind of customization.
Flags: needinfo?(rlin)
(Reporter)

Comment 8

5 years ago
The vendcom issue is already tracked elsewhere - this bug is dealing with the case when the device does not support speaker mode.
(Reporter)

Comment 9

5 years ago
Marco - Can we safely assume all vendors should be required to support speaker mode for the speaker manager API? Or do we take into account that there could be vendors that could decide to not support speaker mode? That will determine whether we need to pref off the UI or not if speaker mode isn't supported.
Flags: needinfo?(mchen)

Comment 10

5 years ago
(In reply to Jason Smith [:jsmith] from comment #9)
> Marco - Can we safely assume all vendors should be required to support

I think this should be decided by product manager from perspective of FxOS SW/HW spec.

For me, I don't think FxOS should limit such kind of requirement.
So maybe FMRadio app can easily check the settings which is optimized from settings.json to decide the UI of speaker mode. (or Gecko can detect HW features from property system then set values into settings DB.)
Flags: needinfo?(mchen)
(Reporter)

Comment 11

5 years ago
Sri - Can you comment here from the product perspective on whether we need to be ready to handle the case where a FxOS phone we're shipping does not support speaker mode? We're trying to understand if we can enforce speaker mode on all devices or not for the FM Radio.
blocking-b2g: 1.3? → ---
Flags: needinfo?(skasetti)

Comment 12

5 years ago
Yeah, we should definitely support the case where the device doesn't have speaker mode.
We shouldn't be enforcing speaker mode on all devices.
Flags: needinfo?(skasetti)
(Reporter)

Comment 13

5 years ago
Okay - moving back to 1.3? then - sounds like we do need to block on this.
blocking-b2g: --- → 1.3?

Comment 14

5 years ago
CJ/Marco

Since the speaker mode for FMRadio feature was implemented by Pin and Randy for 1.3. Could one of them please get this issue addressed. 

Thanks
Hema
Flags: needinfo?(mchen)
Flags: needinfo?(cku)

Comment 15

5 years ago
Randy, please discuss with marco to provide a mechanism for application to determine the visibility of speaker mode UI.
Flags: needinfo?(cku) → needinfo?(rlin)
Hi Macro,
I think we may add new method called getsupportedtype and it would return the constraints that this API supported. like {telephony, fm, media}?
BTW, How can I get this information about this device has supported speaker on feature?
Flags: needinfo?(rlin)

Comment 17

5 years ago
As I know that device/platform didn't provide such kind of query so the easy way is to define the property in full_hamachi.mk (ex: moz.force_speaker.disabled=fm).
Flags: needinfo?(mchen)
(In reply to Marco Chen [:mchen] [PTO from 2013/12/24 ~ 2014/01/02] from comment #17)
> As I know that device/platform didn't provide such kind of query so the easy
> way is to define the property in full_hamachi.mk (ex:
> moz.force_speaker.disabled=fm).

Maybe we can just simply define a setting, and read it  in fmradio app?
Hi Pin,
Is it a common way to do the customize in gaia side?
Flags: needinfo?(pzhang)
(In reply to Randy Lin [:rlin] from comment #19)
> Hi Pin,
> Is it a common way to do the customize in gaia side?

I'm sorry i don't know either, let's ask Tim, :)

Hi, Tim, what do you think?
Flags: needinfo?(pzhang) → needinfo?(timdream)
Gaia apps can be coded so be responsive to Setting database entries.

However, please consider customize these device capabilities on Android ro, just like bug 952043. Thanks!
Flags: needinfo?(timdream) → needinfo?(mchen)

Comment 22

5 years ago
(In reply to Jason Smith [:jsmith] from comment #13)
> Okay - moving back to 1.3? then - sounds like we do need to block on this.

We need to make sure that there is one of devices shipped with V1.3 don't support FMRadio on speaker or I think we don't need to set it as block
Flags: needinfo?(mchen)

Comment 23

5 years ago
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #21)
> Gaia apps can be coded so be responsive to Setting database entries.
> 
> However, please consider customize these device capabilities on Android ro,
> just like bug 952043. Thanks!

I think let property to show capability is not difficult but we need a new Web API for query this.

Hi Randy,

I am ok for helping update property into full_XXX.mk.
But we still need your help on this new Web API.
(In reply to Marco Chen [:mchen] from comment #22)
> (In reply to Jason Smith [:jsmith] from comment #13)
> > Okay - moving back to 1.3? then - sounds like we do need to block on this.
> 
> We need to make sure that there is one of devices shipped with V1.3 don't
> support FMRadio on speaker or I think we don't need to set it as block

(In reply to Jason Smith [:jsmith] from comment #8)
> The vendcom issue is already tracked elsewhere - this bug is dealing with
> the case when the device does not support speaker mode.

Where is the vendcom being tracked? Can we confirm Buri does not support FM speaker by design?

I don't think Hema would like to track a blocking bug when it doesn't really need to block.
Flags: needinfo?(jsmith)
(Reporter)

Comment 25

5 years ago
It's actually not by design - the Buri guys are working on fixing this in bug 947720.

I guess that makes sense that we don't need to block on this until we hear a vendor requiring this to be implemented.
blocking-b2g: 1.3? → ---
Flags: needinfo?(jsmith)

Comment 26

7 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.