Closed Bug 497643 Opened 15 years ago Closed 9 years ago

With View > Sort by > Grouped by Sort enabled, clicking on column header of current sort (e.g. date) has row invalidation problems in message list (doesn't update / refresh screen)

Categories

(Thunderbird :: Folder and Message Lists, defect)

defect
Not set
normal

Tracking

(blocking-thunderbird3.1 -)

RESOLVED FIXED
Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: thomas8, Unassigned)

References

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [fixed by bug 1192838])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090608 Shredder/3.0b3pre

Following the steps below will lead to screen update problems and mess up the message list.




Reproducible: Always

Steps to Reproduce:
1. For a given mail folder (subfolder of inbox, in my test case), sorted by Date, newest on top, enable View > Group by Sort G.

Result1: mails are correctly sorted and grouped into Today, Yesterday etc.

2. Now click on Date Column header, expecting to change sort order to oldest first. Important: Do not move the mouse pointer out of the grey date column header area where you clicked.

Actual Results:  
Result2: Nothing changes (bug). Message list stays as after step 1 (see result 1).

3. Now move your mouse from the column header downward and hover downwards over the first messages in the list. Take it slow (one by one). Watch.

Result3: Message list (screen) updates only those items that are hovered over (bug). 

Expected Results:  
Message list should be resorted in some way, completely and immediately as soon as mouse click event happenend on the column header (ideally, grouped sorting should stay but sort order should change, e.g. from newest first to oldest first in this case)

Similar to, but IMO not a duplicate of
Bug 480392 -  Changing "Grouped by Sort" to "Unthreaded" does not remove "Grouped by Sort" UI elements from the tree view
This is probably due to lag time in generation of message summaries. Thomas, how many messages do you have when you saw this problem?
It's only 12 messages and 200 KB altogether in the respective test folder.
Besides, when you don't hover over messages, sort order will never change no matter how long you wait. So this is NOT due to lag time. Please use detailed steps above to reproduce and confirm this bug.
Confirmed on linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3+
OS: Windows XP → All
Hardware: x86 → All
Summary: With View > Grouped by Sort G enabled, clicking on date column header has screen update problems in message list → With View > Grouped by Sort G enabled, clicking on date column header has row invalidation problems in message list
The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a
result, we feel that this bug shouldn't stand in the way of all the other good
work getting into the hands of users sooner rather than later. Therefore we are
retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242
for more details. The 3.1 release is expected to be a quick release soon after
Thunderbird 3.
Flags: blocking-thunderbird3.1+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
This should be checked if still occuring after fix for bug 517467 now landed
Looks to be working over here.
Magnus, which OS? Did you follow the steps exactly?

Unfortunately, this bug is still present, and the potential for confusion is quite high.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091110 Shredder/3.0pre

STR addition: obviously, after step 1 you have to expand some of the group header rows to see messages listed in rows. After clicking on Date header to reverse the sorting, those message rows will only update when you hover over them.
Linux. Ah, the groups were open for me. 

After some clicking to expand i get this though, and it won't expand
Error: uncaught exception: [Exception... "Component returned failure code: 0x80550008 [nsITreeView.toggleOpenState]"  nsresult: "0x80550008 (<unknown>)"  location: "JS frame :: chrome://global/content/bindings/tree.xml :: changeOpenState :: line 228"  data: no]
My assumption is that this is a regression from the front-end refactoring, so I'm adding asuth in case he has an idea what might be going on here.  I don't actually know that that's what caused the regression, so adding regression-window wanted as well, in the hopes that someone from QA-land can verify whether my assumption is actually true.

This seems like a somewhat unusual set of steps to reproduce, and we don't have a lot of people complaining about it, so if this were the last bug standing, I suspect we wouldn't hold Thunderbird 3.1 for it, so setting blocking-.  If that thinking is wrong-headed, please tell me well.
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1+ → wanted-thunderbird+
I could not reproduce with the build Thomas used but I could with others. I tracked what seems like the exact same issue down to this range.

The changesets I got are from mozilla-central. Aren't you building off of comm-central or am I misunderstanding?

It would be good if Thomas confirms the issue and range I got.

STR:
1. Had multiple IMAP accounts
2. Used an Inbox with View "Sorted by" "Date", "Descending", and "Threaded"
3. Change "Sort by" to "Grouped by Sort"
4. Change "Sort by" to "Ascending" by clicking on "Date" column
5. Mouse over emails
6. Emails sort to "Ascending" as each one is moused over

