455802 - [Filters] RunNow becomes broken as number of filters increases.

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[David A. Cobb]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1
Build Identifier: nightly/2008/09/2008-09-12-03-comm-central

That's a funny way to have to write it up!  But it is exactly what I've observed.

Starting fresh (after a disk disaster), I could build a filter and run it on the Inbox immediately.
At some point, as the number of filters increased, RunNow became a no-op.  The disk doesn't light up, nothing visible happens at all.

Reproducible: Always

Steps to Reproduce:
1. Create filters, create LOTS of filters.
2. As you build each one, do RunNow and verify that the right things are moved.

Actual Results:  
At some point, RunNow ceases to operate.


Labeling "Normal" because I can work around it at some inconvenience by doing a Search.  This is not really equivalent because I cannot, say, Copy or Tag messages from the Search dialog [that's another enhancement].

If it's meaningful, I'm now up over 200 filters again.

Comment 1

[Magnus Melin [:mkmelin]]

Do you see it on 2.0 too?

Comment 2

[Kent James (:rkent)]

I've traced out a bug, a regression from bug 422474, that landed 2008-05-26, and causes behaviour similar to this. I'm trying to decide whether to hijack this bug, or file another one.

The problem is in RunSelectedFilters in FilterListDialog.js at this code:

  for each (var item in list.selectedItems) {
    filterList.insertFilterAt(list.getIndexOfItem(item), item._filter);
  }

You can't insert an item past the current length of the array in the filter list. So if you select some filters to run, you must select all of the filters starting at the top of the list, otherwise any filters that are selected past a gap in the list will not run. Hmmm, hard to explain.

STR:

1) Create two filters
2) select the second filter, and try to apply it to a folder.
3) that filter will not run.

This applies to TB trunk builds after 2008-05-26. SM uses a different FilstListDialog.js, and should not show the problem.

So, is this your bug, or should I file another one?

Comment 3

[Kent James (:rkent)]

Attachment: Add variable to index filter list [Checkin: Comment 5]

Assumming I hijack the bug, here is the proposed fix.

Comment 4

[David :Bienvenu]

Comment on attachment 339582 [details] [diff] [review]
Add variable to index filter list
[Checkin: Comment 5]

thx, Kent.

Comment 5

[Serge Gautherie (:sgautherie)]

Comment on attachment 339582 [details] [diff] [review]
Add variable to index filter list
[Checkin: Comment 5]

http://hg.mozilla.org/comm-central/rev/84b4e8431ca3

Comment 6

[David A. Cobb]

(In reply to comment #2)
> I've traced out a bug, a regression from bug 422474, that landed 2008-05-26,
> Hmmm, hard to explain.
> 

Not at all, that's clear to me.

Sadly, my bug does not require to select more than one bug.  IF IT MATTERS, I'm seeing it on *new* filters.  I'll need to do some testing to see whether it goes for previously existing ones.

Sorry for taking so long to reply.  Work is the curse of the thinking class.

Comment 7

[David A. Cobb]

I'm happy to confirm that the bug is gone in 2008-09-26-comm-central.

Comment 8

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)
> This applies to TB trunk builds after 2008-05-26. SM uses a different
> FilstListDialog.js, and should not show the problem.

Ftr,
I confirm that SeaMonkey still has bug 180239 code, so did/do not have this regression.