Direct calls failure information (user available/something went wrong) no longer shows, sticks on "Connecting" or "Ringing"

RESOLVED FIXED in Firefox 39

Status

Hello (Loop)
Client
P1
normal
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: standard8, Assigned: mikedeboer)

Tracking

({regression})

unspecified
mozilla40
regression
Points:
1
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(firefox38 ?, firefox39+ verified, firefox40+ fixed)

Details

(Whiteboard: [error][direct])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Regression from bug http://hg.mozilla.org/mozilla-central/rev/a6292a3ac79d / Bug 1132301. Note this changeset landed before the 39 uplift so affects aurora as well.

STR:

- Log into Hello via FxA
- Initiate a direct call to a user who you know isn't online.

Expected Results

- "User is unavailable" should be displayed

Actual Results

- The connecting information remains at "Connecting" or "Ringing".

On the console there is a message (via the CallFailedView):

"No string found for key: " "share_button2"

The patches that have so far landed for bug 1132301 don't fix this.

[Tracking Requested - why for this release]: Expected functionality broken.
(Assignee)

Updated

3 years ago
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED
(Assignee)

Updated

3 years ago
Iteration: --- → 40.1 - 13 Apr
Points: --- → 1
Flags: qe-verify+
Flags: firefox-backlog+
(Assignee)

Comment 1

3 years ago
Created attachment 8589572 [details] [diff] [review]
Patch v1: update share_button2 label to the updated share_button3
Attachment #8589572 - Flags: review?(standard8)
(Reporter)

Updated

3 years ago
Attachment #8589572 - Flags: review?(standard8) → review+
Tracking since this is a regression and visible to users. 

Once the work in bug 1152197 and this bug land in 40, it may help for QE to verify both bugs. Then it looks like both these bugs will have elements that need uplift to 39.   Does this affect 38?
status-firefox38: --- → ?
tracking-firefox39: ? → +
tracking-firefox40: ? → +
Flags: needinfo?(mdeboer)
(Assignee)

Comment 3

3 years ago
(In reply to Liz Henry (:lizzard) from comment #2)
> Tracking since this is a regression and visible to users. 
> 
> Once the work in bug 1152197 and this bug land in 40, it may help for QE to
> verify both bugs. Then it looks like both these bugs will have elements that
> need uplift to 39.   Does this affect 38?

No, this does not affect 38. However, since bug 1132301 is slated to (re-)land today and will be uplifted to 39 too, I'm pondering whether we should go through the trouble of landing this before that.
Feels like waste of energy to me.
Flags: needinfo?(mdeboer)
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1154511
(Reporter)

Comment 5

3 years ago
Hi Mike, don't forget to land this
Flags: needinfo?(mdeboer)

Updated

3 years ago
Iteration: 40.1 - 13 Apr → 40.2 - 27 Apr

Updated

3 years ago
Whiteboard: [error][direct]
(Assignee)

Comment 6

3 years ago
Pushed to fx-team as: https://hg.mozilla.org/integration/fx-team/rev/49c0af0d1d4a
Flags: needinfo?(mdeboer)
(Assignee)

Comment 7

3 years ago
Comment on attachment 8589572 [details] [diff] [review]
Patch v1: update share_button2 label to the updated share_button3

Approval Request Comment
[Feature/regressing bug #]: Bug 1132301
[User impact if declined]: I forgot to update a string label whilst landing the new strings for bug 1132301.
[Describe test coverage new/current, TreeHerder]: Once this lands on m-c, it's good to go. This is a 1-line patch (the second file is generated)
[Risks and why]: none.
[String/UUID change made/needed]: n/a.
Attachment #8589572 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/49c0af0d1d4a
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Comment on attachment 8589572 [details] [diff] [review]
Patch v1: update share_button2 label to the updated share_button3

Approving for uplift to aurora so that the share button will be visible.
Attachment #8589572 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I tried to verify this issue on Firefox 40.0a1 (2015-04-20) using Windows 7 64-bit and this is what I have noticed:
- yahoo and gmail contacts: "Something went wrong.You can try again or email a link to be reached at later" message appeared after a few seconds

- outlook contacts: The connecting information remains at "Connecting", the "Cancel" button is disabled and these errors are thrown in browser console:
------------------------------------------------------------------------------------------------------------------------
The Components object is deprecated. It will soon be removed. utils.js:9:0
"Loop hawkRequest error:" Object { code: 400, errno: 122, error: "Could not find any existing user to…" } MozLoopService.jsm:662
"HTTP 400 Could not find any existing user to call; undefined" client.js:74:7

"Failed to get outgoing call data" Object { error: "Could not find any existing user to…", message: undefined, code: 400, errno: 122 } conversationStore.js:501:13

invalid dependency: reason; expected String, got Number validate.js:77:0
-------------------------------------------------------------------------------------------------------------------------

Are there any restrictions for some Email Services?

And please tell me if are some Email Services that requires special testing.
Flags: needinfo?(mdeboer)
QA Contact: bogdan.maris
(Assignee)

Comment 12

3 years ago
(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #11)
> Are there any restrictions for some Email Services?
> 
> And please tell me if are some Email Services that requires special testing.

No, but for direct calling to work _both_ email addresses need to be signed in as FxA accounts and _both_ of them need to use Loop/ Hello connected to the same server - 'https://loop.services.mozilla.com/v0' as set in the 'loop.server' pref.
Since you're testing many variations and possibly switch between the staging server and production, it's quite likely that direct calling might not work in certain these scenarios.
Flags: needinfo?(mdeboer)
(Assignee)

Comment 13

3 years ago
BTW, I just finished a successful call between two distinct Firefox Accounts using different Firefox versions, both connected to 'https://loop.services.mozilla.com/v0'.
Reproduced the initial issue using old Nightly build from 2015-04-09, verified that the issue is fixed using Firefox 39 beta 1 build 2 across platforms (Windows 7 64-bit, Ubuntu 14.04 64-bit and Mac OS X 10.9.5.
status-firefox39: fixed → verified
Removing qe-verify+ since verification on Firefox 39 Beta should suffice.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.