Closed Bug 983459 Opened 11 years ago Closed 11 years ago

[B2G][Notifications] Access point for "Voicemail" notification doesnt launch Dialer app

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog, b2g-v1.3 unaffected, b2g-v1.4 affected)

RESOLVED FIXED
1.4 S6 (25apr)
tracking-b2g backlog
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.4 --- affected

People

(Reporter: jschmitt, Assigned: gerard-majax)

References

Details

(Whiteboard: dogfood1.4, [systemsfe][priority])

Attachments

(3 files, 3 obsolete files)

Attached video Voicemail.mpeg (deleted) —
Description: The Voicemail notification does not place call or disappear when the user has not setup the Voicemail Repro Steps: 1) Updated Buri to BuildID: 20140312040203 2) With Voicemail setup on device, call the device and leave a Voicemail 3) Proceed to Settings -> Call Settings -> Voicemail 4) Delete the phone number in Voicemail and select 'Ok' 5) Exit Settings and drag down the Notifications bar 6) Select 'New Voicemail' Actual: The call is not placed, and the Voicemail notification does not disappear Expected: The call is placed to Voicemail, or a message appears explaining that Voicemail is not setup Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140312040203 Gaia: 3005269d4dcabcc7d27eaf72bda44a969873af8c Gecko: 23005b395ae8 Version: 30.0a1 Firmware Version: V1.2-device.cfg Notes: Repro frequency: 100% See attached: Video
Issue does not occur on the latest 1.3 Buri build Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140313004002 Gaia: 6194def5ceed3f4b9bc9de0ea2c11661cd439a27 Gecko: 9368fd13bfa6 Version: 28.0 Firmware Version: v1.2-device.cfg
What exactly happens on 1.3 here?
Keywords: qawanted
After further investigation on 1.3 when selecting the 'Voicemail' notifications opens the Dialer app and calls the Voicemail number, however the notification does NOT disappear from the notification center.
Keywords: qawanted
I can't follow the analysis here comparing 1.3 vs. 1.4 behavior. Can you clarify what exactly is different between each release?
Keywords: qawanted
On the 1.4 selecting the voicemail notification does not open the Dialer app. In 1.3 selecting the voicemail notification opens Dialer and calls the voicemail.
Keywords: qawanted
Does the voicemail call get placed if I select the notification for voicemail with voicemail already setup on the device?
Keywords: qawanted
It appears that when selecting Voicemail in notifications while Voicemail is setup the call is not placed.
Keywords: qawanted
So the voicemail not being setup part then plays no factor in reproducing this bug. The problem is that the dialer app fails to call your voicemail number when selecting the voicemail notification. This works on 1.3, which means this is a confirmed regression.
blocking-b2g: --- → 1.4?
Component: General → Gaia::System
Summary: [B2G][Notifications] Access point for "Voicemail" notification doesnt launch Dialer app when "Voicemail" is not setup → [B2G][Notifications] Access point for "Voicemail" notification doesnt launch Dialer app
blocking-b2g: 1.4? → 1.4+
Whiteboard: dogfood1.4 → dogfood1.4, [systemsfe]
(In reply to Jason Smith [:jsmith] from comment #8) > So the voicemail not being setup part then plays no factor in reproducing > this bug. The problem is that the dialer app fails to call your voicemail > number when selecting the voicemail notification. This works on 1.3, which > means this is a confirmed regression. I experienced this bug. In my case, the voicemail number in the notification was buggy. Not sure who's fault it is.
(In reply to Josh Schmitt from comment #3) > After further investigation on 1.3 when selecting the 'Voicemail' > notifications opens the Dialer app and calls the Voicemail number, however > the notification does NOT disappear from the notification center. That's expected, notification will disappear once you listen to your voicemails.
Maybe it's a regression from bug 975918 ?
On my device, the Voicemail number in settings is '+', and I cannot change it :( When I try, I'm getting: E/GeckoConsole( 3000): [JavaScript Error: "TypeError: 0 is read-only" {file: "app://settings.gaiamobile.org/js/call_voicemail_settings.js" line: 36}]
Depends on: 985090
Looks like queyring ril.iccInfo.mbdn I don't get an array but rather a string.
Depends on: 985117
(In reply to Josh Schmitt from comment #0) > Created attachment 8390888 [details] > Voicemail.mpeg > > Description: > The Voicemail notification does not place call or disappear when the user > has not setup the Voicemail > > Repro Steps: > 1) Updated Buri to BuildID: 20140312040203 > 2) With Voicemail setup on device, call the device and leave a Voicemail > 3) Proceed to Settings -> Call Settings -> Voicemail > 4) Delete the phone number in Voicemail and select 'Ok' > 5) Exit Settings and drag down the Notifications bar > 6) Select 'New Voicemail' > > Actual: > The call is not placed, and the Voicemail notification does not disappear > > Expected: > The call is placed to Voicemail, or a message appears explaining that > Voicemail is not setup > > Environmental Variables: > Device: Buri 1.4 MOZ > BuildID: 20140312040203 > Gaia: 3005269d4dcabcc7d27eaf72bda44a969873af8c > Gecko: 23005b395ae8 > Version: 30.0a1 > Firmware Version: V1.2-device.cfg > > Notes: > Repro frequency: 100% > See attached: Video Looking at the source code carefully, this is not a bug per se. When we send the notification, we explicitely add no 'click' event handler that is reponsible for placing the call, as in https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/voicemail.js#L91. I don't get the point of placing a call to voicemail when we have no voicemail number to call. So I think that if we want to fix this, we should rather display something to the user. We need input from the UX there.
Asking UX input on how we should notify the user in this case: tapping on voicemail notification when no voicemail number is available.
Flags: needinfo?(firefoxos-ux-bugzilla)
Assignee: nobody → lissyx+mozillians
Flagging Jacqueline on notifications as Rob is on vacation, and flagging Carrie on the dialer and voicemail pieces.
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
Flags: needinfo?(firefoxos-ux-bugzilla)
Flags: needinfo?(cawang)
Hi, sorry for the late reply. I was on travel these days. For this case, I'd suggest popping up a confirm window, which shows: ========================================================== title: Voicemail number is unavailable ----------------------------------------- content: Unable to call the voicemail. Set up the voicemail number to place the call. action: Cancel Settings ========================================================== If the user taps cancel, close the confirm window. If the user taps Settings, go to "Voicemail" setting. (Settings-> Call settings-> Voicemail) However, from comment 14, it looks like even the number is already set up, it will not directly place the call while users tap the notification. In this way, why shall we display information for them when the number is unavailable? Users will not expect to tap it to call. Hence, if the notification only shows "New voicemail" without any further action, then the confirm window I mentioned above should only appear when users long-tap "1" in dialer to access the voicemail. In addition, I can't reproduce the bug here. On my device, I only received a SMS from carrier to inform me the voicemail. I didn't receive any notification! Correct me if I have some misunderstanding here. Thanks!
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
Flags: needinfo?(cawang)
(In reply to Carrie Wang [:carrie] from comment #17) > Hi, sorry for the late reply. I was on travel these days. > > For this case, I'd suggest popping up a confirm window, which shows: > > ========================================================== > title: Voicemail number is unavailable > ----------------------------------------- > content: Unable to call the voicemail. > Set up the voicemail number to place the call. > > action: Cancel Settings > ========================================================== > If the user taps cancel, close the confirm window. > If the user taps Settings, go to "Voicemail" setting. (Settings-> Call > settings-> Voicemail) > > However, from comment 14, it looks like even the number is already set up, > it will not directly place the call while users tap the notification. In > this way, why shall we display information for them when the number is > unavailable? Users will not expect to tap it to call. > Hence, if the notification only shows "New voicemail" without any further > action, then the confirm window I mentioned above should only appear when > users long-tap "1" in dialer to access the voicemail. > > In addition, I can't reproduce the bug here. On my device, I only received a > SMS from carrier to inform me the voicemail. I didn't receive any > notification! Correct me if I have some misunderstanding here. > Thanks! That sounds like a new feature. Can we split this up? 1.4 just display the overlay saying please set up the voicemail and in 1.5 actually provide the full functionality with the link to the settings app here?
Note for the fix required here - let's make sure that we're focusing on resolving the regression here & not adding unnecessary feature scope.
After further investigation, currently the bug is SIM specific, I have tested multiple devices and different SIMs trying to repro this bug, but the bug only repros with my SIM. My voicemail is always 'Not Set' so when selecting the 'Voicemail' notification the Dialer app does not open because a number is not set. When testing a SIM that has voicemail auto set ability, the bug does not repro. I have retested on 1.1, 1.2, 1.3 and 1.4 on my device with my affected SIM and the Dialer app the bug reproduces, with other SIMs this bug does not repro. In comment 3 I used a reference device/SIM not the affected device/SIM I used in comment 0. 1.1 Buri Build Environmental Variables: Device: Buri 1.1 MOZ BuildID: 20140318041202 Gaia: 44a2ddf63373f8e95c784faf4ed4d60081699c61 Gecko: 2c70ef07c5b3 Version: 18.0 Firmware Version: V1.2-device.cfg 1.2 Buri Build Environmental Variables: Device: Buri 1.2 MOZ BuildID: 20140311004003 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: 9008f899e5af Version: 26.0 Firmware Version: V1.2-device.cfg 1.3 Buri Build Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140325004002 Gaia: b789780c53adaac199787f51615375f721edfef4 Gecko: 37917eb0dfeb Version: 28.0 Firmware Version: V1.2-device.cfg 1.4 Buri Build Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140324000202 Gaia: 730670951e40b2317a167fcd07c398bb662d6e87 Gecko: a44f8b39c2c8 Version: 30.0a2 Firmware Version: V1.2-device.cfg SIM settings information as seen using a SIM card manager on an Android device: Phone Type: GSM Phone Number: 359585046591654 SIM state: ready SIM serial number: 89014103276352319781 SIM country ISO: us SIM Operator name: AT&T SIM operator code: 310410 Network type: Unknown Network country ISO: Network operator code: 00000 Network operator name: Service state: Registered to network Network operator manually selected: No Active roaming: No Voice mail text ID: Voicemail Voice mail number:
Discussed with nkot offline - she's going to assign someone to re-analyze this, as comment 20's analysis seems inconsistent with the original bug filed.
Keywords: qawanted
This is not a bug, following STRs in Comment 0, I do not reproduce the issue as described in Comment 0 on latest v1.4 and v1.3. I launch Dialer app as expected when tapping on the Voicemail notification. I worked with the reporter and with an Android device we were able to successfully add a Voicemail number to the SIM, when we transferred the SIM back to the Buri it is shown initially in Settings and the issue no longer reproduces on his device. Instead when tapping the Voicemail notification, the Dialer app is launched.
Keywords: qawanted
Thanks for the clarification - closing this as invalid then.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
This happens on certain sim cards so I am not sure if this is invalid. Alex saw this issue as well. He should take a look and reopen once he is back.
Fair enough, let's keep this open & keep investigating.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Alex, what do we need to do here?
Flags: needinfo?(lissyx+mozillians)
(In reply to Gregor Wagner [:gwagner] from comment #26) > Alex, what do we need to do here? Well, I think we just need to implement the UI, and do a follow up for the link to settings, as you suggested?
Flags: needinfo?(lissyx+mozillians)
We should fix this but we can ship 1.4 without it. The fix is explained in comment 17.
blocking-b2g: 1.4+ → backlog
Whiteboard: dogfood1.4, [systemsfe] → dogfood1.4, [systemsfe][priority]
Please find attached a link to the github pull request that fixes the issue. I implemented a user dialog as suggested in comment 17.
Attachment #8401318 - Flags: review?(timdream)
Attachment #8401318 - Flags: ui-review?(firefoxos-ux-bugzilla)
Comment on attachment 8401318 [details] Link to Github https://github.com/mozilla-b2g/gaia/pull/17948 Flagging Jacqueline for patch review since it is a holiday for Taipei (and thus for Carrie). Jacqueline, please reassign as needed/appropriate.
Attachment #8401318 - Flags: ui-review?(firefoxos-ux-bugzilla) → ui-review?(jsavory)
While working on bug 991865, I noticed this patch in the Travis PR builds. I'm going to sync my changes to yours so that the messages are the same.
FYI, bug 980701 will impact this code, so I prefer it lands before the present bug. We will have to rebase once bug 980701 landed.
Depends on: 980701
(In reply to Alexandre LISSY :gerard-majax from comment #32) > Travis is green at https://travis-ci.org/mozilla-b2g/gaia/builds/22219126 I forced a rebuild of the unit tests because I noticed an error on my patch which was applied on top of yours. The rebuild reprod it: https://travis-ci.org/mozilla-b2g/gaia/jobs/22219128 I fixed it by doing this: https://github.com/DouglasSherk/gaia/commit/c6658abb292d04bfd37cd2aee066be914d05dfa1#diff-a69d5a04235b584fc246078cb421f397L19
(In reply to Doug Sherk (:drs) from comment #34) > (In reply to Alexandre LISSY :gerard-majax from comment #32) > > Travis is green at https://travis-ci.org/mozilla-b2g/gaia/builds/22219126 > > I forced a rebuild of the unit tests because I noticed an error on my patch > which was applied on top of yours. The rebuild reprod it: > https://travis-ci.org/mozilla-b2g/gaia/jobs/22219128 > > I fixed it by doing this: > https://github.com/DouglasSherk/gaia/commit/ > c6658abb292d04bfd37cd2aee066be914d05dfa1#diff- > a69d5a04235b584fc246078cb421f397L19 Thanks for the info, I've added it it.
Comment on attachment 8401318 [details] Link to Github https://github.com/mozilla-b2g/gaia/pull/17948 Etienne should be the better reviewer on this file.
Attachment #8401318 - Flags: review?(timdream) → review?(etienne)
Comment on attachment 8401318 [details] Link to Github https://github.com/mozilla-b2g/gaia/pull/17948 r=me with the comments addressed (a bit more this time ;)) You should attach a screenshot of the prompt if you want a quick ui-review.
Attachment #8401318 - Flags: review?(etienne) → review+
Attached image Missing voicemail number message (obsolete) (deleted) —
Screenshot to help ui-review
(In reply to Alexandre LISSY :gerard-majax from comment #38) > Created attachment 8403275 [details] > Missing voicemail number message > > Screenshot to help ui-review In my case, in bug 991865, it looks a bit different. See attachment 8403463 [details]. We should probably sync them so they look the same.
(In reply to Doug Sherk (:drs) from comment #39) > (In reply to Alexandre LISSY :gerard-majax from comment #38) > > Created attachment 8403275 [details] > > Missing voicemail number message > > > > Screenshot to help ui-review > > In my case, in bug 991865, it looks a bit different. See attachment 8403463 [details] > [details]. We should probably sync them so they look the same. Those are indeed the same, it's just that I took the screenshot in B2G Desktop.
Attached image Missing voicemail number message on Inari (obsolete) (deleted) —
(In reply to Alexandre LISSY :gerard-majax from comment #40) > Those are indeed the same, it's just that I took the screenshot in B2G > Desktop. Here's a screenshot of it on an Inari.
Thank you for the screenshot, it really helps with the reviews on bugs like this. The attachment 8403275 [details] needs to have the title "Voicemail Number is Unavailable" that Carrie mentioned and the layout should not have the space at the beginning of the body text. Attachment 8403463 [details] looks like it has the correct layout and structure.
Attachment #8401318 - Flags: ui-review?(jsavory) → ui-review-
Rha, ModalDialog does not allows for a title after looking in the source ...
Depends on: 994262
I'm going to move my new strings to shared/, to simplify future work like bug 991865.
Flags: needinfo?(drs+bugzilla)
Bug 994262 landed, we still have to fix the spacing?
Flags: needinfo?(jsavory)
Attached image Capture du 2014-04-10 12:34:09.png (obsolete) (deleted) —
Fixing title and spacing.
Attachment #8403275 - Attachment is obsolete: true
Attachment #8403498 - Attachment is obsolete: true
Attachment #8404611 - Flags: ui-review?(jsavory)
Comment on attachment 8401318 [details] Link to Github https://github.com/mozilla-b2g/gaia/pull/17948 Carrying r+ from alive for the css change (on IRC).
Attachment #8401318 - Flags: review+
Everything looks correct to me in this screenshot, except for the font. Will this be changed to one of the fonts we are currently using? Also, ni? Carrie just to confirm the design is correct.
Flags: needinfo?(jsavory) → needinfo?(cawang)
(In reply to jsavory from comment #48) > Everything looks correct to me in this screenshot, except for the font. Will > this be changed to one of the fonts we are currently using? Also, ni? Carrie > just to confirm the design is correct. The fonts are because of B2G Desktop.
Attached image 2014-04-12-12-43-34.png (deleted) —
Updated screenshot with one taken on Inari, to get the correct fonts.
Attachment #8404611 - Attachment is obsolete: true
Attachment #8404611 - Flags: ui-review?(jsavory)
Attachment #8405747 - Flags: ui-review?(jsavory)
Thanks for the heads up.
Flags: needinfo?(drs+bugzilla)
Yes it looks fine to me with the fonts on Inari. Thanks!
Flags: needinfo?(cawang)
Attachment #8401318 - Flags: ui-review- → ui-review+
Comment on attachment 8405747 [details] 2014-04-12-12-43-34.png r+ from carrie in comment 52.
Attachment #8405747 - Flags: ui-review?(jsavory) → ui-review+
And rebased pull request is green on travis: https://travis-ci.org/mozilla-b2g/gaia/builds/22926964
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S6 (25apr)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: