201652 - mail link does not restore minimize/iconified browser window

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[James Rome]

If the browser window is minimized, and if you click a link in a mail message,
it appears as if nothing is happening because the browser window stays minimized.
In my opinion, clicking such a link should unminimize the browser.
Win2k build 2003040308

Comment 1

[Matthias Versen [:Matti]]

Please select a better component the next time, Browser General doesn't fix bugs !

-> XP APPS

Comment 2

[James Rome]

Sorry, but I had no clue which component to pick because it was mail + browser,
and I don't know what XP Apps is....

Comment 3

[Boris Zbarsky [:bzbarsky]]

James, you may want to read the component descriptions (the link on the word
"Component" leads there)... Sometimes those help (not much in this case, though).

Comment 4

[David Favor]

This problem also occurs in all AIX builds after 4/15 22:15.

Comment 5

[esther]

Nominating, this is a bad regression for Mail.  Note, additionally, if the
browser window is openend but not up front, clicking on a link in a mail message
does not bring the  browser window to the front.  

Comment 6

[James Rome]

Thanks for agreeing with me :-)

Comment 7

[esther]

This may have been caused by a fix to 199360, waiting for comments in that bug
to confirm this, I'll leave this open until I find out.

Comment 8

[Michael Dunn]

I think this regression should be "plus'ed" for nsbeta1.

Comment 9

[(not reading, please use [e-mail] instead)]

yeah, this is all me jag, cause by my checking for 199360.

working on it...

Comment 10

[(not reading, please use [e-mail] instead)]

Attachment: patch

Comment 11

[esther]

resolving as dup because this scenario is mentioned in bug 199360 as a side
affect of the fix.  

*** This bug has been marked as a duplicate of 199360 ***

Comment 12

[Brian Ryner (not reading)]

Comment on attachment 121474 [details] [diff] [review]
patch

r/sr=me

Comment 13

[esther]

removing the dup status 

Comment 14

[Olivier Cahagne]

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

Comment 15

[(not reading, please use [e-mail] instead)]

fixed checked in last night.

Comment 16

[(not reading, please use [e-mail] instead)]

whoops, problem with this, as sarah points out.

we need to focus on the content area, so that in the new window, keyboard
scrolling works.

otherwise, the window has focus, and you have to click in / tab into the content
area first, before that works.

she's logging a new bug, but here's the patch:

Index: resources/content/contentAreaUtils.js
===================================================================
RCS file: /cvsroot/mozilla/xpfe/communicator/resources/content/contentAreaUtils.
js,v
retrieving revision 1.76
diff -u -w -r1.76 contentAreaUtils.js
--- resources/content/contentAreaUtils.js       24 Apr 2003 00:13:12 -00001.76
+++ resources/content/contentAreaUtils.js       28 Apr 2003 21:32:16 -0000
@@ -110,7 +110,7 @@
   // if there's an existing browser window, open this url in one
   if (browserWin) {
     browserWin.getBrowser().loadURI(url); // Just do a normal load.
-    browserWin.focus();
+    browserWin.content.focus();
   }
   else
     window.openDialog(getBrowserURL(), "_blank", "chrome,all,dialog=no", url, n
ull, null);

Comment 17

[sairuh (rarely reading bugmail)]

filed bug 203716.

Comment 18

[esther]

using trunk build 20030428 on winxp, macosx and linux this is fixed. Verified