Open Bug 55557 Opened 24 years ago Updated 12 years ago

Need multiple (advanced) search messages window

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: ftang, Unassigned)

References

Details

(Whiteboard: [p-oe/mac] [p-sherlock]) 

I really hope that we can have multiple mail search window.
reproduce procedure
1. open mail
2. open "Search:Search Mail/News"
3. select "to or cc"
4. type my email address and search
5. I found all the mail send directly to me
6. try to reply those mail
7. when I compose my reply, I need to do some research and find a mail that
related to this issue.
8. I cannot do such research without lost my origional search.

actual result
If I select "Search:Search Mail/News", the current mail search window will be
position in a different place.
expect result
If I select a "Search:Search Mail/News", I will have a new Searh window for me
to do research.

Of course, I know it is late for rtm. just file as RFE
QA Contact: esther → laurel
reassign all search/filter UI bugs to gayatrib, part 2
Assignee: alecf → gayatrib
reassigning to naving
Assignee: gayatrib → naving
As it is right now Moz doesn't even do the right thing with just one window:

The first click on Search mail messages will bring up the search window with the
current folder chosen
A second click on Search mail (without closing the previous search window) will
bring up the old window but with the server instead of the current folder chosen.
It's quite funny, when I made the fix for bug 44800, I accidently made it so we
always opened up a new Search window regardless if one was already open.

When I realized my mistake, I tried it some and it to further surprise me it
worked very well! I tried searching simultaneously in three search windows at
once, and that worked well.

Turning this on in the FE is easy, but Seth is worried that the backend might
not support it.

Bienvenu, Navin, any comments on the backend?
Assignee: naving → hwaara
hwaara, after you land your fix for #44800, can you attach a patch that makes 
it so we can have multiple search windows?

I'd also suggest we future this.

we should focus on other existing problem before adding new features like this.
Depends on: 44800
I'm just making this feature visible. It's a 5-liner in JS code.

Unless the backend has problems, I don't see a reason why we should future this.
the backend supports this, I believe, though there will be some unhappy things
happening if you get simultaneous searches going on at the same time in terms of
server hits, etc.
But that's not our problem, right? ;)

bienvenu, what do you say about turning this on? it worked flawlessly for me and
you say the backend supports it...
Seth, looks like a highgain-lowrisk fix to me! Sounds like it's OK backend-wise.

What do you say?
can you attach the patch that turns this feature on?

I still think we've got bigger fish to fry right now, but when things clear up
we can investigate this.

I'd rather see us work on fixing bugs we've got, before adding more features.

The second part of this is for jglick to comment on the UI issues / user
experience issue of allowing multiple search windows.  she's currently
overloaded, so don't expect her to comment real soon.


Most of our other dialogs only allow one instance of that dialog at one time. If 
the user has the search dialog open and selects "Search Messages" from the 
menu again, shouldn't it bring the already open dialog into focus instead of 
opening a whole new window? This seems to be how the rest of the product works. 
Any examples of other dialogs in the product that work differently?

As for Frank's original goal, we would like to have a feature in which users can 
save the results of a search (in a virtual folder) and return to it whenever 
they like.
based on jglick's comment, and the specs, this is sounding like a wontfix.

just because we can do it, doesn't mean we should.

for example, we don't allow multiple bookmarks, subscribe, or history dialogs.
Would be nice if we could catch wontfixes in the process where bugs are being
confirmed/triaged... instead of doing it 9 months after being reported.

Oh well. wontfix as needed.
wontfix.

given the volume of bugs, the priorities we have, and our limited resources, we
can't get to everything right away.

the current behaviour (re-focusing the search window) is the desired one.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Reopening -- this appears to have been wontfixed in error.
<http://bugzilla.mozilla.org/bug_status.html> says WONTFIX means `The problem
described is a bug which will never be fixed'. It does not mean `we can't get to
everything right away, even though we don't need to get to this right away
because someone else has volunteered to do it'.

The Search Messages window is not a dialog, it is a window (that's why it's
possible for it to lose focus in the first place). Certainly when a Search
window is open but dow not have focus, `Search Messages ...' or Shift+Command+F
should focus the most-recently-focused Search window (and that's already been
fixed); but for either the menu item or the keyboard shortcut to do nothing
*when a Search window is already focused* is obviously a bug. Only allowing one
search window to be open at once in mail/news is the equivalent of only allowing
one google.com window to be open at once in Navigator.

Saving search results as would not solve ftang's problem, since it still
wouldn't allow two sets of search results to be shown at the same time. The only
practical alternative to allowing multiple search windows (as Sherlock 2 does)
would be to put search results in a separate window from the search form itself
(as Outlook Express and Sherlock 1 do), so that multiple results windows could
be open at once while having only one search window. This would be worse than
the behavior proposed in this bug, however, because: (1) it would require twice
as much dragging of windows to arrange the search UI conveniently on the screen;
(2) it would require two clicks or key-presses to close the search UI once you
were done with it, instead of one; and (3) it would be more difficult to make a
slight modification to a mistyped search.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [p-oe/mac] [p-sherlock]
Tell me the desired behaviour, and I'll whip up a patch. Ftang?
When someone becomes interested in this talk to me. I have a good solution for
it, but no one has yet defined the behaviour of this feature.

Reassigning back to default owner for now.
Assignee: hwaara → naving
Status: REOPENED → NEW
I don't see any use of this, particularly now that we have done Quick Search in 
3 pane. No one would like to launch multiple search window for whatever may be 
the reason. 
Desired behavior is analagous to that requested in bug 20306.
*   When there are one or more Search Messages windows open but none of them have
    focus, choosing `Edit' > `Search Messages...' (or typing Shift+accel+F)
    should focus the most-recently-focused Search Messages window.
*   When there are one or more Search Messages windows open and one of them does
    have focus, choosing `Edit' > `Search Messages...' (or typing Shift+accel+F)
    should open a new Search Messages window.

Quick Search does not affect this bug at all; it still doesn't let me compare
two or more search results with each other.
mass re-assign.
Assignee: naving → sspitzer
Product: Browser → Seamonkey
Assignee: sspitzer → mail
(In reply to comment #18)
> I don't see any use of this, particularly now that we have done Quick Search in 
> 3 pane. No one would like to launch multiple search window for whatever may be 
> the reason. 

given that quick search does not do boolean search, I quite disagree.

in addition, occasions arises where one is in the middle of a search and a
message that needs some additional research, i.e. a secondary search, or, you
temporarily move to a task (e.g. get a call) that requires another search 

(come to think of it, it frequently happens that multiple bmo searches are
needed, but buglist doesn't accomodate)
Severity: normal → enhancement
Summary: Need multiple search mail window → Need multiple (advanced) search messages window
Håkan writes:
[the key to making this work/reproducing the 5 lines of JS is] "probably it's in
one of the main mail JS-files and has to do with windowmediator or something
like that. I remember I fiddled with code that searched for the window with the
id "mail:3pane" or something like that.  This is probably the key for finding
out if a 3pane is already opened anyway. "
[ref bug 44800]

The combination of this and bug 258371 will give search another great leap in
functionality, similar to that of VF and quick search.

Comment 19 is a good starting for behavior, but consider, that if only
ctrl-accel-F pops additional search windows then there is no UI to inform a user
that more than one search windows is possible.  Suggestions:

a) initiate *additional* search windows only via "additional searches" button on
the first and subsequent "search messages" window

b) if more more than one search message window is open and focus is on a search
window, make ctrl-shift-F cycle through a ring of active "search messages" window
QA Contact: laurel → search
We probably need to work out what the server impact is of having multiple search windows open and searching as David said in commment 7.
The issue is that because of the UW server's fondness for kicking a connection off if a second connection selects the same mailbox, we will only run url at a time against a particular folder. So if you get two searches on the same set of folders going at the same time, one of them will basically have to wait for the other to be done with each folder. This is an edge case that's not worth worrying about much.
bug 87854 a dupe of this?
Component: MailNews: Search → MailNews: Message Display
Assignee: mail → nobody
Priority: P3 → --
QA Contact: search → message-display
Just wanted to note on this bug that I've been looking at this problem being solved through the eventual plans to use the tabs ( bug 218999 ) for opening up search results via the new toolbar ( bug 452281 ).  This should enable multiple searches open at the same time and not destroy your existing context with reading messages.  An advanced search on these new tabs with facets has not yet been done but needs to get some attention soon.
You need to log in before you can comment on or make changes to this bug.