If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

'About Mozilla' is treated very badly

NEW
Unassigned

Status

SeaMonkey
UI Design
17 years ago
5 years ago

People

(Reporter: Matthew Paul Thomas, Unassigned)

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
Future
x86
Mac OS X
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

17 years ago
Build: 2001062905, Mac OS 9.1

To reproduce:
1.  Choose `About Mozilla' from the `Help' menu.

What happens:
*   A browser window opens showing About information.
*   This makes about as much sense as a word processor app showing its About
    information in a new word processing document.
*   Or a spreadsheet app showing its About information in a new spreadsheet.
*   That is, no sense at all.
*   In fact, it looks thoroughly unprofessional.

What should happen:
+--------------------------------------------------------+
|[X] About Mozilla :::::::::::::::::::::::::::::::::::[v]|
+--------------------------------------------------------+
|                                                        |
|                         __/\__                         |
|                         `.  ,'                         |
|                          /'`\                          |
|                   |\ /| _  _ . | | _                   |
|                   | V |(_) / 1 | |(_|                  |
|                                                        |
|           Version 0.9.1+ (build: 2001072408)           |
|                                                        |
| +--------------------------------------------------+-+ |
| | Mozilla lets you browse the Web, send and        |A| |
| | receive messages via e-mail and newsgroups, chat |:| |
| | on IRC, and create Web pages.                    |:| |
| |                                                  |:| |
| | Copyright (C) 1998-2001 by contributors to the   |:| |
| | Mozilla codebase under the _Mozilla_Public_      |:| |
| | _License_ and the _Netscape_Public_License_. All |V| |
| +--------------------------------------------------+-+ |
+--------------------------------------------------------+

Random design points:
*   The window should not be modal or resizable.
*   Both the XUL, and the content of the IFRAME, should use CSS2 system fonts
    throughout.
*   The position of the icon (to the left of/above the application name), and
    the font used for the application name, should be themable.

Related bugs: bug 83295, bug 50510, bug 60541.
Edit | Preferences | Debug | Show "About" as modal dialog.

Current default: unchecked.
You'd like it checked and the UI removed? :-)

The dialog now is not all you want it to be, though. It's modal, for a start. 
Hmm. And the Contributors tab seems to have broken.

Gerv

Comment 2

17 years ago
There should be no pref to start with, Gerv. It should always be a modal 
dialog, and yes, the current UI should be ripped out in favor of the proposed 
new UI.

|                         __/\__                         |
|                         `.  ,'                         |
|                          /'`\                          |
|                   |\ /| _  _ . | | _                   |
|                   | V |(_) / 1 | |(_|                  |

Not sure this is possible. I think we'll have to use our current picture which 
has the star on the right-hand side of "Mozilla".

Comment 3

17 years ago
...Shouldn't it also be updated to reflect the true version (i.e. 0.9.2+ in my
case)?  Mine says 0.9.1

Comment 4

17 years ago
Ok, I'm kinda working on this... Just so you all know.

Comment 5

17 years ago
Yes, matthew sees all kind of things and could not see that it says 0.9.1+
instead of 0.9.2+ :)
http://vivaldi.ing.ula.ve/~fricardo/mozilla/mozilla_about.jpg
(Reporter)

Comment 6

17 years ago
Dwayne, Francisco: If you have comments which are completely irrelevant to this 
bug, e.g. what Mozilla's version number happens to be on a particular day, 
please e-mail the comments to yourselves instead of commenting in this bug. 
Thanks.

Clarifications:
*   The list of contributors should be included in the IFRAME, following the
    copyright notice.
