1103697 - Unable to answer calls, hang up, use dial-pad during call, etc. (in-call screen & incoming/outgoing call screens are not responsive)

Status: VERIFIED FIXED

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

Description

[Daniel Holbert [:dholbert]]

Ever since Saturday morning (when I installed an OTA nightly update, on the FxOS 2.1 channel), my Flame's incoming/outgoing/in-call screens have all been completely unresponsive to touches.

So, specifically, this means:
 - I cannot answer incoming calls.
 - I *can* place calls, BUT I can't hang up, after I've placed a call (the hang-up button is unresponsive), and I can't bring up a dial-pad, toggle speakerphone, etc. when I'm in a call that I placed.


Moreover, the incoming-call / in-a-call screen stays around forever (even if the person on the other end hangs up. This means I'm unable to place an additional call until I reboot my phone.

(So: my phone calls this weekend have mostly gone like this: (1) someone calls me, and I'm unable to answer. (2) I try in vain to call them back. (3) I reboot my phone. (4) I call them back. (5) after they hang up, the in-call-screen sticks around, with a non-functional & obsolete "hangup" button. (6) I reboot my phone again to fix that.)

This is a regression -- I was able to use my phone successfully on Friday. I installed at least one (maybe two) OTA updates between Friday and Saturday morning, when my phone stopped working. I've installed another OTA update or two since then, and it's still not working.

Current (broken) version info:
OS Version: 2.1.0.0-prerelease
Build Identifier: 20141123001201
Update channel: nightly-b2g34
Git Commit Info: 2014-11-21 22:43:54 afdfa629

[Blocking Requested - why for this release]: regression breaking a core feature (ability to place/receive calls)

Comment 1

[Daniel Holbert [:dholbert]]

Currently, the most recent change on https://github.com/mozilla-b2g/gaia/tree/v2.1 is:
https://github.com/mozilla-b2g/gaia/commit/afdfa629be209dd53a1b7b6d6c95eab7077ffcd9

with this commit message:
"Bug 1093862 - Make Callscreen not respond to user input while there are no currently handled calls"

Based on the timing, this is clearly a regression from that bug. (Merged to aurora on Friday afternoon, and I first hit this Saturday morning.

I'm guessing we're just being a bit overzealous about when to "make callscreen not respond to user input"... Doug, can you take a look at this (and ideally back out if you don't have an immediate quick fix)?  This is making my phone not work at all as a phone, per comment 0.

Comment 2

[Daniel Holbert [:dholbert]]

It's not just me, either -- jpdeplaix reported the same symptoms as this bug, over on
 https://github.com/mozilla-b2g/gaia/pull/26046#issuecomment-64140890
(which is the github page for the pull request that regressed this).

Given that the regressing cset landed on trunk 10 days ago & this bug hasn't been reported by any trunk dogfooders yet, it seems like this is an Aurora-only issue.  That raises the possibility of a busted merge, or something along those lines.

trunk version:  https://github.com/mozilla-b2g/gaia/commit/0e6c2571d5368032c9ee11a033b261a4343e9c06
aurora version: https://github.com/mozilla-b2g/gaia/commit/afdfa629be209dd53a1b7b6d6c95eab7077ffcd9

The aurora version does list some "conflicts" in the commit message, and its first chunk has the following change that's not present in the before/after view of the trunk version:

>- }, CallScreen.callEndPromptTime);
>+ }, timeout);

The trunk version already has "timeout" on that line, but Aurora did not (until this merge).  That might be the problem... (presumably the "timeout" variable comes from some other commit which has not yet made it to Aurora.)

So -- kwierso, it's looking like this might be a bad merge...

Comment 3

[Daniel Holbert [:dholbert]]

Indeed, "timeout" was added on trunk as a parameter to this function (exitCallScreenIfNoCalls), in this commit here:
 https://github.com/mozilla-b2g/gaia/commit/20a56c3cf6ea6b730d05d7a8cfa06e178cd5717c

That commit has not yet made it to 2.1 (though it's got a pending approval request). So, "timeout" is an undeclared variable here, which must be causing us to throw an exception or something.  So, this was a copypaste error in the merge to 2.1, it looks like -- we should not have made the change that I quoted in comment 2 here. (That change is in the context of the Trunk code; it's not part of the trunk patch.)

