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)
Tracking
(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 fixed, b2g-v2.2 fixed)
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)
30.20 KB,
text/plain
|
Details | |
5.90 KB,
patch
|
gtorodelvalle
:
review+
thills
:
review+
etienne
:
feedback+
fabrice
:
approval-gaia-v2.1+
|
Details | Diff | Splinter Review |
6.91 KB,
patch
|
gtorodelvalle
:
review+
thills
:
review+
|
Details | Diff | Splinter Review |
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)
Keywords: regressionwindow-wanted
Updated•10 years ago
|
QA Contact: jmercado
Comment 3•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: nobody → drs.bugzilla
Target Milestone: --- → 2.1 S8 (7Nov)
Comment 4•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
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
Comment 7•10 years ago
|
||
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
Comment 8•10 years ago
|
||
Can you have a look at this, Tamara?
Flags: needinfo?(tchung) → needinfo?(thills)
Comment 9•10 years ago
|
||
(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)
Assignee | ||
Updated•10 years ago
|
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)
Assignee | ||
Comment 10•10 years ago
|
||
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 11•10 years ago
|
||
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 12•10 years ago
|
||
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 13•10 years ago
|
||
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+
Assignee | ||
Comment 14•10 years ago
|
||
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
Assignee | ||
Comment 15•10 years ago
|
||
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)
Comment 16•10 years ago
|
||
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]
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Keywords: verifyme
Updated•10 years ago
|
Attachment #8520986 -
Flags: approval-gaia-v2.1?(release-mgmt) → approval-gaia-v2.1+
Assignee | ||
Comment 17•10 years ago
|
||
I posted a demo: https://wiki.mozilla.org/FirefoxOS/Comms/Dialer/Sprint/v2.1-S9#Demos
Flags: needinfo?(drs.bugzilla)
v2.1 https://github.com/mozilla-b2g/gaia/commit/afdfa629be209dd53a1b7b6d6c95eab7077ffcd9
Flags: needinfo?(drs.bugzilla)
Comment 19•10 years ago
|
||
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.
Comment 20•10 years ago
|
||
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.
Comment 21•10 years ago
|
||
Reverted for causing test failures (linters and unit tests): https://github.com/mozilla-b2g/gaia/commit/9d3d851b333c8265d260b4aba5a50975512b2025
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•10 years ago
|
Assignee | ||
Comment 22•10 years ago
|
||
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 23•10 years ago
|
||
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+
Comment 24•10 years ago
|
||
Can we update the target milestone to see when we expect to close this bug? Thank you.
Flags: needinfo?(drs.bugzilla)
Comment 25•10 years ago
|
||
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+
Assignee | ||
Comment 26•10 years ago
|
||
v2.1: https://github.com/mozilla-b2g/gaia/commit/5372b675e018b6aac97d95ff5db8d4bd16addb9b
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Flags: needinfo?(drs.bugzilla)
Resolution: --- → FIXED
Target Milestone: 2.1 S9 (21Nov) → 2.2 S1 (5dec)
Comment 27•10 years ago
|
||
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
Comment 28•10 years ago
|
||
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 ago → 10 years ago
QA Whiteboard: [QAnalyst-Triage+][failed-verification][QA-Triage?] → [QA-Triage?]
Updated•10 years ago
|
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.
Description
•