*   The star is the star in the current <about:> page, scaled to 64*64.
*   The `Mozilla' title should be in the CSS UI system font, 2em (but themable,
    e.g. 14px on Mac OS X).
*   No, the window should not be modal.

Comment 7

17 years ago
All netscapes have not been modal, and mozilla isn't by default
I think the current setup (having it both ways) is the best idea. Let the user
choose. Besides, i dont think anyone will spend his/her time looking in the
about window. Perhaps about:mozilla :)

Comment 8

16 years ago
Most of the stuff done...

Comment 9

16 years ago
I've fixed everything you've mentioned. The only thing that I couldn't do was
resize the image (XUL bug), however it looked bad at 64x64 when I tried it in
HTML anyway.

Attaching screenshot.

Comment 10

16 years ago
Created attachment 41474 [details]
screenshot of the fix

Updated

16 years ago
Blocks: 83295

Updated

16 years ago
Blocks: 50510

Updated

16 years ago
Blocks: 60541

Comment 11

16 years ago
I have the fix ready, if you are OK with the look.
No longer blocks: 60541

Updated

16 years ago
Blocks: 60541

Comment 12

16 years ago
The star looks a little big to my opinion. I really dont have issues with the
current one. Otherwise it looks "ok"
No longer blocks: 60541

Comment 13

16 years ago
As I wrote in the last comment, I can't resize it. So it's either all or nothing.
Blocks: 60541

Comment 14

16 years ago
Taking.
Assignee: blake → hwaara

Comment 15

16 years ago
Created attachment 41516 [details] [diff] [review]
Fix

Comment 16

16 years ago
Doron, Gerv, Boris, Ryan -- someone r= this baby.

Thanks.
Status: NEW → ASSIGNED
Keywords: patch, review
Whiteboard: Need review

Comment 17

16 years ago
Why did you remove the Contributors tab? I'd like it to stay. The IFRAME in the
bottom of your dialog (both as proposed by mpt and implemented by Hakan) is way
to small for our long, unsorted contributors list.

Comment 18

16 years ago
Created attachment 41537 [details] [diff] [review]
My last patch was incomplete. Here is the full one. Review requested
(Reporter)

Comment 19

16 years ago
The following must be fixed, because it would cause opening the About box to 
effectively hang Mozilla on Mac OS:
|
| window.openDialog("chrome:global/content/about.xul", "About",
| "modal,chrome,resizable=no,height=450,width=480");
|
The `modal' needs to be removed (or set to `no', or whatever). Unfortunately, 
someone else needs to do it, as Håkan is going away for a few days. Anyone?

Other problems (like fixing the fonts used, and making the window close with 
Control+W) will be filed as depending bugs.

Comment 20

16 years ago
No one else needs to do it. I will.

Comment 21

16 years ago
Created attachment 41577 [details] [diff] [review]
Full fix. This time non-modal and closes on Ctrl+W

Comment 22

16 years ago
Created attachment 41579 [details] [diff] [review]
The text in the <iframe> is displayed in the small system font. (Last patch, I promise ;) )
Here's some initial review comments:

&closeWindow; should be &closeWindow.commandkey; .
The string "Version" should be localisable.
Remove the "Hack" comment - it's not really necessary.

I'm not sure I understand your regexps; why are you not looking for
"Gecko/(\d)+" for the build ID?

Contributors. Ben is right - the box is too small. IMO the whole thing should be
a two-tab control - the first, default one being the current look and the second
being an iframe with the Contributors list in. 

Who are Support.com and what did they contribute?
What BSD-ad-clause-licensed stuff are we including?
Given that we are open source, do we need the US Government bit?

We should run this stuff past Mitchell.

Gerv

Comment 24

16 years ago
> Contributors. Ben is right - the box is too small. IMO the whole thing should
> be a two-tab control - the first, default one being the current look and the
> second being an iframe with the Contributors list in. 

"The box is too small"? If you've tried to click the contributors link, you'll
see that a new window will open. In other words, the box has nothing to do with it.

I don't think we should have another tab with this webpage in it. There's a bug
reported to have the contributors list locally as a list, when that bug is
fixed, we can have another tab with the list in it. That would be great.

But have a webpage inside it, is just ugly IMHO.

> Who are Support.com and what did they contribute?
> What BSD-ad-clause-licensed stuff are we including?
> Given that we are open source, do we need the US Government bit?

> We should run this stuff past Mitchell.

What does that have to do with this bug?  You're just making it all more
complicated now when you involve other stuff.
OK, forget the contributors stuff. The current behaviour is fine. And the legal
stuff, while needing an answer, is outside the scope of this bug.

Gerv

Comment 26

16 years ago
> I'm not sure I understand your regexps; why are you not looking for
> "Gecko/(\d)+" for the build ID?

I don't know regexps at all, I just took it from the Chatzilla code. I can
adjust that code if you show me how to.

Comment 27

16 years ago
Hakan, your lines are way too long. Please reformat them to have < 80 chars.

