78429 - Search/Filter UI: Status/Priority criteria doesn't display any default value

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[laurel]

Using may01 commercial trunk build

The Status criteria choice in Search Messages UI doesn't show a default value.

1.  From mail window, Search|Search Mail/News Messages.
2.  Select Status as criteria. The operator/2nd dropdown changes to default Is
and the value/3rd field changes to dropdown for fixed value list, but the
default value display is blank. If the value list is pulled down, it appears
that Replied is selected (4.x defaults to Read), but doesn't display as selected
until you select another value then select Replied again.

Result:  No default value is displayed

Expected:  Some default value or text should be displayed.  Note: spec doesn't
detail this.

Comment 1

[laurel]

Oops, forgot about Priority.

Comment 2

[Håkan Waara]

Jglick, what should the default option be of these available:

Replied
Read
New
Forwarded

I vote for "New".

Comment 3

[jglick]

I would say either Read or New is fine. 4.x didn't list "New" as an option, was 
there a reason for that?  Do we expose the user to any more risk or errors by 
using "New" vs "Read" by default?  (messages they haven't seen yet being 
filtered)

Comment 4

[laurel]

FYI:  As to Jennifer's last comments about status filtering... Status filtering
doesn't really apply.  We've never spec'd to have New in the status filtering
choice list and the main point here is that status filtering doesn't apply in
our current product! Status filtering is applicable when and if we implement
after-the-fact/manual filtering.  I've long ago asked to have status pulled from
the list - see bug 40472. The powers that be have not yet deemed removing
unimplemented criteria choices from filters (or search) ui.  

Comment 5

[laurel]

Oh, and, but the way searching with New (again, we never spec'd to have this)
doesn't even work. see bug 78418. 

Comment 6

[jglick]

For Status lets go with the default "Read"
For Priorty lets go with the default "Lowest"

Comment 7

[Håkan Waara]

I agree about "Read". Most of the user's emails that it might want to search are
already ready.

Why "Lowest" as default? I know that 99% of all mails sent and received each day
is by default "Normal" because very few people use Priority at all. Therefore, I
think it should be "Normal" because otherwise the user won't find many emails at
all if it doesn't modify these settings.

Comment 8

[jglick]

I don't think the defaults we pick for filters are very important. Filters are 
are used by a more experienced type of user. People setting up filters WILL  
change the settings (why would you go to the trouble to setup a filter and use 
the defaults?).  Hence, "Normal" is fine for the default if you prefer.

Comment 9

[Håkan Waara]

Fine.  Thanks Jennifer.

Comment 10

[(not reading, please use [e-mail] instead)]

taking from hwaara.

I've got a fix for this in my local tree.

Comment 11

[(not reading, please use [e-mail] instead)]

Attachment: workaround fix

Comment 12

[Håkan Waara]

I can tell this is a workaround because it makes no sense to me. :)

Seth, can you explain please...

Comment 13

[Håkan Waara]

r=hwaara if you explain the workaround

Comment 14

[(not reading, please use [e-mail] instead)]

Attachment: cleaner patch, same work around.

Comment 15

[(not reading, please use [e-mail] instead)]

here's what the work around does, when the constructor for the search term is 
called, I need to reset the selectedItem on the menulist.

that last patch is in (r/sr=bienvenu).

I'll start a new bug on improving (or removing) the work around.  I shouldn't 
have to do what I did, but I've been unable to figure out a way around it yet.

Comment 16

[(not reading, please use [e-mail] instead)]

http://bugzilla.mozilla.org/show_bug.cgi?id=90739 covers the workaround.

but at least end users (and my pal laurel) will not have to see blank pickers 
anymore.

Comment 17

[Håkan Waara]

The pickers are now initialized, but not to the right values which would be:
Priority normal and Status read (as discussed by me and jglick earlier in this bug).

Patch coming up to fix this

Comment 18

[Håkan Waara]

Argh. My fix didn't work and all the construction/init stuff that is in
mailWidgets.xml is confusing.

Probably an easy change if you know what to do. :(

Comment 19

[(not reading, please use [e-mail] instead)]

hwaara, can you spin off changing the default values to another bug?

since the pickers are no longer blank, I consider this fixed.

Comment 20

[(not reading, please use [e-mail] instead)]

spun off to bug #91055

this problem (blank pickers) is fixed.

Comment 21

[laurel]

OK using aug10 commerical trunk build: win98, linux rh6.2, mac OS 9.0.
OK classic and modern themes.