856546 - [Buri][Beetle lite FF]The music not pause when call incoming

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Music, defect, P2)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.044
  Firefox os  v1.0.1
  Mozilla build ID: 20130319070203
 +++ This bug was initially created as a clone of Bug #432494 +++
 
 DEFECT DESCRIPTION:
 The music not pause when call incoming
 REPRODUCING PROCEDURES:
 1.Select a music to playing
 2.Make a incoming call when music playing，the music always playing，can't hear the ringtone-K.O
 3.Answer the call，music playing background--K.O
 
 EXPECTED BEHAVIOUR:
 The music should be pause when call incoming
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:
 5/5
 For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #432494 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Daniel Coloma:dcoloma]

Need to block on this one, please note that this does not happen when you are listening to music through the headset.

Copying Jonas and Lucas as they may know who is best to have a look at this.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This sounds like an issue for Marco and/or Andrea.

What *should* happen here is that we should switch to the dialer app when the call comes in. As soon as we are in the dialer app and are using a higher-privileged channel, such as "ringer" or "telephony" the background music should be muted.

Comment 3

[Daniel Coloma:dcoloma]

(In reply to Jonas Sicking (:sicking) from comment #2)
> This sounds like an issue for Marco and/or Andrea.
> 
> What *should* happen here is that we should switch to the dialer app when
> the call comes in. As soon as we are in the dialer app and are using a
> higher-privileged channel, such as "ringer" or "telephony" the background
> music should be muted.

This is exactly the behaviour when the headset is plugged-in. We just need to do it also when music is being played without headsets.

Comment 4

[Marco Chen [:mchen]]

I suspected that this is caused by the regression of hacking mozvisibility event. When music app is starting to play music, system app doesn't send visibility change to music app. So it will not be paused by audio channel. 

Since it is fixed by bug 853454, will check it with daily build.

Comment 5

[Marco Chen [:mchen]]

I tested it on the b2g18-v1.0.1 and gaia version today and this issue is not happened. So set flag for qawanted to verify this issue.

Comment 6

[Al Tsai [:atsai]]

I tested on my Unagi phone w/ nightly v1.0.1 build and was able to reproduce.

Build info:
gaia@git: 630fdb0e9617d59ff65c649ad68d0c4735db6bc7
gecko@hg: ccec751a468e

Comment 7

[Marco Chen [:mchen]]

After discussing with Andrea, I take this bug.

Comment 8

[Marco Chen [:mchen]]

(In reply to Al Tsai [:atsai] from comment #6)
> I tested on my Unagi phone w/ nightly v1.0.1 build and was able to reproduce.
> 
> Build info:
> gaia@git: 630fdb0e9617d59ff65c649ad68d0c4735db6bc7
> gecko@hg: ccec751a468e

Yes, Al is right. I tested it on headset pluggin not on speaker. And it will happen on case of speaker. Will investigat it.

Comment 9

[Marco Chen [:mchen]]

Attachment: Gaia Patch v1

When window_manager listened event of attentionscreenshow, it will set a timer then set visibility change. And this timer will be canceled if another event coming before timeout. The issue is happened when mozChromeEvent is added into handler. Because mozChromeEvent should not cancel that timer.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 732263 [details] [diff] [review]
Gaia Patch v1

Review of attachment 732263 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, thanks.

Comment 11

[Marco Chen [:mchen]]

Url of pull request.

https://github.com/mozilla-b2g/gaia/pull/9037

Comment 13

[Daniel Coloma:dcoloma]

What is preventing us for landing this?

Comment 14

[Marco Chen [:mchen]]

(In reply to Daniel Coloma:dcoloma from comment #13)
> What is preventing us for landing this?

Sorry, I don't get your point. Could you explain more?

By the way, the pull_request is merged into gaia-master already and is waiting to be uplifted. Thanks.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

We could close this once it's merged to master already.

Comment 16

[Daniel Coloma:dcoloma]

(In reply to Marco Chen [:mchen] from comment #14)
> (In reply to Daniel Coloma:dcoloma from comment #13)
> > What is preventing us for landing this?
> 
> Sorry, I don't get your point. Could you explain more?
> 
> By the way, the pull_request is merged into gaia-master already and is
> waiting to be uplifted. Thanks.

The point was that is was not marked as FIXED and hence it was not under sheriffs radar for being uplifted. Would you be so kind to include the commit link so sheriff can uplift it easier?

Thanks!

Comment 17

[Marco Chen [:mchen]]

Oh, very thanks for reminding. Alive already help to mark as fixed.

The merged link is as below.

https://github.com/mozilla-b2g/gaia/pull/9037

Comment 18

[Daniel Coloma:dcoloma]

Landed in master:

https://github.com/mozilla-b2g/gaia/commit/8a063da1d7ca489238b6c0d926e1d62bd5a018e7

Comment 20

[Jeni]

Verfied fixed on Master Build

Updated to Unagi Build ID: 20130410065939
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/mozilla-central/rev/ee5ca214e87c
Gaia: f6587418cc5fd8dfe885539ae1a798473890c7f5

But not fixed on 

Unagi Build ID: 20130410070209
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/423f7851bdb5
Gaia: c614b3f3c956dc1e1adf93cf4cf41511ce75de80

and on

Unagi Build ID: 20130410070204
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/935ff9a97f7b
Gaia: aff876b051c51d091cecf322b90c4f0093281b5e 

Music does not play while you answer a call on Master Build.

Comment 21

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted commit 8a063da1d7ca489238b6c0d926e1d62bd5a018e7 as:
v1-train: 96a1538aa23da7c2a4ca69deea19054912c45d42
v1.0.1: 09bc5db946e002a8d8ccfa49773afb1ceef8da7a

Comment 22

[Jeni]

Verified fixed on 

Unagi Build ID: 20130411070205
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/f83d169babee
Gaia: 81cab0e96c0064b03db46a5248047fed617c2f26

and on 

Unagi Build ID: 20130411070205
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/f671fa539473
Gaia: e7e338a765e22334b40ced41489a785941382c66

when user receives and answers a phone call music is paused until call is ended.

Comment 24

[Leo]

This causes a regression. It displays a white empty screen shortly on incoming call when the currently displayed app is anything other than homescreen, browser, dialer.

Steps to repro:
1. Open Clock app on 1st phone.
2. Use 2nd phone to call 1st phone.
3. Observe 1st phone and it will display a white empty screen shortly before displaying the incoming call screen.

Debugging Info:
I have put some logs as follows.

    function overlayEventHandler(evt) {
    console.log('wwwww overlayEventHandler 1, evt.type=' + evt.type);
    if (attentionScreenTimer && 'mozChromeEvent' != evt.type) {
      clearTimeout(attentionScreenTimer);
      console.log('wwwww overlayEventHandler 2, evt.type=' + evt.type);
    }

and it gives the following log when I repro.

05-13 09:02:22.399: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=mozChromeEvent
05-13 09:02:22.519: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=attentionscreenshow
05-13 09:02:22.519: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1680 in overlayEventHandler: wwwww overlayEventHandler 2, evt.type=attentionscreenshow
05-13 09:02:23.279: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=mozChromeEvent
05-13 09:02:23.279: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=mozChromeEvent
05-13 09:02:25.109: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=mozChromeEvent
05-13 09:02:25.109: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=mozChromeEvent
05-13 09:02:25.109: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=mozChromeEvent
05-13 09:02:25.679: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1677 in overlayEventHandler: wwwww overlayEventHandler 1, evt.type=attentionscreenhide
05-13 09:02:25.679: E/GeckoConsole(3432): Content JS LOG at app://system.gaiamobile.org/js/window_manager.js:1680 in overlayEventHandler: wwwww overlayEventHandler 2, evt.type=attentionscreenhide

Any idea?

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

White screen sounds the timer doesn't set.
Anyway, file another bug for that.

Comment 26

[(inactive after 6/18) Alive Kuo [:alive]]

After investigation, comment 24 is a regression from bug 845661.

Comment 27

[Leo]

(In reply to Alive Kuo [:alive] from comment #26)
> After investigation, comment 24 is a regression from bug 845661.

Ops, let me update a comment in the new bug I just created.
Thanks.