I agree that having a mozilla.org webpage in the contributors tab is not good.
But  I hope that the contributors list will be local before 1.0 (bug 40024). If
the contributors list is local, the tab is the better solution (I think, we all
agree on that). That tab is already implemented in the current solution. Instead
of just removing all that from the source, can't just you just comment out the
tabs for now. Or better yet, just comment out the contributors tab, leaving the
About tab there. That way, it will be easy to recreate the Contributors tab once
the list is local.

Comment 28

16 years ago
Ben, what lines are you talking about?

Having a tabcontrol with only one tab is useless and confusing. Also, since we
don't know how soon bug 40024 will get fixed I think this is safe.

It's very easy to add a tabcontrol, when we want to, later. If you problems then
- I can demonstrate the few lines of code. :)

Comment 29

16 years ago
*** Bug 40023 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
> what lines are you talking about?

In the last patch, opened in the browser:

- document.getElementById("mozillaVersion" ...
- All the long paragraphs in about.html, e.g.
  - <p>Mozilla lets you browse the Web, ...
  - <p>Copyright &copy; 1998-2001 by ...
  - <div class="govtext">U.S. GOVERNMENT END

Comment 31

16 years ago
I don't see a problem. The text is softly wrapped ow instead of hardwrapped like
before.

Comment 32

16 years ago
Also, the text is not meant to be read through the patch. Or the patch is not
meant to be read in the browser either, for that matter. It will wrap normally
in the iframe and any text editor. :)

Comment 33

16 years ago
a dialog box with no buttons?  come on, this is ridiculous.  Following Apple 
guidelines is great for mac users, but no good for windows/unix people.  Just 
because MS doesn't have guidelines for this doesn't mean we should be going 
against the de facto standard on windows, which AFAICS is one OK button and 
nothing else.

Comment 34

16 years ago
All images of Mozilla have to come out of the tree.  Please replace the image in 
the about box with a solid star, rather than use the existing mozilla one.  

Comment 35

16 years ago
I have no problem with mac guidelines, but plz don't enforce them on windows 
users, especially when most win users are used to certain 'standard' things, 
like OK buttons in dialogs....I mean, what's the point of changing that, really?

Comment 36

16 years ago
Can we get a comment from mitchell regarding the image issue?  

