Closed Bug 836424 Opened 11 years ago Closed 11 years ago

On inserting wired headset call is getting disconnected

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-, b2g18 affected, b2g18-v1.0.1 affected)

RESOLVED WORKSFORME
blocking-b2g -
Tracking Status
b2g18 --- affected
b2g18-v1.0.1 --- affected

People

(Reporter: anshulj, Unassigned)

References

Details

Attachments

(1 file)

While in a call, inserting a wired headset is disconnecting the call. Steps to reproduce.

1. Make a call
2. When the call is connected, insert a wired headset

Observed behavior
I see in the status bar the icon for the wired headset and then I see that call is getting disconnected.

From the logs I see receiving RIL:Hangup request from the content process.

I added debug messages to the oncall.js method handleHSCommand and I see that when I insert the headset the message received is "headset-button-press" and therefore this fix isn't resolving the issue. 

I am not sure why when I tried the patch last time on the same hardware and with the same wired headset the patch did work. The wired headset I am using has two rings (TRS) on it.
It seems like bug 831396 didn't fix this.
Assignee: nobody → francisco.jordano
blocking-b2g: tef? → tef+
Hi,

I've tested this with 5 kind of different headset (2, 3 rings), but I'm not able to reproduce it.

Again, I don't think this is a Gaia issue, I think is a platform issue, as the backend is sending us the 'headset-button-press' when obviously it's not.

Anyway I'll try another approach that I wold like someone that has this problem check. Basically will check first if we have a headphones connected, maybe this doesn't help at all, but is the last thing we can do at Gaia level.
Anshul the current patch is a 'hack' to detect that the headphones are already plugged (using the mozfm api lol).

If this doesn't fix the problem you are commenting, I suggest we cannot fix this in gaia, we will need to fix this at gecko level.

Cheers!
Attachment #710270 - Flags: feedback?(anshulj)
(In reply to Francisco Jordano [:arcturus] from comment #3)
> Created attachment 710270 [details]
> WIP - Trying to detect that the headphones are connected before cancelling a
> call cause 'headset button pressed'
> 
> Anshul the current patch is a 'hack' to detect that the headphones are
> already plugged (using the mozfm api lol).
> 
> If this doesn't fix the problem you are commenting, I suggest we cannot fix
> this in gaia, we will need to fix this at gecko level.
> 
> Cheers!

I think you will need radio permission to use this hack. Also, we would really love the hack to be removed soon, so please file a bug for that once this lands.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #4)
> (In reply to Francisco Jordano [:arcturus] from comment #3)
> > Created attachment 710270 [details]
> > WIP - Trying to detect that the headphones are connected before cancelling a
> > call cause 'headset button pressed'
> > 
> > Anshul the current patch is a 'hack' to detect that the headphones are
> > already plugged (using the mozfm api lol).
> > 
> > If this doesn't fix the problem you are commenting, I suggest we cannot fix
> > this in gaia, we will need to fix this at gecko level.
> > 
> > Cheers!
> 
> I think you will need radio permission to use this hack. Also, we would
> really love the hack to be removed soon, so please file a bug for that once
> this lands.

Hi Tim!

Yes, I'm adding the fmradio permissions to the communications manifest.

I would like Anshul to try this patch and see if it solves the problem :)

Thanks!
Francisco, the patch didn't work as expected. I was getting a JS error that mozFMRadio isn't available. I then added the following line in OnCall.js and got past that error. 

var mozFMRadio = window.navigator.mozFMRadio;

My use case is that I connect the wired headset when a call is already connected and I see a hangup event. When I print the value of mozFMRadio.antennaAvailable it prints true and so this patch doesn't resolve the issue.
Francisco, what's next for this bug?
Flags: needinfo?(francisco.jordano)
(In reply to Anshul from comment #6)
> Francisco, the patch didn't work as expected. I was getting a JS error that
> mozFMRadio isn't available. I then added the following line in OnCall.js and
> got past that error. 
> 
> var mozFMRadio = window.navigator.mozFMRadio;
> 
> My use case is that I connect the wired headset when a call is already
> connected and I see a hangup event. When I print the value of
> mozFMRadio.antennaAvailable it prints true and so this patch doesn't resolve
> the issue.

Hi Ansul, thanks for trying with the correct |window.navigator.mozFMRadio| unfortunately if this hack doesn't work, there is not much we can do from Gaia.

Cause basically gaia is finishing the call cause we are receiving an event of end call button pressed with your headset.

We will need someone input from the guys on the backend.

As well would like to know if this problem is happening with several headset or just with a single one, so far, I tried with 6 different headset and didn't have this behavior.

Reassigning back to platform since we cannot do anything else in gaia.
Flags: needinfo?(francisco.jordano)
Assignee: francisco.jordano → nobody
Component: Gaia → General
Andrew, please, could you assign someone ?
Flags: needinfo?(overholt)
I cannot reproduce this problem and neither can Andrea Marchesini.  I tried on my Unagi with a North American TRS headset.

Anshul, can you think of anything specific about your setup that could be causing this?  Is it only with one headset?
Flags: needinfo?(overholt) → needinfo?(anshulj)
I am trying to test on different hardwares with different headsets. Will update the results soon.
Flags: needinfo?(anshulj)
Kicking out of blockers, re-nom if this is ever reproduced.
blocking-b2g: tef+ → -
This issue is not reproducing on Unagi
Build ID: 20130215070202
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/a9e4f8912607
Gaia   21ba59d933c66024cb351c2379315301d5352e0c
Kernal: Dec5th

Note: Insted of reopening 831396, New bug was opened :836424. so, changing status of both the bug to verified
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Attachment #710270 - Flags: feedback?(anshulj) → feedback-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: