459318 - Reuse/merge existing query view/object model after other user disconnects and reconnects

Status: RESOLVED INCOMPLETE

(Other Applications Graveyard :: ChatZilla, defect)

Description

[worms]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080715 Ubuntu/7.10 (gutsy) Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080715 Ubuntu/7.10 (gutsy) Firefox/2.0.0.16

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 [e-mail] at first, and came back as [e-mail], 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

Comment 1

[James Ross]

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).

Comment 2

[worms]

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++

Comment 3

[James Ross]

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.

Comment 4

[Glen Mailer]

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 <[e-mail]> “User Alpha” ... etc ...
UserA has disconnected (Quit: Bye)
UserA: I'm back!
UserA <[e-mail]> “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.