Closed Bug 1093862 Opened 10 years ago Closed 10 years ago

[Dialer]The dialer app will become unresponsive when the user ends a call, quickly presses the conference call button, and then taps the notifications bar that appears immediately after

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 fixed, b2g-v2.2 fixed)

RESOLVED FIXED
2.2 S1 (5dec)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: cnelson, Assigned: drs)

References

()

Details

(Keywords: regression, Whiteboard: [2.1-Exploratory-3][planned-sprint c=1])

Attachments

(3 files)

Attached file log.txt
When the user ends a call, presses the conference call button, and then taps the notification that appears immediately after, the dialer app will become unresponsive.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141104001202
2) Open dialer app, and make a call.
3) End the call, and quickly press the conference call button.
4) Then quickly press the notification that appears at the top of the screen.
5) Notice the dialer app has become unresponsive.
  
Actual:
When the user ends a call, presses the conference call button, and then taps the notification that appears immediately after, the dialer app will become unresponsive.
  
Expected: 
The dialer app should not become unresponsive.
  
Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141104001202
Gaia: 8b0cf889ae0d48a9eb7ecdcb9b67590de45cc5e5
Gecko: 388b03efe92d
Version: 34.0 (2.1)
Firmware: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0"
  
Repro frequency: 100%
See attached: logcat, video clip https://www.youtube.com/watch?v=GRjkKFgoL-Y
Flags: needinfo?(dharris)
This issue does occur on Flame 2.2(319mb)(KitKat)(Shallow Flash).

When the user ends a call, presses the conference call button, and then taps the notification that appears immediately after, the dialer app will become unresponsive.

Flame 2.2

Device: Flame 2.2(319mb)(KitKat)(Shallow Flash)
Build ID: 20141104040207
Gaia: 3c50520982560ccba301474d1ac43706138fc851
Gecko: 54d05732f29b
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

This issue doesn't occur on Flame 2.0(319mb)(KitKat)(Shallow Flash).

The dialer app should not become unresponsive.

Flame 2.0

Device: Flame 2.0(319mb)(KitKat)(Shallow Flash)
BuildID: 20141104000201
Gaia: fe2167fa5314c7e71c143a590914cbf3771905a8
Gecko: 241e51806687
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
[Blocking Requested - why for this release]:

This seems like an edge case bug, but due to the impact of the bug I am nominating this to block 2.1. The user will see a blank white notification on the homescreen if they return home with this bug occuring, as well as an icon in the notification screen saying that the user is in the call.
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
QA Contact: jmercado
I left that comment in bug 1093896, yesterday but actually I meant to write it here. 

I can easily repro if I shallow flash gecko and gaia on top of v188, but I can't if I do a full flash. Both are exactly the same build: 
Gaia-Rev        57b111ff404345006e13e576ddeb498edc21dd5d
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/c98b64ef4148
Build-ID        20141104161202
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880

Craig, can you check if you're able to repro with a full flash too?

Tony, if this issue only occurs on a shallow flash, shoud we block on it?
Flags: needinfo?(tchung)
Flags: needinfo?(cnelson)
Assignee: nobody → drs.bugzilla
Target Milestone: --- → 2.1 S8 (7Nov)
This blocks the user from using the phone so triage decided that we should try to get it fixed.
blocking-b2g: 2.1? → 2.1+
This issue is reproducible on Flame full flash.  This test was completed on Flame 2.1.

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141106001204
Gaia: 9658b93b412bdcc0f953d668e8c8e68318c99fb8
Gecko: 76880403db44
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Flags: needinfo?(cnelson)
Cause: Bug 1068109 seems to have caused this issue.