It's strange that Mozilla itself can't use its own images. bug 28028 .
Regarding the "OK" button issue: the OS X HIG restricting controls to the "close
button" seems to be directed at the standard window controls, not controls
within the window. While having an "OK" button in addition to the
window-supplied close button is certainly redundant, Windows users are
accustomed to having such a button in "About...", and are also unaccustomed to
using the window-supplied close button on non-resizable windows, I think that
adding an "OK" button beneath the scrolling dialog is not unreasonable.  If
there's a particular reason that redundancy is especially bad in the case of
this dialog (people expecting the dialog to do something extra when they click
OK?  I don't know), I would be interested in hearing it.

Comment 38

16 years ago
The bigger problem with the lack of the OK button in this type of dialog is that
otherwise the user has no way of closing it - consider mozilla running on a
embedded system without a window manager, and when a user brings up current
version of the about dialog he will not be able to close it...

Comment 39

16 years ago
Hakan, we, the Mozilla developers need to read the source, so the formatting of
the source matters. Long lines might look good on your VC++ editor, but not on
Unix editors. The same rules apply for HTML source and C++ source files.

Re Close button: On GNOME, about dialogs have a single OK button, which is of
course redundant to the window manager controls.
Long lines also look terrible in LXR. Please reduce the length, preferably to < 
80 chars and certainly to < 100 chars. (I find keeping stuff under 80 chars in 
XUL is very hard.)

I also agree that we need an OK button, because it's a very common thing in 
About dialogs to dismiss them, and users understand it. If you want to leave it 
off on some MacOS version to correspond to some UI guideline, fine.

Gerv
(Reporter)

Comment 41

16 years ago
This is not a dialog, so what *any* platform does with its dialogs is 
completely irrelevant to this bug. This is a window -- just like a browser 
window, or the Page Info window, or the Properties window, or a message 
composition window. None of those windows have `OK' buttons at the bottom, 
because they're not dialogs. Instead, they can be closed either with the close 
button in the title bar, or (modulo bugs) with Control+W. Just like Håkan's 
window can.

Kerz: The Mozilla Organization's trademark comedy is outside the scope of this 
bug. This patch merely alters the placement of whichever icon happens to be 
there already. If you have a 64*64 dinosaur-less star available, please attach 
it to this bug; otherwise I suggest you file a separate bug for it.

Comment 42

16 years ago
Things I don't understand:

- You claim it's a window, but the windows I've seen can be maximized, 
minimized, and resized.

- Why things are seemingly deemed windows or dialogs at random, at your 
discretion.  Not all of us have your grand scheme in mind for the UI.  If you 
just gave a little explanation or justification for your UI proposals, instead 
of just reporting them as "obvious" bugs and waiting to fight the opposition 
later, it would help out a lot.

When I open an About box on Windows, I'm used to what lots of other apps give me 
-- a modal dialog box, not a pseudo window.  I don't care about the 1% who, for 
some ungodly reason, need to copy a sentence or two out of it.

Comment 43

16 years ago
Reguardless of which breed of thing an about item is on windows it has an ok 
button in nearly all cases (in some cases they let you click anywhere in the 
window to dismiss, but obviously we aren't doing that).

If MacOS has different requirements than the other platforms then we can create 
a platform specific file for macos.  Considering that About on windows is 
basically versioning, legal and contributors whereas About on macos is about 
functionality and perhaps contributors and resources (about this macintosh) I 
think it's reasonable for us to have different xul files.

Comment 44

16 years ago
> This is a window -- just like a browser window, or [...]
> they can be closed either with the close button in the title bar, or (modulo
> bugs) with Control+W.

They can also be closed with the menu. The About window can't (at least on Unix
and Win32).

Comment 45

16 years ago
I'm not too fond with jihads, and since we can't even have the Mozilla star...
Assignee: hwaara → blake
Status: ASSIGNED → NEW

Comment 46

16 years ago
So here is my list of known about dialog forms:
SplashScreen [registration [SystemInfo]]
Logo Appname (c)info [registration [SystemInfo]]
Logo Credits

mpt made reference to macintosh apps, so i grabbed iCab and went to About iCab. 
It's screen is similar to say Acrobat Reader and the Logo+Credit style about 
dialog. I say dialog, but on macos they're really windows.

And then there's the mpt style which i can't find on my mac.

VNCServer gives program name, version, build datestamp, and current settings. 
Plus an <Okay> button.

BBEditLite gives Icon, AppName, version release date, (c)info, contact info, 
legalease: FreeWare notice, Commercial redist restriction notice
credits for product design, engineering, QA, components
system info (mem usage for app and system)
. No buttons, click anywhere to dismiss.

About This Computer
Logo, Version, Mem info.  It doesn't explain what a computer is, what finder 
is, how to use a computer, how to use finder ...
window, sizable, closable, collapsable, autosizable

iCab
Logo, Appname, Version, Scrolling{Credits}
Dialog, movable, fixed size, not closable, <Ok> button

Apple System Profiler
Appname, Creation Date, (c)info
Dialog, moveable, collapsable, closable, <OK> button

Sherlock 2 [UI not matching os9.0.4]
Icon, Appname, Scrolling{Credits} the first one sentence does mention that it 
lets you find things.
(c)info
Dialog, movable, fixed size, not closable, <OK> button

Outlook Express (4.5)
Background{SplashScreen}
(c)info, version info
no titlebar at all, it appears to be a bitmap w/ the two buttons stuck on it: 
<Support...> <OK>

Support Information is a Dialog, movable, fixed size, not closable <Save...> 
<OK>

more later, storm now.
Keywords: patch, review
Whiteboard: Need review
(Reporter)

Comment 47

16 years ago
> You claim it's a window, but the windows I've seen can be maximized,
> minimized, and resized.

I never said it shouldn't be minimizable; my original sketch shows that it 
should be. (Errr ... that's the [v] bit in the title bar, in case you were 
wondering.:-) As for resizability, there are plenty of examples in Windows 2000 
of non-dialog windows which cannot be resized, and which therefore cannot be 
maximized. Some of these, as Ben Bucksch mentioned, have a menu bar -- e.g. the 
Calculator, Minesweeper, the Sound Recorder, and the Volume Control. Others 
don't have a menu bar, e.g. the CD Player and the Character Map utility.

> - Why things are seemingly deemed windows or dialogs at random, at your
> discretion.

My discretion? Hardly. :-) Håkan asked for something to do. I suggested fixing 
`Help' > `About', and came up with a design for it. I copied, to the letter, 
the UI guidelines for the only platform which currently *has* UI guidelines for 
About boxes, Mac OS. (I went with the Mac OS X HIGs, rather than the Mac OS 
Classic HIGs, because (a) the future Mac-wise is OS X, and (b) as Timeless 
noted, Mac OS Classic apps have a mixture of the two types of About box so Mac 
OS Classic users wouldn't really mind which style was used.) And Håkan, a 
Windows user, implemented it. I had no idea there would be such `opposition' to 
such a simple UI improvement which would make Mozilla look so much more 
professional.

> Not all of us have your grand scheme in mind for the UI.

Well, I didn't have a grand scheme in mind when filing this bug, but if you 
want one, here it is ... Something should only be a dialog if there is a 
compelling reason to make it modal -- that is, if making it non-modal would be 
confusing (e.g. `File' > `Save As'), or if allowing interaction with the parent 
window could cause race conditions (e.g. confirmation alerts). So a formatting 
dialog is ok, but a floating formatting palette window is better. An `Open 
Location' dialog (as in Mosaic 1.x for Unix) is ok, but an editable address 
field in the browser window itself is better. A dialog telling me my modem has 
disconnected is ok, but a floating window (or, in Windows 2000, help balloon) 
in the corner of the screen is better. An About dialog is ok, but an About 
window is better.

Like the rest of the 99 percent of people who never need to copy stuff out of 
the About box, I don't mind if it is a dialog with an `OK' button. It makes no 
difference to me whether it is or not. But to the 1 percent of people who *do* 
need to copy stuff out of the About box, or to compare the version number in 
the About box with the version number on a Web page to see whether their build 
is up-to-date enough to run a particular XPI, or whatever, it probably does 
make a difference. And I hardly think a non-modal About window is confusing 
enough for a dialog to be necessary instead.

Note that if you make it a modal dialog you should probably make the icon 32*32 
and put it to the left of the application name (rather than centered above it), 
so that the presence of the `OK' button in the bottom right doesn't make the 
dialog look lopsided.

Comment 48

16 years ago
usability/polish, 0.9.4.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4

Updated

16 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Updated

16 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.7

Comment 49

16 years ago
I have one suggestion, and that is that the OK button be default, so hitting
return or enter dismisses it.

Comment 50

16 years ago
Created attachment 56986 [details]
A 64x64 pixel 8-bit PNG image of a five-point star without a dinosaur

Comment 51

16 years ago
Created attachment 56987 [details]
Same thing in 32x32

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.9

Updated

16 years ago
Target Milestone: mozilla0.9.9 → Future

Comment 52

16 years ago
-> nobody
Assignee: blaker → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted

Comment 53

16 years ago
*** Bug 147556 has been marked as a duplicate of this bug. ***
I don't see what keeps this bug from getting fixed. There are four patches, none
if which either got marked needs-work (with a comment as to why, of course) or
received r= / sr=.

Why shouldn't this be modal? Because there is no reason why Mozilla should keep
you from filing a bug to BugZilla while its about box is open so you can copy
Mozilla's UA string for the bug.

Why shouldn't there be an OK button? Because every windows manager except those
two and a half pointless experimental ones has a Close button in the window
decorations already. Sometimes at the top left, sometimes at the top right.
Maybe somewhere in between. To Close the window is all that OK button would do:
you cannot change any setting in an about box. You cannot confirm or submit
anything. An about box is informational only and not editable.

timeless, I don't have a Mac OS Classic computer at hand right now, so I can't
look for examples of About Boxes without buttons in that OS, unfortunately. In
Mac OS X, though, usual About Boxes only contain *information*, and the window
manager (Aqua) adds a close widget to the top left. Why Windows 2000's About
Windows box needs an OK button is beyond me.

(As to GNOME/KDE; their GUIs are mostly ripped off of Windows.)

Updated

15 years ago
Attachment #41516 - Attachment is obsolete: true

Updated

15 years ago
Attachment #41537 - Attachment is obsolete: true

Updated

15 years ago
Attachment #41577 - Attachment is obsolete: true

Comment 55

15 years ago
*** Bug 181272 has been marked as a duplicate of this bug. ***

Comment 56

15 years ago
What about having a "About Mozilla" like Phoenix has?
>What about having a "About Mozilla" like Phoenix has?

what kind of "about mozilla" does phoenix have?
Created attachment 107033 [details]
About box from Phoenix as requested

Comment 59

15 years ago
This bug seems to be revolving around UI design decisions that nobody agrees on
in a cross-platform way already.

What I personally think is that the About box should be an internal web page
that uses an optional stylesheet from the current browser theme.  The launching
of such a page within a smaller default-sized (smallish) window is easy enough
to do.  The creation of the entire dialog as presented here a dozen times as
HTML with CSS is *easy* in all forms thus far presented.

Why is this being done as anything but an HTML page launched in an undecorated
window (no toolbars/statusbar/menubar)?  The current display at the faked URI
"about:" should be almost sufficient (given the additional info/links suggested
in this bug) for display in a smaller JavaScript-launched window;

javascript:window.open("about:","__about_box__","top=85,left=40,width=450,height=350,scrollbars=yes,resize=yes");

That URI works as I would expect the About menu item to currently work.
Product: Core → Mozilla Application Suite

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design

Comment 60

8 years ago
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
Status: NEW → UNCONFIRMED

Comment 61

8 years ago
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

Comment 62

8 years ago
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

Comment 63

8 years ago
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

Comment 64

8 years ago
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

Comment 65

8 years ago
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

Comment 66

8 years ago
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

Comment 67

8 years ago
Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1.2pre) Gecko/20090721 SeaMonkey/2.0b2pre

This bug still applies to SeaMonkey 2.x, IMHO.
I suggest to set it back to the NEW state.

Comment 68

8 years ago
Might be right to set this again to NEW. 

Bug 505304 seems to be an Dupe to this Bug, but maybe it would be better, to close this one an work on the fresh Bug.
Ever confirmed: false

Comment 69

8 years ago
Since we aren't about to go back to a modal dialog any time soon I'm closing this bug as WONTFIX. Bug 505304 deals with improving the current in-tab implementation of the about: screen.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX

Comment 70

8 years ago
Actually, our current about "window" violates the Apple HIG (the toolkit dialog is a lot more in line with it).

Updated

8 years ago
Blocks: 73812

Comment 71

8 years ago
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true

Comment 72

8 years ago
Well if anything needs to be done we can do it in Bug 505304.

Comment 73

8 years ago
(In reply to comment #72)
> Well if anything needs to be done we can do it in Bug 505304.

I don't think so.
As you wrote (bug 505304, comment 6), this bug "is about moving to a dialog which toolkit apps now use".
AFAIK, it's not possible to conform to the Apple Human Interface Guidelines with the present implementation of the about: function.
Go check yourself: http://preview.tinyurl.com/myytn9

To be fair, the Apple HIG don't dictate the desired behavior of the application when the about: string is written in the browser address bar but only when the "About ApplicationName" item is chosen from the application menu (or, in the Windows world, when Help --> About ApplicationName is chosen).
So, why not keep the in-tab implementation of about: and move to a window implementation of the "About ApplicationName" item?

(In reply to comment #69)
> Since we aren't about to go back to a modal dialog any time soon […]

Why it should be a modal window?
I (and the Apple HIG) think it should be a *modeless* window. I don't see any practical advantage for the user in a modal About window.
Anyway, if Windows users cannot live with modeless windows, could it be possible to have a modeless About window on Mac OS X and a modal window on Windows?

Comment 74

8 years ago
Reopening and making this OSX specific.
Status: RESOLVED → REOPENED
OS: All → Mac OS X
Hardware: All → x86
Resolution: WONTFIX → ---
Summary: `About Mozilla' is treated very badly → 'About Mozilla' is treated very badly

Comment 75

8 years ago
Thanks Philip.
Only a note: the platform should be set to All, I'm on a PowerPC machine and I'm affected by this bug as well.

Updated

8 years ago
Status: REOPENED → NEW
QA Contact: bugzilla → ui-design
You need to log in before you can comment on or make changes to this bug.