Closed Bug 930604 Opened 9 years ago Closed 9 years ago

[dialer] The "dial" activity is not working when the app is not running

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 930296

People

(Reporter: julienw, Unassigned)

References

Details

(Keywords: regression)

STR:
* ensure the dialer is not running
* launch the messages app
* enter a thread
* tap the header
* depending on whether bug 890209 landed, you'll have a menu, then press "call"

Expected:
* the dialer starts, and the number is prefilled

Actual:
* the dialer starts but the number input is empty

I saw this on a very recent central/master.

QAWanted to test on 1.2.
Did some testing, the message handler is never called.

Could this be an issue with entry points?
Flags: needinfo?(fabrice)
bug 930296 was recently filed on the Sms app, seems related although this could be a coincidence. If this is the same bug then this is nothing to do with entry points.

However I did try the "send sms" activity from the contact app, and it works fine.
There's no relationship between entry points and activity urls. Is the message handler set properly when opening /dialer/index.html#keyboard-view ?
blocking-b2g: --- → 1.3?
Flags: needinfo?(fabrice)
(In reply to Fabrice Desré [:fabrice] from comment #3)
> There's no relationship between entry points and activity urls. Is the
> message handler set properly when opening /dialer/index.html#keyboard-view ?

yes.
note that when the app is already open everything works fine.
I'm wondering if this is caused by bug 924702, which apparently has broken a lot of basic flows already. It's being backed out on inbound right now, so we'll known shortly if this is getting fixed by the backout of that patch.
I also thought about that but I tested with the backout from bug 924702 and it still reproduces.
QA Contact: nkot
Regression window:

-last working-
BuildID: 20131016040202
Gaia: 3d4f1107e6e91e5f5649edc0f2565ac837111d7d
Gecko: 9f63bbc00527
Version: 27.0a1
Firmware: US_20131015

-first broken-
BuildID: 20131017040202
Gaia: 616e87af0133496620aea89f21ca5d37acedf466
Gecko: 423b9c30c73d
Version: 27.0a1
Firmware: US_20131015
does not reproduce on 1.2 - when dialer starts the number is prefilled

Buri aurora
BuildID: 20131028004002
Gaia: 2ef9bc3c7a6de228b63e6ba3613eb0c0dd639c59
Gecko: 4a94d2ea9d37
Version: 26.0a2
Keywords: qawanted
nkot: you had a "first broken" in comment 7, does that mean it's been somehow fixed since then ?
Flags: needinfo?(nkot)
Oh no sorry, got it now, it's broken on central, not on 1.2, great news!
Flags: needinfo?(nkot)
(In reply to Julien Wajsberg [:julienw] from comment #10)
> Oh no sorry, got it now, it's broken on central, not on 1.2, great news!

yeah :), it's just central, and it hasn't been fixed... still repros, just tried on today's m-c
Same regression window than bug 930296
Depends on: 932725
We investigated this with Julien and apparently only the first call to mozSetMessageHandler works properly (subsequent handlers will get triggered only if the app is already launched).

This is why:
- the new incoming call works on the dialer even when the app isn't launched
- but not the dial activity

- the new sms reception doesn't works when the sms app isn't open
- but the sms activity does

The dialer calls mozSetMessageHandler for the "telephony-new-call" first, then for the activity, the sms calls mozSetMessageHandler for the activity first, then for the new sms.

Marking this one as a duplicate.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
blocking-b2g: 1.3? → ---
You need to log in before you can comment on or make changes to this bug.