Closed Bug 1151862 Opened 5 years ago Closed 5 years ago
room list not in sync across two hello clients (when push notification received before accessing the Loop panel)
6.05 KB, patch
|Details | Diff | Splinter Review|
6.02 KB, patch
|Details | Diff | Splinter Review|
Here's a chat log describing the issue: <gavin> hmm, my rooms are not syncing across clients <gavin> (Nightly<->Release) <Standard8> you’re logged into both, right? and are both running at the same time? <Standard8> gavin: ^^^ <gavin> Standard8: yes <Standard8> gavin: might be worth checking if there’s any errors on the console about push <Standard8> i.e. not connected <Standard8> gavin: you could also check that by entering a room on each one and see if it updates the panel <gavin> Standard8: yep the panel/icon are updating properly on room joins <Standard8> uh-oh <Standard8> gavin: can you create another FF profile and log in there? See what happens then <gavin> Standard8: new profile gets all the rooms <Standard8> gavin: from one of your other clients or both? <Standard8> gavin: I guess, what do you mean by “all” ? <gavin> Nightly has all my rooms <gavin> Firefox has only two of them (I think they are the two that I have joined most recently) <gavin> (i.e. I think joining them in Nightly added them to Firefox) <gavin> a new profile (also in Nightly) sees all of the Nightly rooms <Standard8> hmm <Standard8> gavin: can you file a loop:server bug please, this is sounding a lot like bug 1111579 and its related bugs <firebot> https://bugzil.la/1111579 — FIXED, firstname.lastname@example.org — Hawk session and FxA account may not be in sync. <Standard8> which is worrying Let me know if I can provide any other useful debugging info.
Hi, I would need to have some more information about the accounts used (when they were created, where they used often?) and the rooms that aren't appearing. Also, I don't quite understand something: are the room showing in one profile and not the other one? Are you connected to an account in both cases?
(In reply to :Gavin Sharp [email: email@example.com] from comment #0) > <Standard8> gavin: can you file a loop:server bug please, this is sounding a > lot like bug 1111579 and its related bugs > <Standard8> which is worrying I'll note that bug 1111579 resulted in a completely disjoint set of rooms, since you ended up effectively with two different users on the server. This case, where you get partial data, clearly has both clients associated with the same account, but isn't sending all the data. I don't expect that they're related.
(In reply to Alexis Metaireau (:alexis) from comment #1) > Hi, > > I would need to have some more information about the accounts used (when > they were created, where they used often?) and the rooms that aren't > appearing. I'm using my "normal" Firefox account, create long ago (during the FxA-for-Sync days, early 2014). I've been using it for Sync since then, and for Hello since the beginning of this year. > Also, I don't quite understand something: are the room showing in one > profile and not the other one? Are you connected to an account in both cases? Yes. All the rooms I've created appear in Nightly, but in Firefox only rooms that I've recently joined ever appear. Today I am back down to only one of my rooms appearing in Firefox (a room I joined today, in Nightly).
Not sure what info you need about "which rooms" - maybe ping me on IRC to discuss more specific info?
I've just managed to reproduce this. STR with nightly, though I think this is in all versions since we released rooms: 1) Set up a Firefox ("Generator") with more than one room. Copy one of the room urls to another browser. 2) Restart Generator, DO NOT open the Hello Panel. 3) Wait ~30 seconds (to allow Hello to connect). 4) On the other browser, join the room => Note Generator gets a notification 5) Open the panel on Generator Expected Results => All rooms shown Actual Results => Only the room that was joined is shown
Assignee: nobody → standard8
Iteration: --- → 40.3 - 11 May
Points: --- → 2
Component: Server → Client
The issue here is that when we first start up, gDirty is true so when we open the panel, we do a getAll and that gets the fresh list. However, if we get a push notification before the first getAll, then it only gets a partial update from the server, and when that completes we set gDirty to false. Hence we never get the full list in that scenario.
Attachment #8601676 - Flags: review?(mdeboer)
Comment on attachment 8601676 [details] [diff] [review] Get the full list of Loop rooms on first notification if we haven't got it previously. Review of attachment 8601676 [details] [diff] [review]: ----------------------------------------------------------------- Well spotted, thanks! ::: browser/components/loop/test/xpcshell/test_looprooms_first_notification.js @@ +1,3 @@ > +/* This Source Code Form is subject to the terms of the Mozilla Public > + * License, v. 2.0. If a copy of the MPL was not distributed with this file, > + * You can obtain one at http://mozilla.org/MPL/2.0/. */ Generally, we license our test files as Public Domain; see head.js, for example. Can you change that here? AFAICS we also made this 'mistake' for - test_looprooms.js - test_loopservice_busy.js - test_loopservice_directcall.js - test_loopservice_dnd.js - test_loopservice_notification.js I don't know if it's wise to change it right to change it in this bug, but feel free to do so.
Attachment #8601676 - Flags: review?(mdeboer) → review+
Summary: room list not in sync across two hello clients → room list not in sync across two hello clients (when push notification received before accessing the Loop panel)
Approval Request Comment [Feature/regressing bug #]: Hello conversations [User impact if declined]: A user's list of rooms can get out of sync and only display rooms that other people have happened to visit in that session. [Describe test coverage new/current, TreeHerder]: has xpcshell tests, landed in m-c. [Risks and why]: Low, simple added check to get the full list of rooms on first notification if we haven't already. [String/UUID change made/needed]: None Note: Requesting for beta with 38.0.5 in mind, we've not heard of reports of this in the wild but we suspect it will affect some users, but hard to say how many and its particularly confusing when it does. If this only gets to 39, I won't be upset, I'm quite happy for drivers to decide on this one.
I'm happy to uplift this to 39 whether it's in aurora or early beta, but would like to make sure we know that the behavior is broken in 39.
Comment on attachment 8602592 [details] [diff] [review] Aurora version of the patch. Approved for uplift to aurora. Doublechecked to make sure 39 is affected.
Attachment #8602592 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8602592 [details] [diff] [review] Aurora version of the patch. This doesn't look critical enough for uplift to 38.0.5. It's in 39 already.
Attachment #8602592 - Flags: approval-mozilla-beta? → approval-mozilla-release-
Reproduced with Nightly 2015-05-05 using str from comment 5. Verified fixed with 39.0b1 (Build ID: 20150523155636), across platforms , with str from comment 5 and comment 0 - all the rooms are shown. Although, noticed that the conversation name is not synced between 39.0b1 build 2 [A] and 41.0a1 (from 2015-05-26) [B] → when I create a room on [B], the conversation name is not present in [A]; but when i do the other way around (create in [A]) the conversation name is correctly synced, including the nameless one is filled up. Please see the following screenshots: * 41.0a1 → http://i.imgur.com/kGcqgki.png * 39.0b1 → http://i.imgur.com/4GRhNSd.png Any ideas? Thanks in advance!  Windows 7 64-bit, Mac OS X 10.9.5 and Ubuntu 14.04 32-bit
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #16) > Although, noticed that the conversation name is not synced between 39.0b1 > build 2 [A] and 41.0a1 (from 2015-05-26) [B] → when I create a room on [B], > the conversation name is not present in [A]; but when i do the other way > around (create in [A]) the conversation name is correctly synced, including > the nameless one is filled up. Please see the following screenshots: > * 41.0a1 → http://i.imgur.com/kGcqgki.png > * 39.0b1 → http://i.imgur.com/4GRhNSd.png > > Any ideas? Thanks in advance! Yes, that is expected. From 40 onward the room names are encrypted along with any context information added to the room. FF versions 39 and older don't have the decryption code and hence won't be able to read the room name.
Removing qe-verify+ since verification on Firefox 39 Beta should suffice.
You need to log in before you can comment on or make changes to this bug.