Tentative regression range:

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090913 Shredder/3.1a1pre
http://hg.mozilla.org/mozilla-central/rev/bf0fdec8f43b

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090914 Shredder/3.1a1pre
http://hg.mozilla.org/mozilla-central/rev/912c6ae3b70c

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf0fdec8f43b&tochange=912c6ae3b70c
(In reply to comment #10)

Matt, thanks for looking into this!

> I could not reproduce with the build Thomas used but I could with others.

Strange.

>I tracked what seems like the exact same issue down to this range.
> The changesets I got are from mozilla-central. Aren't you building off of
> comm-central or am I misunderstanding?

If that's a question to me, I'm not building from anything, only downloads and automatical upgrades for Shredder.

> It would be good if Thomas confirms the issue and range I got.
> STR:
> 1. Had multiple IMAP accounts
> 2. Used an Inbox with View "Sorted by" "Date", "Descending", and "Threaded"
> 3. Change "Sort by" to "Grouped by Sort"
> 4. Change "Sort by" to "Ascending" by clicking on "Date" column
> 5. Mouse over emails
> 6. Emails sort to "Ascending" as each one is moused over

I didn't use Step 1; otherwise:
Confirming above steps for
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100221 Shredder/3.0.3pre

So that's a different and lower version ("branch"?), compared to what Matt reported. So I don't think the regression range of comment 10 is right. But then I don't fully understand the versioning system and interconnections.
Further indication for different regression range is the version against which I reported this in comment 0, which was also broken before Matt's range.

Another thing I noticed when trying to reproduce is that it didn't happen all the time, and I'm pretty (85%) sure I followed the steps exactly as Matt's.
So *maybe* steps need more refinement, or perhaps I overlooked something or looked in the wrong place (I'm not very deep into this right now).
(In reply to comment #12)
So, you do not use the changesets from "about:buildconfig" in thunderbird to find the pushlog range. You just go by the date, correct?

(In reply to comment #11)
> > I could not reproduce with the build Thomas used but I could with others.
> 
> Strange.
Regression range could change with OS.
(In reply to comment #13)
> (In reply to comment #12)
> So, you do not use the changesets from "about:buildconfig" in thunderbird to
> find the pushlog range. You just go by the date, correct?

That's what i did yes. (I don't know the changeset ids.)
Summary: With View > Grouped by Sort G enabled, clicking on date column header has row invalidation problems in message list → With View > Sort by > Grouped by Sort enabled, clicking on date column header has row invalidation problems in message list (doesn't update / refresh screen)
Still confirming for TB12.0.1/WinXP, per STR of comment 0.
similar to (dupe of?) bug 471928
"Group by sort" and changing sort order still broken in Thunderbird 14/15/16 and even 17a2

Please, correct this
 :(
(In reply to Dricks from comment #18)
> "Group by sort" and changing sort order still broken in Thunderbird 14/15/16
> and even 17a2
...and it's not limited to "Date" column, pick any column to sort by (in non-grouped mode), then Group by Sort, click currently sorted column header without moving mouse away -> message list grouped sort order is not reverted. Hover mouse from top to bottom of message list slowly and watch how rows update under the mouse, kinda manual screen refresh, and kinda confusing.

Oh, and btw, ensure for each reproduction that "group by sort" is really enabled, and it'll only work on the header of the currently sorted column used for grouped sorting, because we automatically return to other non-grouped modes (threaded/unthreaded) if you click a different column header.
Summary: With View > Sort by > Grouped by Sort enabled, clicking on date column header has row invalidation problems in message list (doesn't update / refresh screen) → With View > Sort by > Grouped by Sort enabled, clicking on column header of current sort (e.g. date) has row invalidation problems in message list (doesn't update / refresh screen)
Aceman, this little bugger has precise steps, and I think it's just a single line of code missing somewhere to force the screen update of message list when "grouped by sort" is enabled and you want to toggle order of current sort from grouped-ascending to grouped-descending or vice versa (where the updating of message list tree currently happens only on hovering the message list manually, but then it happens correctly). I think this bug is waiting for you. :)
Yes I do see the bug. But I can't fix these kinds of problems yet.

If the regression range from comment 10 is correct then this commit looks suspicious:
http://hg.mozilla.org/mozilla-central/rev/eda2433181c9 (just from the description and guesswork).

Neil Deakin is the autor, maybe he could comment. I also CC the reviewers of that patch.
Unlikely. Since the thread pane is using a custom treeview, updating on sort should be done by Thunderbird code. You need to find a regression range from there and not in mozilla-central.
I also do not see anything relevant in comm-central log from that time: http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-09-12&enddate=2009-09-14

Thomas, Wayne, can you test it and confirm the regression range from comment 10?
See Also: → 905644
This bug is still present in version 24.6.0
view > Sort by > From, Ascending and Group by Sort.

Sorts From with A at top, but unfortunately also sorts the sub set by oldest email on top.

Select to change Ascending to DEscending keeping all other selection results in no change until you hover over the entire list. Then names are in reverse order, Z at top, but at least the dates are now with newset on top. So this bug is still eveident in the latest release.

Unfortunately it seems to be impossible to sort by FRom in Ascending order but maintain my default setting of Date in descending - but that's another issue.
Depends on: 1192838
Fixed in Bug 1192838 and friends.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 1192838]
You need to log in before you can comment on or make changes to this bug.