392330 - thread pane sometimes doesn't match focused tab

Status: RESOLVED FIXED

(Thunderbird :: Toolbars and Tabs, defect, P3)

Description

[Wayne Mery (:wsmwk)]

Attachment: Thread pane doesn't match focused tab

version 3.0a1pre (2007081410)
Thread pane sometimes doesn't match focused tab after switching tabs...
Has happened more than once but don't have reproducible STR  (perhaps when one is a newsgroup?)

In the screen shot, tab2=inbox account#1 is focused.
Folder pane and message preview pane are correct, but thread pane shown is tab1's.
Tab1 in this case is newsgroup m.d.super-review.

And (wrong) threadpane folder persists when clicking folders under account#1.
Example, I clicked trash just after this screen shot, hit delete, and I know it didn't change to trash folder because it said I couldn't "cancel the articles".

Comment 1

[Wayne Mery (:wsmwk)]

here are the steps to reproduce -- and what you see (**=anomalies):
1. imap inbox, view=all
2. right click a newsgroup which already is set to view=unread
3. select "open in new tab" -- ng displays OK
4. click inbox tab -- threadpane=inbox, **view=unread, **folder=newsgroup, 
5. click drafts folder -- view=all, folder=drafts, **threadpane=newsgroup
6. click inbox folder -- all is OK

Comment 2

[Magnus Melin [:mkmelin]]

Yep, linux too.

Comment 3

[Wayne Mery (:wsmwk)]

If we suggest in release notes that Tabbed is a major new feature for 3.0a1, this probably should be fixed. 

Particularly, if one objective is to get people to constantly use trunk/alpha, not just try it and immediately go back to 2.0.  We need extended participation in order to increase quality.

Perhaps not blocking, but certainly thunderbird-wanted3.0a1

Comment 4

[Wayne Mery (:wsmwk)]

per above

Comment 5

[David Ascher (:davida)]

tweaking flags -- i don't think this would block a2, but we want to get the tab story straight.  adding whiteboard "tabs" marker to facilitate review of all the related bugs together.

Comment 6

[David :Bienvenu]

I'm gonna look at this - maybe Andrew already fixed it.

Comment 7

[David :Bienvenu]

sadly, this is worse than before - right click selects the folder/newsgroup in the original tab, so that needs to be fixed first.

Comment 8

[David :Bienvenu]

this is wfm for me now; can you just verify, Wayne? - the previous comment about right click had to do with the de-rdf folder pane.

Comment 9

[Philip Chee]

Do we know what changed? If only to know how to prevent regressions.

Comment 10

[David :Bienvenu]

as I mentioned before, Andrew probably already fixed this when he redid a lot of the tab stuff.

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to comment #1)
> here are the steps to reproduce -- and what you see (**=anomalies):
> 1. imap inbox, view=all
> 2. right click a newsgroup which already is set to view=unread
> 3. select "open in new tab" -- ng displays OK
> 4. click inbox tab -- threadpane=inbox, **view=unread, **folder=newsgroup, 
> 5. click drafts folder -- view=all, folder=drafts, **threadpane=newsgroup
> 6. click inbox folder -- all is OK

reopening still see the problem - no change

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081110 Shredder/3.0b1pre and 20081104

Comment 12

[Wayne Mery (:wsmwk)]

also well in evidence on a different machine with expmess, closed a tab and the thread pane shown was not a match to the tab.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081111 Shredder/3.0b1pre

Comment 13

[David :Bienvenu]

Attachment: fix several tab issues, including this one

this fixes this bug (which is basically that the view picker doesn't get updated when we switch tabs), and bugs having to do with switching to tabs open on account central. 

The sr is only for the mailviews part. I broke out a utility function to get the label for a value...

Comment 14

[Mark Banner (:standard8)]

Comment on attachment 348512 [details] [diff] [review]
fix several tab issues, including this one

 function ViewChangeByValue(aValue)
 {
+  ViewChange(aValue, GetLabelForValue(aValue));
+}
+
+
+function ViewChangeByFolder(aFolder)
+{

nit: we only need one blank line between these functions.

Otherwise, much nicer.

Comment 15

[David :Bienvenu]

fix checked in - changeset:   1128:f15f33e40beb

I don't see a bug for the account central issue, but if there is one, it should be marked fix. I think it might have just been discovered during the new folder pane landing testing, but not filed separately.

Comment 17

[Wayne Mery (:wsmwk)]

I still have trouble using the steps in comment 1, i.e. using a newsgroup.  see failure at step 5. reopening

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090202 Shredder/3.0b2pre

Comment 18

[Bryan Clark (DevTools PM) [:clarkbw]]

Placing in the right component, leaving as blocking for now... though I'm unsure that's still the case.

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

If this is at all easily reproducible, I think it would have to block: it seems like a serious usability problem.

Comment 20

[Dan Mosedale (:dmosedale, :dmose)]

I can't reproduce this using the steps in comment.  Minusing for now.  If we can get more concrete STR and/or start to believe that it happens frequently, please re-nominate.

Wayne, how often is reproducible for you?

Comment 21

[Wayne Mery (:wsmwk)]

Easily reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090201 Shredder/3.0b2pre, which is approx what I used in comment 17.  But I can't reproduce using ~current nightly - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090228 Shredder/3.0b3pre

So something else checked in that affected this. But, not sure we are totally out of the woods, seems to me in recent days I have seen similar cases that involve quick search, but I'm not sure if tabs are involved. Needs further checking.

Close FIXED if you think it's most appropriate and I will file any further issues in new bugs.

Comment 22

[Dan Mosedale (:dmosedale, :dmose)]

New bugs sounds simpler to me; people don't have to wade through existing content to follow them.  Resolving.