549542 - "creating a filter based on message" doesn't display the filter immediately.

Status: RESOLVED DUPLICATE of bug 543419

(MailNews Core :: Filters, defect)

Description

[ISHIKAWA, Chiaki]

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

TB 3.0.3

TB 3.0.2 was OK, I think.

The operation of creating a filter based on an existing message invoked
by
message -> creating a filter based on the message
seems to CREATE the filter in its internal database, but the
created filter is NOT displayed immediately on the top of the list
of filters immediately.

Only when a new filter is created using the sequence
Tools -> filter -> NEW 
and this new filter rule is displayed at the
top of the list of the filters, the
previously created filter mentioned above is
displayed as the second entry.

VERY CONFUSING and troublesome.



Reproducible: Always

Steps to Reproduce:
1. Creating a filter based on the message using messages -> create ... -> then create.
2. The user doesn't see the created filter at the top of the list.
3. Only after a new filter is generated, the previously created filter is
   displayed in the list as the second entry. DELAYED DISPLAY, so to speak.
Actual Results:  
The filter seems to be created, but its existence is not
shown until another new filter is created.

Expected Results:  
The newly created filter should be displayed immediately at the top of the filter list immediately.

Comment 1

[ISHIKAWA, Chiaki]

I have added a comment to an existing bug at the same time:

 Bug 461152 -  Move Up/Down in Message Filters doesn't scroll selected filter into view

It may be possible that the non-immediate display is caused by forgetting to
refresh the display in the execution path "messages -> creating a filter ..."
while the "tools -> filter -> NEW ..." path takes care of the re-display correctly(?) 

The current failure to display the created filter is very
confusing and buggy.

Comment 2

[ISHIKAWA, Chiaki]

 Bug 266314 -  The "Filter Rules" window doesn't render completely. Resizing window corrects problem.

This may be related, but it is too old, about 5 years, to re-consider (?).

Comment 3

[Ludovic Hirlimann [:Usul]]

(In reply to comment #0)
> 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
> 
> TB 3.0.3
> 
> TB 3.0.2 was OK, I think.
> 

Can you double check that ? and if that's the case can you find the regression window ?

Comment 4

[ISHIKAWA, Chiaki]

> Can you double check that ? and if that's the case can you find the regression
> window ?

You mean to figure out where the bug appeared in which version?

Comment 5

[ISHIKAWA, Chiaki]

Ok, as I tried to re-create the problem on my PC, I found a pre-condition for the
bug.

1st: You have to display the filter list by [Tools] -> [Filter]

Filter list is displayed on the screen. Leave it as it is. This is the key.

Now, try creating the filter based on the message as I explained above.

Again, it doesn't show up in the filter list (which was staying on the
different part of the screen.)
Only after I create another filter which is now shown in the top-most slot, 
and the previously created filter based on the message does show up as the
second entry.

*IF* I have not shown the filter list in advance, or
erase the filter list, and try the message-based creation sequence without the
filter list present on the screen in advance, the filter list is now displayed after the creation and the newly created filter based on the message is shown at the top.

So this is clearly a problem of refreshing or repainting of the filter list
that does not reflect the internal change of the list when the filter list
is already shown on the screen.

I will investigate where this bug creeps in, but in the meantime, I hope the
above ramification of the bug may help someone to investigate the cause.

Comment 6

[ISHIKAWA, Chiaki]

OK, I found out that actually TB3.0 (yes, 3.0) suffered from the same problem.
(Under Linux)

I thought prematurely that TB3.0.2 was OK when I, now I think, 
tested it WITHOUT having the filter list shown on the screen in advance as I explained in comment 5.
Without the filter list present on the screen, the newly displayed list shows
the newly created item at the beginning. 

When I tested TB3.0 with and without the filter list shown on the screen,
it *DID* fail to update the filter list when the filter list was already on the screen.

So I think the problem is with 3.0, ..., 3.0.3 all the way through.

Sorry for the confusion.

Comment 7

[Ludovic Hirlimann [:Usul]]

(In reply to comment #4)
> > Can you double check that ? and if that's the case can you find the regression
> > window ?
> 
> You mean to figure out where the bug appeared in which version?

Yes that's what I meant.

confirming on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.2pre) Gecko/20100321 Lanikai/3.1b2pre.

Comment 8

[Kent James (:rkent)]

"Major" is too severe for this bug.

Comment 9

[Wayne Mery (:wsmwk)]

I have mixed results with v3.1
I can reliably reproduce if Message Filters is open, and account A is selected in the filter window, and the filter being created is from a message in an other than account A.

Comment 10

[Wayne Mery (:wsmwk)]

does this now work for everyone else?

I think it got fixed in acelist's patches.
WFM using current trunk and combination of steps from comment 9 and comment 0

Comment 11

[:aceman]

Surely looks a lot like bug 543419.
DUPE?