User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/2008092417 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3 I have many filters (more than one window full). When I use Move Down and the filter I'm moving scrolls down and out of the window, I'm now "flying blind" and I can't see where the filter is being moved to. I can find it using the scroll bar (but it's no longer highlighted) and select it again, but as soon as I "Move Down", the windows resets to the top of the filter list and I'm "flying blind" again. Reproducible: Always Steps to Reproduce: See Details above Actual Results: See Details above Expected Results: Same as Thunderbird 2.0.x - window should scroll, "active" filter being moved should stay highlighted and visible.
Confirmed on linux/trunk.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Move Up/Down in Message Filters doesn't display properly → Move Up/Down in Message Filters doesn't scroll selected filter into view
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090404 Lightning/1.0pre Shredder/3.1a1pre ID:20090419051533 I think bug 373075 is similar plus confirming on latest 3.1 nightlies. In order to see this, you need to have enough filters to fill the listbox beyond its height and so that the scrollbar appears on the right side of the listbox. I think the bug's description should change to: 'Moving Message Filters Up/Down doesn't scroll *with* selected filter into view. Scrollbar resets to top of the listbox each time.' ... or something.
Some other bugs dealing with Message Filters dialog and the listbox that contains the filters: Bug 358641 - Allow drag and drop for message filters Bug 363411 - Message filters: Scroll position resets on filter name change Bug 373075 - awkward scrolling in message filter window on move up/move down (mentioned above). All of then have to do with scrolling and positioning of the message filters.
Component: Search → Filters
Product: Thunderbird → MailNews Core
QA Contact: search → filters
This regression from 2.0 should have been examined before release of 3.0 If fixed, it should go on the branch.
Assignee: nobody → kent
Status: NEW → ASSIGNED
blocking-thunderbird3.0: --- → ?
Created attachment 419498 [details] [diff] [review] ensure visible In addition to the bare minimum ensureElementIsVisible call, this cleans up a couple of other minor issues as well: 1) It keeps the scroll position rather than always just resetting it to the top after a filter move. 2) In multiple selection, after a filter move keyboard extension of selection was failing due to a caching issue in listbox.xml. We work around that here.
Attachment #419498 - Flags: review?(mkmelin+mozilla)
Comment on attachment 419498 [details] [diff] [review] ensure visible >+ // range at _selectionStart. The old value though is now obsolete, >+ // since we will recreate all of the elements. We need to clear Please drop the "though". There's a bit of jumping, but all in all it's still an improvement. r=mkmelin
Attachment #419498 - Flags: review?(mkmelin+mozilla) → review+
Comment on attachment 419498 [details] [diff] [review] ensure visible Checked in http://hg.mozilla.org/comm-central/rev/57a3752779a0
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Attachment #419498 - Flags: approval-thunderbird3.0.1?
Whilst I can see the regression as an annoyance, the work around is simple and this doesn't actually break anything. Therefore not blocking a 3.0.x release, but is wanted. I'll consider the patch for approval later.
blocking-thunderbird3.0: ? → -
status-thunderbird3.0: --- → wanted
Attachment #419498 - Flags: approval-thunderbird3.0.1? → approval-thunderbird3.0.1+
Landed on 1.9.1 as <http://hg.mozilla.org/releases/comm-1.9.1/rev/12ee7b2efc8e>.
Whiteboard: [needs 3.0 approval]
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:188.8.131.52) Gecko/20100110 Shredder/3.0.1pre
Status: RESOLVED → VERIFIED
9 years ago
I am afraid that this problem has returned in a somewhat subtle manner in the latest 3.0.3. I am using TB 3.0.x under linux (mostly Debian Gnu/Linux). 3.0.2 was OK With 3.0.3, running TB3 over LAN, TB3 running on a linux PC, and showing the display on another X11 window, when I move down a filter, the re-display seems to work very strangely: it is as if the item goes down the lower boundary of the window pane, and suddenly the whole list is moved DOWN(!), not down, the upper portion becoming blank, (by block scroll) and then the whole screen is re-drawn from top to bottom (or the lower portion is scrolled UP and the remaining is redrawn. The same effect.). This is observable due to the delay/latency caused by LAN connection. But the problem with the DIRECT draw where TB3.0.3 is used on the same machine where the X console terminal is on the same machine is very problematic and renders the filter down/up operation inoperative. It is very difficult to explain, but the most similar symptom I could find in this bugzilla is this 461152 and "Bug 538864", Message Filters window - Using Up and Down buttons causes window to scroll to top, in that the scrolling shows I think it is a re-paint problem: there must be some logic (to miss the flushing the last paint operation somewhere. The reason the symptom differs from the SAME machine operation and REMOTE operation can be explained by this IMHO. Please note that the symptom is different on a remote usage and local usage and testing under both conditions is necessary. Also, the display driver (for local, direct rendering) may have something to do. In both cases, I used ATI/AMD Radeon graphics adapter.
>Using Up and Down buttons causes window to scroll to top, in that >the scrolling shows I meant to write that the resulting scrolling goes back to the original display in that the top-most filter is the FIRST filter and the filter I was trying to move is no longer visible! There seems to be a few other scroll (update problem). I don't know if they are related, but they seem to point that the redisplay code may have some issues. 51836 Scrolling in Filter rules dialog too slow. TIA
Typo of the bug number. NOT 51836 -> 518305 Bug 518305 - Scrolling in Filter rules dialog is too slow Summary: Scrolling in Filter rules dialog is too slow
(In reply to comment #16) > I am afraid that this problem has returned in a somewhat subtle manner in the > latest 3.0.3. > > I am using TB 3.0.x under linux (mostly Debian Gnu/Linux). > > 3.0.2 was OK > > With 3.0.3, Please can you file this under a separate bug. Whilst it may seem like the same issue, this has been marked as fixed since .1. I can also tell you that between .2 and .3 the only change in the Thunderbird source code was to correct Local Folders/Accounts from being lost from the display. Hence I very much doubt that your issue has returned as a result of the upgrade.
(In reply to comment #19) > > [... snip ...] > > Please can you file this under a separate bug. Whilst it may seem like the same > issue, this has been marked as fixed since .1. > I did: Bug 549577 - TB 3.0.3 Move Up/Down in Message Filters doesn't scroll selected filter into view > I can also tell you that between .2 and .3 the only change in the Thunderbird > source code was to correct Local Folders/Accounts from being lost from the > display. Hence I very much doubt that your issue has returned as a result of > the upgrade. Hmm, then possibly the problem with the upgrade of GUI middleware/X11 library, etc. under Debian GNU/Linux lately? But I will follow this up in Bug 549577 TIA
This fix is in TB 3.0, and as a result it is now VERY, horrendously slow to add a new filter to my list (and scroll it down the hundreds of lines to where it belongs) because TB now stops to repaint the list after every single one-line move. Is there an option setting to delay the repaints until explicitly asked for (by a "refresh" button or similar)? If not, please create it.
I tested this with 100 filters on my slow XP system, and I was able to scroll the filter down about two lines per second. While not exactly speedy, I don't think that is unacceptable behavior. The root cause of your issue is "scroll it down the hundreds of lines" which is done by selecting down hundreds of times. I would agree that is far from ideal, and so the filter list editor is really not very suitable for use for people with hundreds of filters. But I don't think that the correct solution is to reverse the fix of this bug.
You need to log in before you can comment on or make changes to this bug.