Open Bug 459318 Opened 11 years ago Updated 10 years ago
Reuse/merge existing query view/object model after other user disconnects and reconnects
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20080715 Ubuntu/7.10 (gutsy) Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20080715 Ubuntu/7.10 (gutsy) Firefox/18.104.22.168 Trying to drag and drop the active "user_a" tab will actually move the unactive "user_a" tab left open. Reproducible: Always Steps to Reproduce: 1. Talk with "user_a" in a query view 2. "user_a" pings timeout for some reason (but you can still write in this "unactive" tab, without receiving "No such nick / channel" message 3. user_a reconnects with the same nick 4. Write to user_a in the "unactive" tab 5. This will open a new "user_a" tab at the right of the other tabs 6. Trying to drag & drop the new "user_a" tab does not move the tab, but moves and drop the old unactive "user_a" tab. (In my example, user_a was email@example.com at first, and came back as firstname.lastname@example.org, but I'm not sure this is relevant. Would need guinea-pigs to test further) Actual Results: 6. Trying to drag & drop the new "user_a" tab does not move the tab, but moves and drop the old unactive "user_a" tab. Expected Results: The newish "user_a" tab should move
Yeah, this is an artifact of how we do the tab moving; the URI of the tab is used as a unique identifier, but in this situation you have a "user_a" tab and a "user_a<2>" tab, both with the same URI. Would it make more sense to you if we reused the tab for user_a in the first place? I think it would (although we'd be stuffed if they come back before the ping timeout).
It has always bugged me to no end to see a new tab "user_a" popping up in this case, so if it is possible, yes, it would make sense to me to re-use the old "user_a" tab and not have a new one created. (If user_a has a really bad connection, you could end up with many "user_a" tabs!) If that's not too difficult a change, that would be great! But still, we would need to have a user_a<2> tab if you have a query with user_a on server1 and another on server2, which is "legitimate" in this case. Sugnim++
Let's make it re-use the tab. Not sure if we should keep the user object around and re-use that, or associate the old object's data with the new one, but we should keep the same view and its messages.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86 → All
Summary: Impossible to drag and drop an active user tab when an unactive user tab with same name is open → Reuse/merge existing query view/object model after other user disconnects and reconnects
Version: unspecified → Trunk
Can we make sure that the whois commands that are run on first user tab open are run again when a message is displayed in a tab following a quit? I case that's not explained well, i mean like this: Query view for UserA opened. UserA: Hi UserA <chatzilla@DE939736.FE83B46F.91F48899.IP> “User Alpha” ... etc ... UserA has disconnected (Quit: Bye) UserA: I'm back! UserA <chatzilla@DE939736.FE83B46F.91F48899.IP> “User Alpha” ... etc ... I believe the two-tab thing is partially to make sure people don't connect using the same nickname and impersonate the former occupant of the nick - which hopefully this approach should help with.
You need to log in before you can comment on or make changes to this bug.