Closed
Bug 125631
Opened 22 years ago
Closed 16 years ago
mail search and filters: default should be "all" instead of "any"
Categories
(MailNews Core :: Search, enhancement)
MailNews Core
Search
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 3.0b2
People
(Reporter: jruderman, Assigned: philor)
References
Details
Attachments
(1 file, 1 obsolete file)
2.24 KB,
patch
|
neil
:
review+
neil
:
superreview+
clarkbw
:
ui-review+
|
Details | Diff | Splinter Review |
AND searches should be the default in mail search. - Consistency with search toolbar (bug 123788). - Consistency with modern search engines (e.g. Google, Teoma, Lycos, Alltheweb). - "Or" searches are really not that useful, especially if you can't combine them. You might as well just run two searches. ((A or B) and (C or D) would be more useful, but that's not this bug.) I would suggest making this change to the filter dialog as well (for consistency). While "or" filters are more common than "or" searches, I search much more often than I edit my filters.
Updated•20 years ago
|
OS: Windows 98 → All
Hardware: PC → All
This is to show that whining about favorite bugs in one's weblog is not always completely useless and sometimes actually can make random people take the two minutes to fix (and ten test check that it's actually the right fix). :) (Okay, and I'd just noticed myself always toggling this thing as well when searching.)
Comment on attachment 145730 [details] [diff] [review] patch Neil, could you take a sec for review of this super simple fix?
Attachment #145730 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 5•20 years ago
|
||
Comment on attachment 145730 [details] [diff] [review] patch Looks good but it doesn't work with Create Filter From Message :-( BTW you can probably get rid of the selectedItem attribute.
Attachment #145730 -
Flags: review?(neil.parkwaycc.co.uk) → review-
Comment on attachment 145730 [details] [diff] [review] patch Oh, gaah! So I just spent an hour tracing where this is set for create filter from message, but as far as I'm able to determine, it isn't - rather, it's a result of the and=true, or=false assumption made, with uninitialized thus resulting in or, and that in a next step being set for real. So either I'll need to initialize this myself somewhere (but where?), or remove the logic for setting this when based on uninitialized. Need to spend some more time familizarizing myself with what's going on before I can decide what the most correct fix would be. *grumbles grumbles* stupid deceptively simple code - that'll teach me to help with a quick cheap fix... :)
Attachment #145730 -
Attachment is obsolete: true
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•19 years ago
|
Assignee: sspitzer → mail
Comment 7•18 years ago
|
||
(In reply to comment #0) > AND searches should be the default in mail search. conditionally, I disagree per https://bugzilla.mozilla.org/show_bug.cgi?id=324113#c2
Component: MailNews: Search → MailNews: Message Display
QA Contact: laurel → search
Updated•16 years ago
|
Assignee: mail → nobody
QA Contact: search → message-display
Assignee | ||
Comment 8•16 years ago
|
||
Since there's just one of things like FilterEditor.js and searchTermOverlay.xul, let's move this to MailNews Core: Shared UI. Oh, yeah.
Component: MailNews: Message Display → Search
Product: SeaMonkey → MailNews Core
QA Contact: message-display → search
Assignee | ||
Updated•16 years ago
|
Summary: mail search: default should by "all" instead of "any" → mail search and filters: default should be "all" instead of "any"
Assignee | ||
Comment 11•16 years ago
|
||
"Neil, could you take a sec for review of this super simple fix?" I just took the value of the radiobutton from the UI, stuck it into the filter item, where it turns into a column in the UI, which is then hidden because it's unreliable, but before it's hidden the value comes back out of it to set the radiobutton in the UI to the value that the radiobutton in the UI already has. I found that two hours of continuous handwashing after writing the patch was enough to start to feel clean again; your mileage after reviewing may vary.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #349611 -
Flags: ui-review?(clarkbw)
Attachment #349611 -
Flags: superreview?(neil)
Attachment #349611 -
Flags: review?(neil)
Comment 12•16 years ago
|
||
I take it you also meant to change the mail view and virtual folder default?
Comment 13•16 years ago
|
||
Comment on attachment 349611 [details] [diff] [review] patch, v2 Seems like a better default. It would be good to have a "search for conversations with..." style search option that allows people to search all of the to/cc/bcc fields at once. Otherwise I can see how this might make that search a little harder.
Attachment #349611 -
Flags: ui-review?(clarkbw) → ui-review+
Comment 14•16 years ago
|
||
(In reply to comment #13) > (From update of attachment 349611 [details] [diff] [review]) > Seems like a better default. > > It would be good to have a "search for conversations with..." style search > option that allows people to search all of the to/cc/bcc fields at once. > Otherwise I can see how this might make that search a little harder. That's bug 310359.
Assignee | ||
Comment 15•16 years ago
|
||
(In reply to comment #12) > I take it you also meant to change the mail view and virtual folder default? I meant to change everything, but I see that Tb's quicksearch defeated me. Lucky that I picked a reviewer who will be happy to call that another bug, eh? Virtual folders I changed, intentionally: I see that as being "Search Messages... And I Know I'm Going To Click The Save As Search Folder Button" and having them different would be weird. Views by themselves, I don't think I changed: they set booleanAnd to true on their own, and did before I got to them. But, Tb's quicksearch, and the horror of combining a view with quicksearch... It's certainly undiscoverable (after six years of using mailnews/ products, I discovered it by reading the code), and probably undocumented, but you can do OR quicksearches (in SM or Tb) with "foo|bar", which is implemented by .split("|") and then saving each bit, including [0], with booleanAnd = false. With this patch, if you save "foo|bar", we'll bring up the dialog with OR selected, thank Ghu. If you save "foo", we'll bring up the dialog with OR selected, which isn't what I would choose. If you save "foo" with a view, say Tags - Important, we'll bring up the dialog with OR selected, despite the fact that the search, "subject contains foo", booleanAnd = false, "tags contain important", booleanAnd = true, evaluates as an AND. And if you save "foo|bar" with a view, we'll bring up the dialog with OR selected, despite there being no radio button which can express what you're doing, because that actually lets you (in limited circumstances) do a search that people are always asking for, (subject contains foo || subject contains bar) && tags include important. But as I say, that's a Tb-only problem, and thus not this bug, and maybe our next incarnation of quicksearch will have some different bug instead.
Comment 16•16 years ago
|
||
(In reply to comment #15) > (In reply to comment #12) > > I take it you also meant to change the mail view and virtual folder default? > Views by themselves, I don't think I changed: they set booleanAnd to true on > their own, and did before I got to them. When I do View > Messages > Customise... [New] it defaults to "or" without the patch and "and" with the patch.
Updated•16 years ago
|
Attachment #349611 -
Flags: superreview?(neil)
Attachment #349611 -
Flags: superreview+
Attachment #349611 -
Flags: review?(neil)
Attachment #349611 -
Flags: review+
Comment 17•16 years ago
|
||
Comment on attachment 349611 [details] [diff] [review] patch, v2 >+ term.booleanAnd = (gSearchBooleanRadiogroup.value == "and"); Nit: don't need the ()s. > <radiogroup id="booleanAndGroup" orient="horizontal" >- selectedItem="or" oncommand="booleanChanged(event);"> You may prefer to use value="and" here instead of radio selected attributes.
Assignee | ||
Comment 18•16 years ago
|
||
http://hg.mozilla.org/comm-central/rev/10e7cea5a551
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b2
You need to log in
before you can comment on or make changes to this bug.
Description
•