Closed Bug 549577 Opened 14 years ago Closed 12 years ago

TB 3.0.3 Move Up/Down in Message Filters doesn't scroll selected filter into view

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Version:
1.9.2 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ishikawa, Unassigned)

Details

(Whiteboard: [CLOSEME 2012-09-15]) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

3.0.2 was OK.

3.0.3 is now buggy.

When there are many filter rules, and I want to move down a particular filter rule to the lower portion of this long list using [Down] button,
the repainting that occurs when the focused filter goes down the
lower edge of the shown screen is buggy.
Instead of scrolling up the whole list somewhat and placing the focused
item in the middle or somewhere in the visible area,
the repainted list goes back to the top of the list showing the
first filter rule as the top-most entry.

(I filed the description below [slightly edited to fix
my initial typo and additions] for Bug     , but was advised
to file a separate bug.

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 Down buttons causes window to scroll to top, and the
scrolling result 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 (it is way down by now t fit in the screen)!

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.

51805 Scrolling in Filter rules dialog too slow.

I think this could be is a re-paint problem: there must be some flakey
logic (to miss the flushing the last paint operation somewhere, for
example.  My reasoning is because the symptom differs from the SAME
machine operation and REMOTE operation. Such different behavior can be
explained by buggy re-paint problem IMHO or in the upper-level GUI
library possibly.)

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.  Especially for direct rendering behavior.
In both cases, I used ATI/AMD Radeon graphics adapter under linux
Xorg..

TIA

Reproducible: Always

Steps to Reproduce:
1. (You have to have a list of filter entries long enough not to be shown in the
   screenful at a time.)
2. Pick up a filter rule and try moving it down  the list by 
   pressing [Down] button so that the
   entry is about to be hidden in the invisible part of the current list.
3. When the entry crosses the lower-bottm boundary, the repainting of the
   filter list becomes unusable in that the focused filter is no longer visible.
   Instead the display shows the first filter in the list at the top of the
   screen: the focused filter is no longer visible because it is way down the
   list and not in the screen.

Actual Results:  
As is explained the focused filter is no longer visible in the screen and
GUI is practically unusable for placing the focused rule in an intended place.


Expected Results:  
The display should show the focused rule in the visible portion of the
list, i.e. in the screen somewhere (preferreably near the top during DOWN operation, and near the bottom during UP operation, but as far as it is visible
somewhere I am satisfied.)


As I have indicated, the problem may manifest differently
depending whether you are using TB3.0.3 remotely (the program executing
on a remote machine and you are accessing it from a remote X11 window system via LAN.) or not.
So the tester may need to check the both cases: using a local machine remotely even by using ssh -XC -YC username 127.0.0.1 just to test what I would call the remote operation if the tester doesn't have another machine to spare.)
Running TB3.0.3 on a local machine and accessing directly by invoking the program
from the shell may, most likely, use the Direct Rendering and this may
result in very different re-paint behavior of X11-based programs.
As long as the re-paint logic is correct, they should produce the same result, but often the difference of ordinary X11 library path and Direct Draw path
reveals painting logic flaw in the original program and produces different behavior.
In Bug 46115, I said

>> 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

But come to think of it, today, I upgraded TB 3.0.2 and TB 3.0.3, and noticed
the change [I re-tried the behaviors I noticed on a separate machine]
and so the external changes may play a role, but that will be a minor role.
Hmm...

The number of filters in the whole filter list.
The display driver.
The size of SCREEN device: this may affect the conditions to trigger the bug.
X11: local DirectDraw imaging vs remote X11 library drawing.
The factors that affect the drawing problem are so many.

TIA
I have filed another bug
 Bug 549623 : Sometimes choosing a filter rule doesn't give the item full dark highlighting.

That bug may be related this bug because the strange failure of proper high-lighting occurred after the chosen rule went down the bottom boundary and
the list re-display (re-positioning of the whole list) occurred.
Mea Culpa. 

Despite my initial comment that 3.0.2 was OK, I think 3.0.2 had a similar problem.
(I am running a few versions on different computers for testing purposes, and I get confused.)
Today, I tried to re-create the problem on another linux PC with TB 3.0.2 but could not re-create the problem. Very strange. So the version of TB (3.0.2, etc.)
may not be the only factor as pointed out in a post to Bug 46115.
Component: General → Filters
Product: Thunderbird → MailNews Core
QA Contact: general → filters
ISHIKAWA, so this is currently working for you?

I could not find bug 51805 Scrolling in Filter rules dialog too slow.
Dear Wayne,

The problem here is that of very poor performance.

The poor performance problem still exists today and I noticed that it exists
both under linux and window version.

The redrawing algorithm, or the redrawing routine performance itself,
after the rule is moved down and about to disappear across the bottom edge of
the screen and the resulting redrawing to bring this rule into view, is abysmal.

For that matter, the rule doesn't have to go across the border edge.

I can literally feel the scrolling and repainting on this 2.x GHz CPU.

Something is very wrong.

But again, you have to have a very longish list of filters.

If the filter names are not sensitive, I could capture the screen and show
how poorly the redrawing is done like somebody did.

The BUG  51805 ought to have read Bug 518305
>I could not find bug 51805 Scrolling in Filter rules dialog too slow.

I must have mistyped/misrecorded the bug number:
There was a correction  in 
https://bugzilla.mozilla.org/show_bug.cgi?id=461152#c18

(Too fat finger on a small happy hacking keyboard (tm) ?)

Bug 518305 is marked as dupe of bug 444793

Bug 444793 refers to Bug 571419
(I am not sure if disk I/O is slowing down the redrawing...)

The repainting reminds me of the slow speed of running vi on a slow 1200bps modem link :-)
This issue is fairly well known, at least to me :)  The filter list editor has never recovered from the de-rdfification rewrite, and the very poor performance for people with lots of filters is the result.