B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141006080822
Gaia: fdd378e53445bcec7145111cfe0e2d163ae29872
Gecko: 0c22e43c9e77
Version: 35.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20141006082726
Gaia: cfe5165889a5e07779fe73aaa7d9d1b08b2845fe
Gecko: 60af78c644e2
Version: 35.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: fdd378e53445bcec7145111cfe0e2d163ae29872
Gecko: 60af78c644e2

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: cfe5165889a5e07779fe73aaa7d9d1b08b2845fe
Gecko: 0c22e43c9e77

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/fdd378e53445bcec7145111cfe0e2d163ae29872...cfe5165889a5e07779fe73aaa7d9d1b08b2845fe
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by Bug 1068109; bug already assigned, not NIing patch author
Blocks: 1068109
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: jmercado
Can you have a look at this, Tamara?
Flags: needinfo?(tchung) → needinfo?(thills)
(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #8)
> Can you have a look at this, Tamara?

Hi Johan, I think Doug is taking this one.
Flags: needinfo?(thills)
Status: NEW → ASSIGNED
Whiteboard: [2.1-Exploratory-3] → [2.1-Exploratory-3][planned-sprint c=1]
Target Milestone: 2.1 S8 (7Nov) → 2.1 S9 (21Nov)
PR: https://github.com/mozilla-b2g/gaia/pull/26046

Etienne, does this seem fundamentally ok to you? It seems like it's nice to have this anyways since the UI should not be responding to user interaction when there are no handled calls. I'd just like to know if you think I'm missing something here.
Attachment #8520986 - Flags: review?(thills)
Attachment #8520986 - Flags: review?(gtorodelvalle)
Attachment #8520986 - Flags: feedback?(etienne)
Comment on attachment 8520986 [details] [diff] [review]
Make Callscreen not respond to user input while there are no currently handled calls.

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

Looks good to me.
Might be worth it to file a follow up to gray out the buttons when the class is set.
Attachment #8520986 - Flags: feedback?(etienne) → feedback+
Comment on attachment 8520986 [details] [diff] [review]
Make Callscreen not respond to user input while there are no currently handled calls.

I was thinking about the possibility to expand this behaviour to the case when the call screen is minimised (https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/style/oncall_status_bar.css) but since there are no actionable elements in this case (at least for now), I think we are good to go. On the other hand, it may do no harm so I leave it to you :)

BTW, testing the patch I did found bug 1097772 which is kind of "related" to this one ;)
Attachment #8520986 - Flags: review?(gtorodelvalle) → review+
Comment on attachment 8520986 [details] [diff] [review]
Make Callscreen not respond to user input while there are no currently handled calls.

Hi Doug,

It looks good to me.  I tested out as well.

Thanks,

-tamara
Attachment #8520986 - Flags: review?(thills) → review+
https://github.com/mozilla-b2g/gaia/commit/0e6c2571d5368032c9ee11a033b261a4343e9c06

Needinfo to record a demo and request uplift.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: needinfo?(drs.bugzilla)
Resolution: --- → FIXED
Comment on attachment 8520986 [details] [diff] [review]
Make Callscreen not respond to user input while there are no currently handled calls.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 1068109
[User impact] if declined: Callscreen can become unresponsive once calls end if the user continues pressing buttons.
[Testing completed]: Germán, Tamara, and I tested this. It's also been sitting on master for a while.
[Risk to taking this patch] (and alternatives if risky): Low.
[String changes made]: None.
Attachment #8520986 - Flags: approval-gaia-v2.1?(release-mgmt)
The issue still reproduces on 2.2 Flame build

The calling icons on the  dialer screen become unresponsive

"Flame 2.2

Environmental Variables:
Device: Flame 2.2
Build ID: 20141117040203
Gaia: ddf5b92f43ec27c93ad4fea4fd1207da8936b8e7
Gecko: 21b745197618
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0"
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][failed-verification]
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Keywords: verifyme
Blocks: 1100552
Attachment #8520986 - Flags: approval-gaia-v2.1?(release-mgmt) → approval-gaia-v2.1+
I posted a demo:
https://wiki.mozilla.org/FirefoxOS/Comms/Dialer/Sprint/v2.1-S9#Demos
Flags: needinfo?(drs.bugzilla)
Depends on: 1103697
I've found on v2.1 linter now is permanent red because this patch introduced some diffs that *without* checking any Gaia-Try result from master. The reason is the function:

   function exitCallScreenIfNoCalls(timeout) {
     //...
+      }, timeout);
   };

On master the `timeout` is an valid argument so this is a good patch. But on v2.1, the same function is without the argument:

   function exitCallScreenIfNoCalls() {
     //...
+      }, timeout);

And the linter complains this immediately. The more important is this error cause the patch not work, since you're expecting a in-existing variable in this function, and I think the only reason it looks good on v2.1 is because setTimeout allow undefined as the last argument, so it seems good although it's actually broken.

I've tried to revert this patch on my local v2.1, and this time the linter keep silent. So it pointed out the patch on v2.1 is the root cause.

