103873 - Closing of two dependent windows simultaneously makes the primary window go behind other windows

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[ji]

***Observed with win32 and Mac OS X 10/08 0.9.4 build***

When a reply mail contains characters not in the specified charset, an warning
dialog will pop up. If this dialog window is canceled, the focus should be
returned back to the reply compose window, but now with the current 0.9.4
builds, the reply window is minimized instead.

Steps to reproduce:
1. Select a Japanese mail in your mail box.
2. Click on Reply.
3. Change the charset to Western (ISO-8859-1) by selecting View | Character
Coding menu
4. Click on Send, a warning dialog pops up saying that this mail contains chars
not in the specified charset, click on Cancel.
The reply window is minimized.

Comment 1

[nhottanscp]

This might be not specific to the charset alert.
Could you try with other kind of warnings (e.g. folder not set)?

Comment 2

[ji]

You are right. When I erase the recipient email address in the reply window and
send it, I get an error. If I OK that error dialog, the reply window is
minimized too. Naoki, could you reassign? Thanks.

Comment 3

[nhottanscp]

Okay, not i18n specific, reassign to ducarroz.

Comment 4

[ji]

Changed component and QA contact accordingly. 

Comment 5

[scottputterman]

nominating.  Error messages shouldn't hide the compose window.

Comment 6

[Jean-Francois Ducarroz]

reassign to varada

Comment 7

[varada]

*** Bug 113186 has been marked as a duplicate of this bug. ***

Comment 8

[varada]

I have marked 113186 as a dup of this. What happens in both cases is that the
compose window is moved to the background in favour of the browser or mail
windows. this is an OS issue and the bug is being re-assigned to the xptoolkit
team. I am also changing the summary to "Closing of two dependant windows
simultaneously makes the primary window go behind other windows" as per dan matejka.

Comment 9

[Dan M]

Attachment: enhance reactivation of the parent window when closing a dialog, Windows-only

First let me verify that the original bug description is incorrect: in step 4
the message window is *not* minimized; it's just unexpectedly sent behind other
open windows, yes? This is yet another version of a long-standing bug that's
proven pretty intractable. It's been an annoyance, but only a minor one. This
bug is related to bug 74053, though it seems to not be identical. This bug is
nsbeta1+? Sigh.
  Well, this patch seems to fix this bug without affecting bug 22658 in a bad
way, without hurting bug 54936, and surprisingly without fixing bug 74053. It's
not very pretty and could probably be improved by hiding the new
Windows-specific code behind some method call in nsIWidget. It would have to be
a new method (nsIWidget::DispatchEvent won't suffice). But I guess I'd rather
have the ugly XP code than a whole new special-purpose method on nsIWidget, so
I'm just presenting the patch for review as is.

Comment 10

[Juan José Mata]

Update target milestone to 'Future' since this missed the 'mozilla1.1beta' train.

Comment 11

[Juan José Mata]

Reassigning futured nsbeta1+ bugs to Samir in case he wants to find people that
can pay attention to them.

Comment 12

[Samir Gehani]

Removing nsbeta1+ for mail triage team reconsideration.

Comment 13

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 14

[Daniel Kirsch]

The problem in bug 243388 is still reproducable and this one is open since 7 1/2 years. I would really like to see some progress here. Shouldn't be to hard to fix this.

Comment 15

[Wayne Mery (:wsmwk)]

Dan, old patch of yours :)

Comment 16

[Daniel Kirsch]

Thanks Wayne for the hint to the patch. I would be really happy to see this fixed. Dealing with multiple dependent windows is a real pain because of this bug. Using palettes like Photoshop is just not possible because when closing one dependent window, all other dependent windows will be hidden until one set the focus to another window and back to the original window.
bug 243388 is pretty similar and still not solved (although marked as "worksforme" which it does not on my system).
See bug 243388 comment 12 for a description how to reproduce it.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

Wayne: actually, "Dan M" is "Dan Matejka".

Comment 18

[Magnus Melin [:mkmelin]]

The dialogs as reported do not exist since many years. Closing this.