88686 - 'About Mozilla' is treated very badly

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[Gervase Markham [:gerv]]

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

[Håkan Waara]

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

[Dwayne]

...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

[Håkan Waara]

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

Comment 5

[Francisco León]

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

Comment 6

[Matthew T (active 1999-2002)]

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

[Francisco León]

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

[Håkan Waara]

Most of the stuff done...

Comment 9

[Håkan Waara]

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

[Håkan Waara]

Attachment: screenshot of the fix

Comment 11

[Håkan Waara]

I have the fix ready, if you are OK with the look.

Comment 12

[Francisco León]

The star looks a little big to my opinion. I really dont have issues with the
current one. Otherwise it looks "ok"

Comment 13

[Håkan Waara]

As I wrote in the last comment, I can't resize it. So it's either all or nothing.

Comment 14

[Håkan Waara]

Taking.

Comment 15

[Håkan Waara]

Attachment: Fix

Comment 16

[Håkan Waara]

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

Thanks.

Comment 17

[Ben Bucksch (:BenB)]

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

[Håkan Waara]

Attachment: My last patch was incomplete. Here is the full one. Review requested

Comment 19

[Matthew T (active 1999-2002)]

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

[Håkan Waara]

No one else needs to do it. I will.

Comment 21

[Håkan Waara]

Attachment: Full fix. This time non-modal and closes on Ctrl+W

Comment 22

[Håkan Waara]

Attachment: The text in the <iframe> is displayed in the small system font. (Last patch, I promise ;) )

Comment 23

[Gervase Markham [:gerv]]

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

[Håkan Waara]

> 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.

Comment 25

[Gervase Markham [:gerv]]

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

[Håkan Waara]

> 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

[Ben Bucksch (:BenB)]

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

[Håkan Waara]

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

[Håkan Waara]

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

Comment 30

[Ben Bucksch (:BenB)]

> 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

[Håkan Waara]

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

Comment 32

[Håkan Waara]

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

[Rann Bar-On]

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

[Jason Kersey]

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

[Rann Bar-On]

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

[Håkan Waara]

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 .

Comment 37

[Christopher Hoess (gone)]

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

[pocemit]

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

[Ben Bucksch (:BenB)]

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.

Comment 40

[Gervase Markham [:gerv]]

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

Comment 41

[Matthew T (active 1999-2002)]

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

[Blake Ross]

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

[timeless]

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

[Ben Bucksch (:BenB)]

> 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

[Håkan Waara]

I'm not too fond with jihads, and since we can't even have the Mozilla star...

Comment 46

[timeless]

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.

Comment 47

[Matthew T (active 1999-2002)]

> 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

[Blake Ross]

usability/polish, 0.9.4.

Comment 49

[Greg K.]

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

Comment 50

[Damian Yerrick]

Attachment: A 64x64 pixel 8-bit PNG image of a five-point star without a dinosaur

Comment 51

[Damian Yerrick]

Attachment: Same thing in 32x32

Comment 52

[Blake Ross]

-> nobody

Comment 53

[Markus Långström]

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

Comment 54

[Sören 'Chucker' Kuklau (gone)]

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.)

Comment 55

[Olivier Cahagne]

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

Comment 56

[José Jeria]

What about having a "About Mozilla" like Phoenix has?

Comment 57

[Christian :Biesinger (don't email me, ping me on IRC)]

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

what kind of "about mozilla" does phoenix have?

Comment 58

[Sören 'Chucker' Kuklau (gone)]

Attachment: About box from Phoenix as requested

Comment 59

[Michael T. Babcock]

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.

Comment 60

[Robert Kaiser]

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 61

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Robert Kaiser]

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

[Andrea Govoni]

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

[Tobias Fischer]

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.

Comment 69

[Philip Chee]

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.

Comment 70

[Stefan [:stefanh]]

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

Comment 72

[Philip Chee]

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

Comment 73

[Andrea Govoni]

(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

[Philip Chee]

Reopening and making this OSX specific.

Comment 75

[Andrea Govoni]

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.