140821 - compose window raised inappropriately.

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, defect)

Description

[Max Waterman]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; IRIX IP32; en-US; rv:1.0.0+) Gecko/20020427
BuildID:    2002042723

When you are finished composing a message, and hit 'send', a window is opened
indicating progress in sending the message. When this window is opened, it
raises the compose window to the front of the window stack.

This is wrong. (IMO) Nothing should alter the position of windows in the window
stack apart from the user. It would be understandable (though, IMO, still not
acceptable) if it were an error which demanded my attention, but this is purely
a status message.

It is a problem for me because I hit send and immediately push it to the back of
the window stack so I can work on something else. When I do this, it rudely
raises itself again, purely to tell me it's doing what I asked of it.

Reproducible: Always
Steps to Reproduce:
1.compose email in a window which isn't at the top of the window stack
2.hit 'send'
3.

Actual Results:  window is raised to the top of the window stack.

Expected Results:  should just send.

Comment 1

[Mitch]

Confirmed i am seeing the same action on all Unix platforms (Solaris,
Linux). Agree that this is the wrong thing to do and also the copious
amount of window raises in mozilla code makes it not only ineffecient
but also very slow due to the expensive nature of X window stacking 
and raising.!

This need to be fixed since the browser is becoming stable we really
need to concentrate on performance which is quire dire comparatively to 
netscape.

Comment 2

[Max Waterman]

Could someone please have a look at this? It is incredibly irritating.

Thanks.

Max.

Comment 3

[Jean-Francois Ducarroz]

-->varada

Comment 4

[Nick Blievers]

Can someone please change this to ALL platforms if it is occuring on all other 
*nix's. It will broaden the number of people who see this considerably, and it 
sounds like it is NOT just an IRIX bug.

Comment 5

[Mitch]

dup of 128505 ?

Comment 6

[Max Waterman]

Sounds likely, though that suggests it is a dup of 88810, which has a more
sensible Summary.

Comment 7

[Mike Cowperthwaite]

I think bug 88810 is a more generic problem; this is a specific issue.  I also 
don't think "all" is appropriate because, under Windows, it's not (normally) 
possible to have an active window where you can "hit send" without that window 
being on top already.  (I don't know whether that's true for the Mac or not.)

Does the problem still exist?  Does it apply to all windowing environments for 
*nix, or just X-windows?

Comment 8

[Aaron Lawrence]

Can't see how to reproduce this on Windows... the progress dialog seems to come
up immediately. 

However, all Mozilla dialogs do try to focus/bring themselves to the top... this
is more of a Windows thing though... and in W2K and later the window doesn't
actually go to the top, just the taskbar icon flashes. So still not relevant to
windows.

Comment 9

[Max Waterman]

(In reply to comment #8)
> Can't see how to reproduce this on Windows... the progress dialog seems to come
> up immediately. 

IINM, *MS* Windows will not let you type into a window which is not at the top
of the stack, so this situation cannot arrise. This is similar on OS X, I think,
though important dialog messages in OS X don't grab focus, even though they are
popped to the top of the stack (at least, that's my observation).

> 
> However, all Mozilla dialogs do try to focus/bring themselves to the top... this
> is more of a Windows thing though... and in W2K and later the window doesn't
> actually go to the top, just the taskbar icon flashes. So still not relevant to
> windows.

Right, but is all UNIX-type systems.

I wonder if one of the haxies (or whatever they're called) can make this
applicable to *MS* Windows too.

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Max Waterman]

(unfortunately) no longer have access to IRIX, or other window system that
allows typing into a window that isn't at the front.

anyone else confirm?

Comment 12

[Wayne Mery (:wsmwk)]

Max feel free to close if you can't recreate this.