I'm not sure what the master bug for this is, but I would be surprised if it was not already listed somewhere.
(In reply to comment #6)
> I'm not sure what the master bug for this is, but I would be surprised if it
> was not already listed somewhere.

I'm not aware of filter perf bugs beyond what is listed above. 

But if you are thinking of an RDF bug, does one of these look likely?
https://bugzilla.mozilla.org/buglist.cgi?bug_id=105966%2C233238%2C298613%2C232725&bug_id_type=anyexact&query_format=advanced

note: I just phutzed with bug 444793 and getsatisfaction topics, and probably incorrectly associated one to 444793.
(In reply to comment #6)
> This issue is fairly well known, at least to me :)  The filter list editor has
> never recovered from the de-rdfification rewrite, and the very poor performance
> for people with lots of filters is the result.
> 

Where is this "filter list editor"?

Maybe I may want to take a look at the source code once the
temporary build problem (Bug 599577) is fixed on my PC.
This issue still exists in the 5th version. I select the first item, clicks "Shift" and click "Down" or Scroll Down with mouse. Some of the items (mostly middle) are not selected.
However, if I select the first item and the click PgDn sever time to reach end of the filter's list, then click on the last item with pressed "Shift" all the filter's items will be selected.
I've tried that in the SafeMode and nothing has changed.

UA: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0
I checked the operation today on TB 7.0.1 under Windows 7 64 bits, and the operation looks much saner. It seems to be a little non-smooth, but at least the strange re-painting or the really slow behavior is no longer there.
I will check the operation under linux tomorrow.
Can anybody make a screen video of this problem? I can't really imagine it.
ISHIKAWA, chiaki, is this something you could work on?

FWIW, the only other bug to report perf issue was recently closed WFM or incomplete (I forget which)
I believe I can certainly re-create the slow behavior under the old version of TB such as 3 (or 4?).
But I am not sure if the performance issue is still with the latest v8 under windows and also under linux.
Let me check this again under linux.
(In reply to :aceman (away 16.-21.) from comment #11)
> Can anybody make a screen video of this problem? I can't really imagine it.

OK, the problem doesn't seem to be in V8 of TB anymore.

But I am going to upload a captured video from a run of 3.1.16.

This is in order to explain what the problem was like, and the coder of the part of TB in question can figure out which changes have solved or at least hide the problem, I captured the screen image.

Setup:
I am not familiar with PC video thingy and all I could was
capture a video using a program called WINK on Windows7 and
capture the image of running TB version 3.1.16 (Serbian version.)
in VMplayer under that.
I could not find an older version other than 3.1.16 from the
usual download places.

I upload three files .htm, .js, .swf.
Place them in your temporary directory.
Somehow if you play .swf directly with a player, I don't get nice-looking screen due to resolution mismatch.
Best viewed by accessing .htm file using Firefox :-)

Observation:
Moving the filter from the top was not that interesting until it
goes across the bottom window boundary.
(The video also captures the problem of 
Bug 569623
Sometimes choosing a filter rule doesn't give the item full dark highlighting (when the filter was moved down to be the last item : this bug is present in V8 as well, BTW). 

Once the filter item is moved toward the end of the list, the
repainting becomes jaggy or taking time.

Once the filter item is moved up from the bottom, you will see
the strange repainting of the whole window content.

The filter list needs to be long to see the problem. 

Enjoy.

My video driver has an issue and the cursor is shown in a black rectangle, sorry about it.

So unless the coder of the filter handling thinks the problem
is simply dormant and may appear again, the status can be set to
resolved for V8 now.
> (The video also captures the problem of 
> Bug 569623

I meant to say Bug 549623

> Sometimes choosing a filter rule doesn't give the item full dark
> highlighting (when the filter was moved down to be the last item : this bug
> is present in V8 as well, BTW). 

The video was too large to upload to bugzilla.

Here is the link where you can pick up three files I mentioned
in my post above.

https://skydrive.live.com/?cid=6DEDB2E2AA1FE2D5&id=6DEDB2E2AA1FE2D5!132&sc=documents

The video doesn't somehow show the long time it takes
for re-painting when the filter is moved from the bottom
toward the beginning. Maybe the time is proportional to
the list length, and if you have several dozen filters,
you are doomed with 3.1.x.

V8 no longer shows the same slow and wasteful repainting.
The bug is still exists in TB-8 under linux (I don't check under windows).
A big number of filters list... Scroll fast with mouse till end and click Shift+Mouse Left click on the last item. Scroll back to top with mouse and you can see unchecked items.
Vitaly, I am not sure the problem you describe is the same as the original problem in comment 0 reported by Ishikawa. You talk about selecting all filters where not all of them get selected.
Ishikawa is using the "Move down" bottom and the one selected filter is moving out of view for him. That is completelly different. But I haven't seen the video yet, maybe I am mistaken.
I try three ways to move down the list (to select all the items):
 - select the first item, scroll down using mouse and click on the last item with Shift
 - select the first item, press Shift+Crtl+End
 - select the first item, press Shift+Ctrl+PgDn (until rich end of the list)

Only the third way works. The other ways don't select all of the list items.
ISHIKAWA, chiaki, I think you mentioned the problem is no longer existing in TB8. Is that true? Can we close this WFM?
Whiteboard: [CLOSEME 2012-09-15]
Version: unspecified → 1.9.2 Branch
The issue, described by me is still exists. I work with TB14.
To check it I've just done the steps listed in my "Comment 18".
Vitaly, I understand that, but your problem does not belong into this bug.
Can you please create a new bug for your problem? I will immediately confirm it as I remember seeing that problem on my machine.
(In reply to :aceman from comment #19)
> ISHIKAWA, chiaki, I think you mentioned the problem is no longer existing in
> TB8. Is that true? Can we close this WFM?

Responding to comment #19,
yes the bug is gone.
Both Windows 7 64 bit version, and linux version do not show the old
strange behavior any more. Thanks!
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.