From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m17) Gecko/20000625 BuildID: 2000062520 if i go to "preferences" -> "themes" and choose the "classic" and click then "Email" button, the email window opens, but in the back (no focus) and with two flashing textcursors, one in the "to:" filed and one in the mailbody filed ! Reproducible: Always Steps to Reproduce: 1. click onto: edit -> preferences -> appearance -> themes -> classic -> email. Actual Results: 1. email composer window appears in the back 2. the email windows got 2 flashing textcursors (two textfields with focus !) Expected Results: window on top. focus only in "to:" field i have the mail client not configured, but i think this doesn't matter...

looked at this using 2000.06.2308 on winnt and 2000.06.26.08 on linux... the funny thing here is that the "email" button is greyed-out, but inactive.

I think this is a known (more general problem)...basically I think the problem is that the new window that appears isn't modal and the prefs dialog is. The new window needs to be opened modally so it's on top of the prefs dialog and doesn't have this problem. I'll try to find a bug on it. Also, sairuh I notice that also, that the button appears to be disabled but it's not...kinda like the open button in open web location. Fwiw, the button becames disabled if you switch to the classic skin (the two flashing carets is a different problem and not specific to this case)

This is similar to http://bugzilla.mozilla.org/show_bug.cgi?id=18455 which is in Account Settings.

yep. I think there might even be a more recent bug though, about modality in general. looking... (btw: before when I said "Fwiw, the button becames disabled if you switch to the classic skin"...s/disabled/enabled)

Just an update: John Gable, who's with marketing, says in bug 44025 that the Email and Website buttons should be text. If by this he means the email address and website should just be displayed in plain text (which I'm not sure I agree with, but I asked him) then this bug would (logically) no longer exist.

There are two ways for this to be fixed. The 'best' way is to allow the pref window not to be as modal as it is (i.e. only modal to the window that spawned it) ... so that the launched mail window appears correctly. That's a danm bug, but I've heard him say that that's very hard (or impossible?) to do nicely XP... (cc'ing him in case he has corrections/comments) The other thing to do is to simply make the prefwindow non-modal across all platforms. This is something Unix users already enjoy, and given our position may be the easiest solution to this problem. The only additional extra here is that (AFAIK) the prefwindow would have to know how to shut down the app by itself if there were no other windows open (unless something has changed from long ago where closing all windows without microwaving the right hamsters caused a remnant of the app to stay running)... I think this is something that's at least of nsbeta3 importance, marking it as such.

see also related bug 44117, which ben referred to

Oh, for ... why are we opening a nonmodal window on top of a modal one? Rrrrrr. This bug will evaporate when I fix bug 44117 -- really, it's a duplicate of that bug. Don't ask me how to fix the other horrible problems that are bound to crop up; especially the massive case of athlete's foot that will curse the author of such code.

Closing as a dup of 44117, as per Don. *** This bug has been marked as a duplicate of 44117 ***

vrfy dup