We generate a new call URL every time the loop panel is opened so this should handle switching to an FxA call URL upon login. When you logout, the panel remains open and so the URL needs be instantly switched from an FxA one to a Guest one otherwise the user could copy a call URL that would only work where they are logged in. The panel is already notified via the LoopStatusChanged event so we can use that to see if we should get a new type of call URL. String already landed in another bug: "This will close any open conversations"
We generate a new call URL every time the loop panel is opened so this should handle switching to an FxA call URL upon login. When you logout, the panel remains open and so the URL needs be instantly switched from an FxA one to a Guest one otherwise the user could copy a call URL that would only work where they are logged in. The panel is already notified via the LoopStatusChanged event so we can use that to see if we should get a new type of call URL.
Could we also just cache the guest loop call URL prior to authenticating and then restore that call URL after logout (retrieving a new one if the cached one is past the expiration date)?
I assumed that wouldn't be wanted since we generate a new URL every time the panel is opened. I suspect that same desire would apply here.
(In reply to Matthew N. [:MattN] from comment #2) > I assumed that wouldn't be wanted since we generate a new URL every time the > panel is opened. I suspect that same desire would apply here. Yeah, I'm wondering though if that is even necessary in itself, as it adds a noticeable delay before a URL is shown and generates potentially unnecessary work for the server. Getting new URLs each time the panel won't work 100% of the time with getting people to send unique URLs for each conversation, as once a URL is copied to the clipboard, the initiator may send that same URL to multiple people.
I see now my conversation is more relevant to bug 1030961.
P2 since even though it's a major issue when it happens, it doesn't seem like it will be super common except for the case where someone is logging out specifically to make a call without caller ID but I'm not sure how common that is.
Priority: -- → P2
moving to 36 as a clean-up since it's an edge case, based on description.
Target Milestone: --- → mozilla36
Lowering priority since this will likely go away with rooms.
status-firefox34: --- → affected
status-firefox35: --- → affected
Priority: P2 → P3
hi matt, since this won't make 34, will this go away when we go to rooms - so we can just close?
Most likely, but until I play with Rooms I won't be sure. The case I'm worried about is: 1) User is logged into FxA 2) User clicks to create a new room. 3) Conversation window opens with a URL. 4) User logs out from FxA. If we close all FxA rooms at this point then we will be fine. If the FxA rooms remain open even when I logout of FxA then we may have the same problem. If you can figure that interaction out then we can decide whether this will still be a problem with Rooms.
For rooms, I'd rather design make sure its designed in from the start than we pull it in later. Darrin, what do you think of closing all rooms upon signout as described in Matt's comment 9?
Sure -- we may want a prompt that says "Logging out will close any open rooms" or something, but I think it's a fine decision.
Hi Darrin, are we ok with the behavior of closing all rooms in Fx35, and then having another bug from prompting that all rooms will close but (new strings- so that bug in Fx36)? or should we do at once in 36? Hi Matej, either decision - are you good with the wording in comment 11 (seems simple and direct)? also, i know you've been our goto word smith guy for a lot - should I ask you these types of questions when they come up or is there a different process?
Well -- to address the string: Matej will probably want something without the term "room" in it. If we're going to close the windows in 35, is it too much of a stretch to add a confirm dialog? I'd like to hear from eng if this is trivial or has to be pushed a release.
(In reply to sescalante from comment #12) > Hi Matej, either decision - are you good with the wording in comment 11 > (seems simple and direct)? also, i know you've been our goto word smith guy > for a lot - should I ask you these types of questions when they come up or > is there a different process? This process works for me. If it starts to get to be too much, we can look at doing it in batches, but for now we're good this way. As for the string, Darrin is right that I would prefer to not say "room." Maybe it could be: "This will close any open conversations" Would that work?
Mark -- Is a prompt before closing all rooms possible in Fx35 using an existing string we can use? We can use Matej's string (Comment 14) in Fx36 with no problem. Should we consider this bug part of the "Rooms" work at this point? It feels like it belongs with the Rooms work IMO. (Should I link it to the Rooms meta bug and put it on the Rooms trello board?)
Adding [rooms] for now. We can remove if folks find it confusing.
Whiteboard: [fxa] → [fxa][rooms]
There's no existing string we could reuse. Doing this as part of the rooms work might make sense.
(In reply to Mark Banner (:standard8) from comment #17) > There's no existing string we could reuse. > > Doing this as part of the rooms work might make sense. If we don't have a string, then I think we just close the rooms without prompting in Fx35 -- and add the prompt (with string) in Fx36. I've linked this to the meta bug for Rooms.
backlog: Fx35+ → Fx36+
Whiteboard: [fxa][rooms] → [fxa][rooms][strings]
Summary: Generate new guest call URL upon logout from FxA → Prompting to close rooms before logging out from FxA (and close them)
I'm assuming this is wontfix for Firefox 34 at this point. Given this requires strings, the time is running out quickly for 35 as well. I believe strings are required for Beta 1.
status-firefox34: affected → wontfix
status-firefox36: --- → affected
[Tracking Requested - why for this release]: Need this for improved UI when logging out of FxA with Rooms. Requires strings, but the strings landed already in another bug (while Fx36 was still on Nightly). Only targeting uplift to Fx36.
tracking-firefox36: --- → ?
Not critical enough to be tracked for the 36 release.
status-firefox35: affected → wontfix
tracking-firefox36: ? → -
Moving all P1->P2. (P2 means a major bug that we very much want to fix, but we wouldn't stop ship or block the release for it.)
Here's the actual change from P1->P2 (per the previous comment). P2 indicates a major bug, but not a stop ship.
Priority: P1 → P2
the user story needs updating. Dan =], then need info Sevaan sevaan - we'll need some design work - actual UX on how do we ensure that the user has a mental model with different accounts. shell - find the bug for when you log out sending the error message to associate
Much of this bug is irrelevant, so I've opened bug 1120720 as a new one with the problem that can occur in the new rooms world. That failure mode does not match the string that was already landed, so I think the only thing to do here is to back this string out.
Whiteboard: [fxa][rooms][strings] → [fxa][rooms][strings][fxa-waffle-ignore]
Whiteboard: [fxa][rooms][strings][fxa-waffle-ignore] → [fxa][fxa-waffle-ignore]
Support for Hello/Loop has been discontinued. https://support.mozilla.org/kb/hello-status Hence closing the old bugs. Thank you for your support.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.