All users were logged out of Bugzilla on October 13th, 2018

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

VERIFIED FIXED in mozilla0.9.3

Status

P1
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: laurel, Assigned: hwaara)

Tracking

(Blocks: 1 bug, {platform-parity})

Trunk
mozilla0.9.3
platform-parity

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Keywords: pp
QA Contact: lchiang → laurel

Comment 1

19 years ago
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

Updated

19 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta3

Comment 3

19 years ago
nsbeta3-, since the window is listed in the system task bar.
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
(Reporter)

Comment 4

18 years ago
*** Bug 91600 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 5

18 years ago
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
(Reporter)

Comment 6

18 years ago
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.  

Comment 7

18 years ago
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
(Assignee)

Comment 8

18 years ago
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
(Assignee)

Comment 9

18 years ago
Created attachment 43430 [details] [diff] [review]
part 1 of fix.
(Assignee)

Comment 10

18 years ago
Created attachment 43431 [details] [diff] [review]
... part 2
(Assignee)

Comment 11

18 years ago
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

Comment 13

18 years ago
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.
(Assignee)

Comment 15

18 years ago
This usage of window-mediator makes the code simpler and will certainly make
fixing bug 55557 a lot easier.

Comment 16

18 years ago
r=bhuvan
(Assignee)

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

18 years ago
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()?]
(Assignee)

Comment 19

18 years ago
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?).
(Reporter)

Comment 20

17 years ago
OK using aug15 commercial trunk build: win98, linux rh6.2 and mac OS 9.0
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

10 years ago
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.