Closed Bug 44800 Opened 24 years ago Closed 23 years ago

Menu item Search Mail doesn't surface hidden search dialog.

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: laurel, Assigned: hwaara)

References

(Blocks 1 open bug)

Details

(Keywords: platform-parity, Whiteboard: [nsbeta3-])

Attachments

(2 files)

Using jul6 commercial build, linux rh6.0

If there is a search messages dialog hidden behind mail (or other) window, using
menu item Search|Search Mail will not make the dialog surface to top.
Keywords: pp
QA Contact: lchiang → laurel
reassigning to XP Toolkit. This works fine on Windows so it looks like a Linux
problem with bringing focus to open dialogs.
Assignee: alecf → trudelle
someone said the magic word....dialog!

danm!
Assignee: trudelle → danm
Status: NEW → ASSIGNED
Keywords: nsbeta3
nsbeta3-, since the window is listed in the system task bar.
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
*** Bug 91600 has been marked as a duplicate of this bug. ***
Regressed and happens with Win98 using commercial branch 0.9.2 build. 
Not sure if the recently reported dup is on branch or trunk, but whenever we
address the problem will check on win32 and linux. Mac has particular symptoms
for this under bug 74447.
OS: Linux → All
Just some info: trunk only fix for bug 83763 has changed search from dialog to
window, don't know if that will affect this, particularly for linux.  
In build 2001072008, Mac OS 9.1, the window still does not come to the front; 
but after a delay it is moved downward about 100 pixels. Of course if you have 
a full-screen or near-full-screen three-pane window open in front of it, you 
don't see this happen, and the menu item appears to have done nothing except 
lock up your computer for ~20 seconds.
Hardware: PC → All
http://bugzilla.mozilla.org/show_bug.cgi?id=44800

I'm taking this one, I will fix it for 0.9.3.

BTW, the fix I'll attach clears up in the fog for an easy fix for bug 55557
(multiple search windows should be possible).

CC bhuvan and sspitzer for review.
Assignee: danm → hwaara
Status: ASSIGNED → NEW
Priority: P3 → P1
Target Milestone: Future → mozilla0.9.3
Attached patch part 1 of fix.Splinter Review
Attached patch ... part 2Splinter Review
I fixed the code to use the new nsIWindowMediator APIs. 

So, basically, I have ids (windowtypes) for each window I want to open/focus.
Whenever we call MsgSearchMessages() or MsgFilterMessages() we check to see if
the dialog is already open, if it is: focus it, if not: open it.

There is also a special case here (which I have commented): if the filtereditor
dialog is open and you try to open the filterlist dialog from the 3pane, then
things will hork (because filterlist is blocked by filtereditor, since it's
modal) so instead we will focus the filtereditor.

I believe it's the correct fix, although it might sound like a hack, but since
we can't focus the filterlist in that case, and the filtereditor is open, we
focus that.

Seth, Bhuvan?
excellent.  I don't consider you special case a hack.  I think you did the 
right thing.

one minor nit:

+ var filterEditor = windowManagerInterface.getMostRecentWindow
("mailnews:filtereditor");
+    +
+    if (filterList)
+    {

should be

+ if (filterList)
+ {
+ var filterEditor = windowManagerInterface.getMostRecentWindow
("mailnews:filtereditor");

since you don't need to get filterEditor unless filterList is non-null.

fix that, and sr=sspitzer
Actually, I think there is a simpler way to do this.  In theory, giving the
window a unique name (it's one of the openDialog arguments) and then trying to
open another window with that name should just focus the original window.  Maybe
Dan can comment on that.
according to hwaara, calling window.focus() doesn't hork us the way calling 
openDialog() did.

does openDialog() the second time do more than just focus?

we should investigate that.

I've seen other places where this trick (with the window mediator is used).

also, hwaara's fix addresses the special case of the filter editor dialog.

we don't want to call focus() on the parent in that case.
This usage of window-mediator makes the code simpler and will certainly make
fixing bug 55557 a lot easier.
r=bhuvan
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
fixed
blake had some valid points.  blake, if you think this fix should be revisited, 
open a new bug on hwaara.

hwaara, any luck investigating what openDialog() does [beyond window.focus()?]
Nope, no luck on investigating that. By debugging I was unable to find the point
where we focus the window. I ended up in native win-code (is this win-only?).
OK using aug15 commercial trunk build: win98, linux rh6.2 and mac OS 9.0
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Component: MailNews: Search → MailNews: Message Display
QA Contact: laurel → search
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: