thread pane sometimes doesn't match focused tab

RESOLVED FIXED in Thunderbird 3.0b3

Status

Thunderbird
Toolbars and Tabs
P3
normal
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: wsmwk, Assigned: Bienvenu)

Tracking

(Blocks: 1 bug, {qawanted})

Trunk
Thunderbird 3.0b3
qawanted
Dependency tree / graph
Bug Flags:
blocking-thunderbird3.0a2 -
blocking-thunderbird3 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Created attachment 276785 [details]
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".
(Reporter)

Comment 1

10 years ago
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

10 years ago
Yep, linux too.
OS: Windows XP → All
Hardware: PC → All
(Reporter)

Comment 3

10 years ago
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
Flags: wanted-thunderbird3.0a1?
(Reporter)

Comment 4

10 years ago
per above
Flags: wanted-thunderbird3.0a1? → blocking-thunderbird3.0a2?
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.
Flags: blocking-thunderbird3.0a2?
Flags: blocking-thunderbird3.0a2-
Flags: blocking-thunderbird3+
Whiteboard: tabs

Updated

9 years ago
Priority: -- → P3
Target Milestone: --- → Thunderbird 3.0b2
(Assignee)

Comment 6

9 years ago
I'm gonna look at this - maybe Andrew already fixed it.
Assignee: nobody → bienvenu
(Assignee)

Comment 7

9 years ago
sadly, this is worse than before - right click selects the folder/newsgroup in the original tab, so that needs to be fixed first.
Blocks: 463395
(Assignee)

Comment 8

9 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME

Comment 9

9 years ago
Do we know what changed? If only to know how to prevent regressions.
(Assignee)

Comment 10

9 years ago
as I mentioned before, Andrew probably already fixed this when he redid a lot of the tab stuff.
(Reporter)

Comment 11

9 years ago
(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
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 12

9 years ago
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
(Assignee)

Comment 13

9 years ago
Created attachment 348512 [details] [diff] [review]
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...
Attachment #348512 - Flags: superreview?(bugzilla)
Attachment #348512 - Flags: review?(bugzilla)
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.
Attachment #348512 - Flags: superreview?(bugzilla)
Attachment #348512 - Flags: superreview+
Attachment #348512 - Flags: review?(bugzilla)
Attachment #348512 - Flags: review+
(Assignee)

Comment 15

9 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
(Assignee)

Updated

9 years ago
Duplicate of this bug: 463395
(Reporter)

Comment 17

9 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Placing in the right component, leaving as blocking for now... though I'm unsure that's still the case.
Component: Mail Window Front End → Toolbars and Tabs
QA Contact: front-end → toolbars-tabs
Whiteboard: tabs
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b3
If this is at all easily reproducible, I think it would have to block: it seems like a serious usability problem.
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?
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Keywords: qawanted
(Reporter)

Comment 21

9 years ago
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.
New bugs sounds simpler to me; people don't have to wade through existing content to follow them.  Resolving.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.