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.
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+
Target Milestone: --- → mozilla40
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
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-firefox40: --- → fixed
Resolution: --- → FIXED
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
status-firefox38: --- → affected
status-firefox39: --- → affected
status-firefox39: affected → fixed
status-firefox38: affected → fixed
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.
status-firefox38: fixed → verified
Removing qe-verify flag as verification on 38 Beta should suffice.
You need to log in before you can comment on or make changes to this bug.