This definitely should not happen, and if you don't land master patch directly into v2.1 this can be avoided, since you would get two different Gaia-Try results. Things become worse because this is the second time I saw a patch directly landed from PR for master broken the v2.1 and nobody care about that (the previous one caused v2.1 CI red for even a week, and I'm the first and maybe the only person discovered that), and they even all come with approvals! I've asked why we allow this thing happen at the first bug, but obviously I'm only an untitled developer needs guides so nobody answered me.
Hi Doug:

I think the patch you merged to v2.1 caused an issue: we cannot click on any button on the callscreen during a call. We cannot click the endCall button to end an outgoing call, and even we cannot click the answer button to answer the incoming call. 

And there is one log :
"11-24 06:35:33.040 E/GeckoConsole(  108): [JavaScript Error: "ReferenceError: timeout is not defined" {file: "app://callscreen.gaiamobile.org/gaia_build_defer_index.js" line: 212}]" 
shows the timeout you used here is undefined. 

Please help check this on v2.1 branch. Thank you.
Reverted for causing test failures (linters and unit tests): https://github.com/mozilla-b2g/gaia/commit/9d3d851b333c8265d260b4aba5a50975512b2025
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
PR: https://github.com/mozilla-b2g/gaia/pull/26430

Thanks everyone, and sorry for the problems on v2.1. The issue was actually not caused by the timeout mistake, but my oversight in not checking it on v2.1 and discovering that the fix in bug 1081811 was making this work on master. Though I'm sure that the timeout mistake played into it as well.

The telephony API's 'callschanged' event was being fired right when the listener was attached, and `handledCalls` was `0`. This lead to disabling the buttons as soon as the Callscreen app was displayed. This didn't happen on master because the 'callschanged' event is only fired when the calls actually change, not when the listener is attached. This patch and the PR include a fix for this, where we check if there were ever any handled calls before setting the `exitCallScreenTimeout` timer.
Flags: needinfo?(drs.bugzilla)
Attachment #8528105 - Flags: review?(thills)
Attachment #8528105 - Flags: review?(gtorodelvalle)
Comment on attachment 8528105 [details] [diff] [review]
(v2.1) Make Callscreen not respond to user input while there are no currently handled calls.

Hi Doug,

It looks good to me.  I also tested out some different scenarios and works well and all the tests passed.

Thanks,

-tamara
Attachment #8528105 - Flags: review?(thills) → review+
Can we update the target milestone to see when we expect to close this bug? Thank you.
Flags: needinfo?(drs.bugzilla)
Comment on attachment 8528105 [details] [diff] [review]
(v2.1) Make Callscreen not respond to user input while there are no currently handled calls.

Sorry guys! I had some issues generating a v2.1 build :)

Working fine, tests passing and looking good, so r+ ;)

Thanks Doug!
Attachment #8528105 - Flags: review?(gtorodelvalle) → review+
v2.1: https://github.com/mozilla-b2g/gaia/commit/5372b675e018b6aac97d95ff5db8d4bd16addb9b
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Flags: needinfo?(drs.bugzilla)
Resolution: --- → FIXED
Target Milestone: 2.1 S9 (21Nov) → 2.2 S1 (5dec)
This issue no longer occurs on Flame 2.2 or 2.1.

Actual Result: Calling a contact and then pressing the end call button followed by the conference call button no longer disables the dialer app.

Device: Flame 2.2  (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141126040207
Gaia: 41b7be7c67167f367c3c4982ff08651d55455373
Gecko: 7bcc6573d204
Version: 36.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

- - - - - - - - - - 

Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141126001202
Gaia: db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko: 211eae88f119
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage+][failed-verification][QA-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
Please disregard comment 27- this issue still occurs on 2.2 and 2.1. However, the repro rate has dropped from 100% to about 10% on both 2.1 and 2.2. Additionally this issue sometimes occurs on incoming calls with an 70% repro rate on both 2.1 and 2.2.

- - - - - - - - - - 

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141201040205
Gaia: 39214fb22c203e8849aaa1c27b773eeb73212921
Gecko: 08be3008650f
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (Unknown)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

- - - - - - - - - 

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141201001201
Gaia: ccb49abe412c978a4045f0c75abff534372716c4
Gecko: 18fb67530b22
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: VERIFIED → RESOLVED
Closed: 10 years ago10 years ago
QA Whiteboard: [QAnalyst-Triage+][failed-verification][QA-Triage?] → [QA-Triage?]
QA Whiteboard: [QA-Triage?] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: