Receiving a call whilst in private browsing or no browser windows open can stop any calls to contacts being made or received

RESOLVED FIXED in Firefox 38

Status

defect
P4
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

unspecified
mozilla40
Points:
2
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +

Firefox Tracking Flags

(firefox38 verified, firefox39 fixed, firefox40 fixed)

Details

Attachments

(1 attachment)

Assignee

Description

4 years ago
STR:

1) Set up two browsers with different FxA accounts.
2) Put browser 2 into private browsing mode, ensure no normal windows are open
3) Initiate a call from browser 1 to browser 2

=> Call doesn't go through as expected.

4) On browser 2 open a non-private browsing window
5) Re-initiate a call from browser 1 to browser 2

Expected Results

Browser 2 gets alerted for an incoming call

Actual Results

Browser 2 doesn't get alerted; Browser 1 is informed the user is unavailable.


This doesn't affect rooms, as we don't have any form of "busy" handling on them at the moment.

We could probably improve the UX for browser 2, but as we're thinking about integrating calls into rooms (somehow) in the future, and the low amount of direct calls atm, I think its reasonable to fix the not being able to open a window issue, and leave the UX for now.

This isn't a major issue, but is one that's part of a set of issues we have to do with not always opening the chat window (bug 1152213), hence I want to fix it to cross one more item off the list.
Assignee

Comment 1

4 years ago
Simple patch to not record the window id if the window doesn't open. Includes unit test.
Attachment #8589551 - Flags: review?(mdeboer)
Attachment #8589551 - Flags: review?(mdeboer) → review+
Assignee

Comment 2

4 years ago
https://hg.mozilla.org/integration/fx-team/rev/f3f23037d074
Target Milestone: --- → mozilla40
Assignee

Updated

4 years ago
Summary: Receiving a call whilst in private browsing or not browser windows open can stop any calls to contacts being made or received → Receiving a call whilst in private browsing or no browser windows open can stop any calls to contacts being made or received
Assignee

Updated

4 years ago
Flags: qe-verify+
Flags: firefox-backlog+
https://hg.mozilla.org/mozilla-central/rev/f3f23037d074
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Assignee

Updated

4 years ago
Flags: in-testsuite+
Assignee

Comment 4

4 years ago
Comment on attachment 8589551 [details] [diff] [review]
Receiving a call whilst in private browsing or not browser windows open can stop any calls to contacts being made or received.

Approval Request Comment
[Feature/regressing bug #]: Hello direct calls to contacts
[User impact if declined]: In some circumstances the user might be able to get into a state where they can no longer receive direct calls.
[Describe test coverage new/current, TreeHerder]: Has xpcshell tests, landed in m-c.
[Risks and why]: Low. Adds a check to see if a window was actually opened before assuming it was. Although it is unlikely that users are hitting this issue, we're seeing various issues with the chat window not opening at times, and this is one more possibility that's highly obvious from the code that I'd like to eliminate.
[String/UUID change made/needed]: None
Attachment #8589551 - Flags: approval-mozilla-beta?
Attachment #8589551 - Flags: approval-mozilla-aurora?
Attachment #8589551 - Flags: approval-mozilla-beta?
Attachment #8589551 - Flags: approval-mozilla-beta+
Attachment #8589551 - Flags: approval-mozilla-aurora?
Attachment #8589551 - Flags: approval-mozilla-aurora+
Assignee

Comment 7

4 years ago
Sorry for not commenting out the possible beta bustage earlier. Landed a fix for the xpcshell-tests:

https://hg.mozilla.org/releases/mozilla-beta/rev/d13016a31d6f
Reproduced the initial issue using Firefox 38 beta 2, verified as fixed across platforms using Firefox 38.0 RC build 2.
Removing qe-verify flag as verification on 38 Beta should suffice.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.