(Pretty scary that we don't have automated tests/smoketest coverage for this sort of bug, and we can have this sort of breaks-the-phone regression on a semi-stable branch for > 48 hours without any alarms going off... :-/)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: pull request to revert line that shouldn't have changed

Here's a pull request to revert the line described in comment 2, which shouldn't have been changed in the merged-to-2.1 version of this patch.

Not sure if this technically needs approval2.1; requesting it to be on the safe side & get this in the pipeline ASAP, so that people's phones don't stay broken for too long.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): an extra change in bug 1093862's 2.1 merge

[User impact] if declined: Phone does not work as a phone. (Callscreen unresponsive to user input)

[Testing completed]: Have not tested patch; however, it seems clearly-correct (and the change it reverts was clearly-incorrect); it's reverting a pretty-clearly accidentally-added line, which references an unused variable.

[Risk to taking this patch] (and alternatives if risky): Low. (Just removing an unused variable & restoring what we had before.)

[String changes made]: None.

Comment 5

[Douglas Arellanes]

This regression happened to me as well. I also followed the same steps dholbert did, and got the same results. Hoping this one gets fixed quickly.

Comment 6

[Wilfred Mathanaraj [:WDM]]

Comms triage: issue is impacting basic functionality of dialer.

Comment 7

[Johan Lorenzo [:jlorenzo]]

I have this regression on my dogfooding device too.

(In reply to Daniel Holbert [:dholbert] from comment #3)
> (Pretty scary that we don't have automated tests/smoketest coverage for this
> sort of bug, and we can have this sort of breaks-the-phone regression on a
> semi-stable branch for > 48 hours without any alarms going off... :-/)

We have this coverage with the gaia-ui-tests running on device only. It's run every once every weekday. As the issue happened on Friday night (European time), it wasn't caught by Friday's automated smoketest run.  This report[1] was sent today.

For the manual smoketests, the team on the West coast tested build 20141120001207 which was made an hour before the landing.

[1] http://jenkins1.qa.scl3.mozilla.com/view/UI/job/flame-kk-319.mozilla-b2g34_v2_1.ui.functional.smoke/87/HTML_Report/

Comment 9

[Kevin Grandon :kgrandon]

Sorry, I missed that there was a patch here which fixes the problems by uplifting bug 1093862.

Since bug 1093862 has been reverted I'm going to close this. Let's uplift the proper patch in that bug.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

(In reply to Daniel Holbert [:dholbert] from comment #3)
> (Pretty scary that we don't have automated tests/smoketest coverage for this
> sort of bug, and we can have this sort of breaks-the-phone regression on a
> semi-stable branch for > 48 hours without any alarms going off... :-/)

Even better - it *was* burning automated tests for days and nobody was paying any attention to that fact.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Kevin Grandon :kgrandon (In Europe/Conf until 11/24) from comment #9)
> Sorry, I missed that there was a patch here which fixes the problems by
> uplifting bug 1093862.
> 
> Since bug 1093862 has been reverted I'm going to close this. Let's uplift
> the proper patch in that bug.

No worries. Thanks for backing out & fixing this!

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #7)
> We have this coverage with the gaia-ui-tests running on device only. It's
> run every once every weekday.
[...]
> For the manual smoketests, the team on the West coast tested build
> 20141120001207 which was made an hour before the landing.

Thanks, that makes me feel a bit safer staying on this release channel. :)

Comment 12

[Johan Lorenzo [:jlorenzo]]

2.2 was not affected by the uplift issue.

Comment 13

[Daniel Holbert [:dholbert]]

I've verified that this is fixed after the latest 2.1 nightly-channel OTA update (which became available in the last hour or so).

Working version (under "Git commit info" in More Information settings section): 8ae086c3

Comment 14

[Alissa（leave from Mozilla）]

This issue has been successfully verified on Flame 2.1.
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0

Comment 15

[dattaz]

Attachment: log-zte-open-c-fr

I always have this issue on a ZTE OPEN C with 2.1 version (2014-12-03)
With FR version and from IRC retour ebay too