Closed Bug 104237 Opened 23 years ago Closed 21 years ago

Compose window comes back behind the application I'm sending from


(MailNews Core :: Simple MAPI, defect, P1)

Windows NT


(Not tracked)



(Reporter: lchiang, Assigned: mscott)



(Whiteboard: [ADT3])


(2 files)

Compose window comes back behind the application I'm sending from

Win32 2001-10-10-094 branch build

I only have one profile in Netscape 6.  

1.  Open Word and a document in Word.
2.  Send the document within Word.
3.  It appears to the user that nothing happened, but if you minimize the Word
application, you will see that the compose window appears.

The compose window should be at the front of the Word window.

This happens whether or not Netscape 6 is already running when step 2 is done.
nominating nsbranch as this is usability and visible, although no data loss or
Keywords: nsbranch
I can reproduce this:

1.  Save the attached doc file to your desktop
2.  Start Netscape 6.  Pref set to open browser and mail.  Browser window opens.  
Mail window opens.  Login dlg appears for Imap mail.  Login.
3.  Minimize the mail window
4.  Minimize the browser window
5.  Double click the doc file that is on your desktop
6.  Word opens
7.  File Send
8.  Compose window appears behind the Word window.

WinNT 4.0, Word 97 SR-1.
Attached file word document
Whiteboard: [PDT]
is there a flag that is set to not gain forcus here?
This happens regardless of which application you use to send to mail recipient.
trix- do you see this if you follow my steps?  Sounds like others are seeing this.
Rajiv will take a look, if we need any architecture change, then fix later.
Otherwise, do it now.
Assignee: tiantian → rdayal
Priority: -- → P3
Let's get this one in the pocket for next week linmbo. nsbranch+ per Simple MAPI
Keywords: nsbranchnsbranch+
I looked at the code for Compose Window. The nsIDOMWindow object associated with
Compose Window is a local variable in the openWindow function in
nsMsgComposeService.cpp. It is not a simple fix since even if we export a
reference to this nsIDOMWindow object (which might not really be a good policy)
there is no exported function in the nsIDOMWindow interface to set it as the top
most window.

How does this work in Outlook and Outlook express?
Hey Rajiv, at PDT today, danm had a suggestion for us. He said the OS is really
what's preventing the compose window from coming to the top because the mozilla
application isn't the application which currently has focus so we can't steal it
from the mapi client. 

We could allow the mapi code to get the dom window for the compose window. There
are some hoops you can jump through to get the native window (HWND) for the
compose window. We could then proxy this object back to the mapi process which
is running in conjunction with the  mapi client (same thread?). It could then
set focus on the  native window which should cause the compose window to then
come up in front. 
Yulian or Gary, can you check out the behavior in 4.x?
Krishna is looking at how to control the top window focus from within the MAPI

Reassign to Krishna, because Rajiv needs to work on bug 104491.

Assignee: rdayal → kkhandrika
4.x behavior:

            bunch of different windows open, 4.x is not open
            and if I do a send from Word: it brings up
            compose window and the password dialog for messenger
            to the front.

            If I have 4.x open already, it brings up compose window
            to the front.

Hmmph. I suppose this is a case where an application could reasonably try to
shoulder its way to the front. Normally that's considered rude and Windows tries
to stop it. Really I don't even understand how 4.x accomplished that.

You could experiment with ::SetForegroundWindow(), but in my experience this
pretty much never succeeds where the current code in SetFocus fails. (That's
what mscott's suggestion above is about (and to be fair it was really Bill's
idea); trying to call that function in a place where it might succeed.)

Or perhaps more reasonably you could add a call to GetAttention in the Focus
code. That will flash the window in the taskbar (Windows OS) under these
circumstances, but I'd want to let that bake on the trunk for a while to see
what else it does before committing it.
Actually, 6.2 behaves the same as 4.x.

Restarting 6.2/4.x Browser or right after setting Netscape mail as default from
4.x/6.2 , for the first time sending MS application, compose window comes back
behind the application. Subsequent sendings within the same section have no
problem bringing compose window to the front of application if the previous
compose windows are closed.


1. Restart 6.2
2. Open MS Word
3. Send the doc
4. Compose window comes back behind the MSWord
5. Send out the compose window or close it
6. repeat Step2&3
7. Compose window is brought up to the front
According to Yulian's test result, we are in parity in 4.x. So this should not
be considered as a stop-ship.
Same behavior as 4.x, PDT- for 094.
Whiteboard: [PDT] → [PDT-]
Keywords: nsbeta1
Blocks: 107066
Keywords: nsbranch+
Blocks: 103807
Target Milestone: --- → mozilla0.9.8
reassigning to rdayal.
Assignee: kkhandrika → rdayal
Keywords: nsbeta1nsbeta1+
Priority: P3 → P1
Target Milestone: mozilla0.9.8 → mozilla0.9.9
removing PDT grafitti.
Whiteboard: [PDT-]
No longer blocks: 107066
Rajiv, when you go to fix this bug come talk to me. I think I may have
discovered a way to get this to work. I just got it working for the mail 3-pane
when you double click the biff icon in the system tray. 
Target Milestone: mozilla0.9.9 → mozilla1.0
Whiteboard: [ADT3]
Discussed in Mail News bug mtg with Engineering QA Mktng PjM.  Decided to minus
this bug. 
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha
Here's what I'm doing in nsMessengerWinIntegration.cpp to make this work:

static void activateWindow( nsIDOMWindowInternal *win ) 
  // Try to get native window handle.
  HWND hwnd = hwndForDOMWindow( win );
  if ( hwnd ) 
    // Restore the window if it is minimized.
    if ( ::IsIconic( hwnd ) ) 
      ::ShowWindow( hwnd, SW_RESTORE );
    // Use the OS call, if possible.
    ::SetForegroundWindow( hwnd );
  } else // Use internal method.  
This will require either the local domWindow/newWindow variable in
nsMsgComposeService::OpenWindow to be exported (which i donot think is a good
idea), or the nsMsgComposeService::OpenWindow function itself be modified. The
second is possible but we should be careful about how it would impact other
places where the compose window is displayed.
I think the quick solution would be to add a window parameters in
nsIMsgComposeParams which will be filled by the compose service when the window
get open. That would prevent us to have to modify a lot of code/interface

But the cleanest solution would be to add a parameter to return the window to
the following apis:

and If you change the nsIMsgComposeService interfaces, please remove depreciated
api OpenComposeWindowWithValues and OpenComposeWindowWithCompFields which are
not used anymore (at least by Netscape/Mozilla)
QA Contact: trix → yulian
QA Contact: yulian → stephend
Blocks: 227208
Attached patch potential fixSplinter Review
This fix forces the compose window to always come to the front when it gets
loaded. This means the windows desktop front and not just the front of the
mozilla process.
No longer blocks: 227208
*** Bug 227208 has been marked as a duplicate of this bug. ***
Assignee: rdayal → mscott
Blocks: 227205
Attachment #137437 - Flags: superreview?(bienvenu)
Comment on attachment 137437 [details] [diff] [review]
potential fix

sr=bienvenu - should we file a bug about doing this in an OS-independent way?
For example, if tbird is the default mail app, clicking on a mailto link in
another app should do the same thing as MAPI...
Attachment #137437 - Flags: superreview?(bienvenu) → superreview+
spun off Bug #228564 per David's comments
Blocks: 228788
checked into the m4 branch of tbird
Is/will it be checked into the Suite?
checked in.
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.2alpha → mozilla1.7alpha
Product: MailNews → Core
*** Bug 189921 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.