When only the bottom right or left corners of Mozilla are showing behind other apps, incoming mail notification is invisible from Mozilla, unlike Netscape 3, which at extreme lower right provides not only incoming mail notification, but a quick switch-to and download from a single button click. I still use Netscape 3 for email in large part because I can leave my open mail window at extreme bottom right and bottom of screen and have the incoming mail notification visible at all times that no app has full screen.
Created attachment 72596 [details] Screenshot of bottom frames of Netscape 3, Comm 4, & Mozilla This is a screenshot of the extreme lower right of my screen. Note that only Netscape 3 can have its incoming email notification placed in a corner where it can be and be kept visible virtually always.
Once bug 122626 is fixed, having the browser's mail notification icon in the lower-right would make is look redundant.
Yes, that it would in windoze, but this is a multi-platform bug. You didn't happen to notice a taskbar in the screenshot of the extreme lower right of the screen, did you? It wasn't there because there isn't one. Not all platforms have a systray equivalent.
removing stephend & adding myself as qa
Those are Linux and Mac bugs. I'm using OS/2. Regardless, I can't see any reason why the mail icon shouldn't be moved to one of the corners, no compelling reason for the padlock to be lower right, nor browser icon lower left. What I've asked is a cross platform solution that would intrude zero upon proposed email notification solutions specific to any platform, and could coexist with them happily.
*** This bug has been confirmed by popular vote. ***
Well, at least in Classic (I don't use Modern), I see the green arrow on the mail icon to show that you have new mail. If that's a problem with modern you should file a themes bug. Also, I filed the bug asking for the mail icon to go to read your new mail some time ago but it's not happened yet.
neil@, you should read the original comment and study the attachment more carefully. The issue is not the mail icon, it is the mail icon placement.
You are apparently missing the point entirely. What the icon looks like when mail is waiting for download is not the issue. The issue is whether the icon is visible. Currently, a very substantial portion of the Mozilla (or 4.x) bottom frame must be peeking from behind other windows in order to see that mail awaits. In Netscape 3, only a tiny little peek at the lower right corner of the frame is required in order to know mail awaits. To the Navigator (?) chrome filespec <http://bugzilla.mozilla.org/attachment.cgi?id=65067&action=view> in section 6 the mail icon should be added, with emphasis on its placement in a corner, preferably lower right, where it can most easily be made to peek out from behind other windows and thus be visble even though Mozilla doesn't have focus. With a mail icon placed on that prime real estate, there would be no need to put a mail icon on the main toolbar as called for by the chrome filespec. With the other app icons removed from the bottom frame, the privacy control, security control, and offline control icons' function as toggles could be distinguished by their placement at the left side of the bottom frame. Neil@, read comment 9 again. Also, to what bug were you referring in comment 8?
Somehow I don't see that you're going to get the icon moved :-(
Why, is there some patent or copyright obstacle to putting it in the most useful location? Even just swapping the browser and mailnews icons would do the trick, putting mailnews in the left lower corner instead of the right lower corner.
No, it was an opinion.
I just can't see us doing this, sorry. If you want it, you need to do it as an add-on, which is easy to manage in SeaMonkey 2.
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420