Closed
Bug 148001
Opened 22 years ago
Closed 20 years ago
Change to View|Msgs in QuickSearch mode not handled well.
Categories
(SeaMonkey :: MailNews: Message Display, defect)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: laurel, Assigned: sspitzer)
Details
(Whiteboard: [adt3])
Using may29 branch build
When you change the View|Messages setting while in a QuickSearch results view
it's not handled properly.
Two things noticed:
1. We clear the results view, but not the text field.
2. If you've switched views and not hit the Clear button and then switch
folders, you get caught in a confusing mode where we still don't clear the text
field and the Clear button is disabled.
It is unlikely for someone to do this intentionally, but we should handle this
odd case better than we do.
Steps:
1. Open a folder with no unread messages.
2. Set View|Messages to All.
3. Do a QuickSearch which will yield results.
4. While in search results mode, change to View|Messages|Unread or some other
view messages setting.
Result: The search results which were present are cleared and you go to an
empty (unread msgs) view. (While this might be somewhat logical, keep in mind
that if we did a search from an empty view we would present search results from
All messages instead of the selected view -- see discussion in bug 107000.)
Notice, too, we did not clear the search text field.
5. Do not Clear the search text field.
6. Select another folder.
Result: Other folder is loaded, but we still don't clear the search text
field (we would clear this field normally if switching folders in QS mode if the
view hadn't been changed). Now the Clear button is disabled, too. User may be
confused as to how to clear the search -- doing another search then using Clear
would do it.
Actual Result: Not clearing search results properly if user happens to access
View|Messages menu while in search results. Can cause confusion if you don't
use Clear right away -- switching folders doesn't subsequently clear search
state properly.
Expected: If you clear the search results, clear the search field. If we're not
going to handle correctly, disable View|Messages when in search results mode.
Using trunk build 20030124 on winxp, linux (haven't tested mac yet) and the
scenario provided, I don't see this problem anymore. This may have been fixed by
the new stuff Seth is putting in. This could be a wfm now, Laurel if the case
you gave was reproducible every time then this is OK now.
QA Contact: laurel → esther
After speaking to Laurel this problem is seen using the View via the Menu, this
is OK using the View Dropdown via the Quick Search bar. This is not a wfm, but
we now have a workaround.
Comment 6•20 years ago
|
||
This bug is a little confusing because what used to be View|Messages is now
View|Threads, and what is now View|Messages is the same as the items in the
MailView dropdown (see bug 189543).
> Two things noticed:
> 1. We clear the results view, but not the text field.
Still true for MailViews / View|Messages (but not for changes in View|Threads).
However, this is not inconsistent, since setting a MailView that might be empty
and then entering a matching QuickSearch still shows no items.
> 2. If you've switched views and not hit the Clear button and then switch
> folders, you get caught in a confusing mode where we still don't clear the
> text field and the Clear button is disabled.
I don't see this happening either. If I "switch view" via View|Threads, the
QuickSearch field clears. If I use View|Messages or the MailView dropdown, the
QS field maintains, but if I then change folders, the QS field clears, as it
should.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040602
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
=>WFM
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Browser → Seamonkey
Component: MailNews: Search → MailNews: Message Display
QA Contact: esther → search
You need to log in
before you can comment on or make changes to this bug.
Description
•