Closed Bug 666978 Opened 10 years ago Closed 10 years ago
Tree twisty in folder pane doesn't update when expanding
When expanding a row in the folder pane, the twisty isn't updated so it still looks like the collapsed twisty, not the expanded one. Once the mouse leaves that row, everything is back to normal. I'm not really sure what's happening here; everything is fine in the thread pane. It appears this also happens when hitting the right arrow to expand a row.
Confirmed on Tb5b2 with Win7 x64 (aero enabled).
This also seems to happen in XP (on a random Miramar nightly build from a month-ish ago), but not Linux (on trunk) so I'm guessing it has something to do with the implementation of tree twisties on Windows, since they're totally different from Linux.
Changing platform to "All" since this happens on Mac too. Some more fun facts: * If a folder is bolded because a subfolder has unread messages and you expand it, the boldness sticks around until you move your mouse (i.e. it changes at the same time as the tree twisty) * The twisties in the address book directory tree work, even after being de-RDFed. * This also exists in 3.1 (though 5.0 may have done something evil to my profile that's causing this)
OS: Windows 7 → All
(CCing Neil, in case it's a more generic XUL bug. I suspect it's not, but I don't think we've done anything particularly strange here recently.)
I *don't* see this on trunk TB 7.0a1 on Linux (x86_64) with KDE 4.4, thus a qute/aero issue? In this case, the platform field should go back to Windows.
Doesn't happen in the bookmarks window in Firefox, nor other trees in Thunderbird. If this is using a custom nsITreeView, then likely your implementation of toggleOpenState is only invalidating the child rows and not the parent row as well. (the index passed into toggleOpenState)
(In reply to comment #5) > I *don't* see this on trunk TB 7.0a1 on Linux (x86_64) with KDE 4.4, thus a > qute/aero issue? In this case, the platform field should go back to Windows. No, because it's also an issue on Mac.
Here's a patch to fix this. I'm leery of trying to test this (unless someone's got a brilliant idea about how to), since I'm not sure how to test things involving invalidation of the currently-painted window. (And I feel like that would be a lot of testing for a one line change! :)) (In reply to comment #6) > If this is using a custom nsITreeView, then likely your implementation of > toggleOpenState is only invalidating the child rows and not the parent row > as well. (the index passed into toggleOpenState) Looks like that was the cause. Thanks for the pointer!
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
Attachment #541776 - Flags: review?(dbienvenu)
> (comment #7) No, because it's also an issue on Mac. Sorry, you said so in comment #3 (I need to read previous comments better...)
Comment on attachment 541776 [details] [diff] [review] Invalid the current row when expanding yeah, it's hard to test invalidations...
Attachment #541776 - Flags: review?(dbienvenu) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 7.0
Attachment #541776 - Flags: approval-comm-aurora?
Attachment #541776 - Flags: approval-comm-aurora? → approval-comm-aurora+
Checked in on Aurora: http://hg.mozilla.org/releases/comm-aurora/rev/63e7cb634c4a
You need to log in before you can comment on or make changes to this bug.