73812 - Browser doesn't fit with Mac OS X UI Specs (Apple HIG)

Status: NEW

(SeaMonkey :: UI Design, enhancement)

Description

[Daniel Boyd]

Someone needs to write a theme that makes Mozilla look like a Mac OS X program.
 We all know how great the browser is, but one of the most common complaints
that I hear about it is that it doesn't fit with the OS.

Along the same lines, I saw a bug that mentioned that 'Quit' was still in the
File menu.  'Preferences' is in the Edit menu and needs to be in the App menu.

Comment 1

[Zach Lipton [:zach]]

Sending to UI:DF for UI review and comment.

Comment 2

[Matthew T (active 1999-2002)]

Yes, I was reading the Mac OS X HIGs yesterday and thought, `oh boy'.

This is a meta-bug. Please file bugs for individual problems and make them 
block this one. Examples:
*   XP Toolkit: not using sheets for alerts (depends on a bug for distinguishing
    alerts from dialogs)
*   XP Toolkit (and then XP Apps: GUI Features): not putting `Quit', `About',
    `Preferences' etc menu items in the right place (the `About' problem also
    applies to Mac OS Classic, currently we hard-code it)
*   Themes: an Aqua theme (assign to Hyatt to start with)
*   Help: using the Apple Help Viewer (also applies to Mac OS Classic).

CCing lordpixel and beard for general OS X foo, and Timeless because we'll need 
to do lots of fun overlay stuff with menu items.

Comment 3

[Henri Sivonen (:hsivonen)]

Bugs that could be considered as bugs blocking this bug: bug 36305, bug 35996,
bug 62462, bug 40700, bug 39375 and bug 74242.

Comment 4

[Henri Sivonen (:hsivonen)]

Adding dependecies.

Comment 5

[Andrew Thompson]

Adding bug depends on 68098 which covers the Quit menu item position.

Of the stuff below, the dialog stuff doesn't bother me so much, as I suspect 
it'll be fairly easy once modal alerts are distinguished in XPToolkit.

The Aqua look and feel is going to require we do a 3rd skin that uses the theme: 
stuff, but that's currently hibernating. Needs someone to work on it full time 
for a few weeks, I'd suspect.

Comment 6

[Matthew T (active 1999-2002)]

Removing dependencies on bugs which, while worthy of fixing, do not actually
block adherence to the OS X HIGs.

Comment 7

[James Turner]

CC-ing self, sorry for the spam

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

-> nobody, helpwanted

Comment 9

[Greg K.]

It might be wise to make a general decision as to how much of the Aqua HIG
Mozilla wants to (or can) implement so we can start pruning some of these bugs back.

Comment 10

[Hervé]

there is a slight contradiction between this bug and bug 74292 "[RFE] XUL to
Aqua layer" :

this bugs talks about a Aqua-like *theme*, whereas 74292 talks about displaying
real Aqua widgets through some sort of layer.

you must make a choice, it's useless to developp both obviously.

if you choose to build an Aqua theme, i suppose it could easily be used on
another platform and Apple would certainly not like it (could they sue you for
doing that ???!)

Comment 11

[Andrew Thompson]

No not necessarily. One way of doing an Aqua theme is to create a Mozilla theme 
which, when it needs to display something like a button,  uses a special URL 
which provides the necessary pixels by asking MacOS to draw a button for us and 
returns those OS provided pixels, converted to a GIF or PNG.

This goes a long way towards solving potential problems because 

(i) the OS is drawing the controls, so they should look right, or very close to
(how they behave is another matter...)

(ii) it will require MacOS to render the theme, so it won't work on other 
platforms, which by all accounts removes Apple's objections. (I believe this has 
been discussed with Apple, but I don't know that "officially")

Comment 12

[Adam Masri]

I believe that anyone who wants to see an Aqua UI for Moz wants to see it with
real Aqua widgets, not pictures of them (that don't behave like real Aqua widgets).

Everyone I show Moz to gets the power of having a single UI across platforms.
But everyone understands scrollbars, buttons, and pop-up menus. Their questions
are always, why can't Mozilla look like an OS X application if it has this great
skinability functionality?

I believe this bug should be migrated over to bug 74292.

- Adam

Comment 13

[Adam Masri]

OIC... Herve, this is a meta bug to make Fizzilla behave like an OS X
application. lordpixel's previous comment about "skins" means that Aqua could be
chosen as a skin, just as we choose Modern or Classic skins now. The behavior of
the "Aqua skin" will be defined by the bugs this bug depends on.

In saying that, I notice that bug 74292 isn't listed as a dependency. Shouldn't
it be?

- Adam

Comment 14

[timeless]

stop believing. some of us have alterior motives

Comment 15

[Adam Masri]

timeless, since this is the meta-bug, then shouldn't your request be spun out
into a new bug? Please note mpt & Henri's previous comments.

- Adam

Comment 16

[timeless]

ok. i'm not quite sure why i did it, but i filed bug 106312

Comment 17

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Eric ____ did a nice Aqua Mozilla theme and got shut down by Apple (hence the
404 nature of http://www.simweb.net/eric/projects/Aqua/).

If Mozilla is to 'fit with Mac OS X UI Specs' it's going to have to be done per
bug 74292, otherwise it'll never be a total fit (double-ended double-arrow
scrollbars come to mind as one example) without reimplementing quite a bit of
Aqua  logic in Mozilla. 

I'm not saying that's the right use of resources at this time, just addressing
the intent of this bug.  Adding 74292 to the dependency list.

Comment 18

[timeless]

we already suport double ended arrows, you can have any variation (including 
some which are sometimes unavailable on macos).

Comment 19

[Robert John Churchill]

BTW:  See bug # 83643 for a diff which adds basic sheet support.  Not perfect yet 
by any means, but a first step.  :)

Comment 20

[marlon bishop]

this is a much deeper issue than it appears to be at the surface. there have
been a number of debates about whether we need an Aqua theme or not.  Or
similarly, whether we need an XP theme, Win 2k, etc.  However, we have resolved
in the current climate of frequent visual "revolutions" in OS and software, we
can't realistically chase each one of them around with a new theme.  Also, as
someone mentioned, we run the risk of violating the visual guidelines and
behaviors of each aqua and xp that comes along by doing so.  

We have been all over the place with Apple, about the Aqua theme. Most recently
i was told that they respect Netscape's desire to "be different" and actually
encourage us and others when it makes sense for a particular business.  We build
and sell our product around skinability, so it indeed makes sense for us to do
so.  (the only detail in question was our title bars not being skinned - as the
aqua and modern elements shouldn't be mixed that way they said)

However, that's not to say we shouldn't offer users a native appearance. I
believe we need to offer users a choice to fall back on.  Therefore the only
solution i can see is to serve up native widgets underneath some kind of "base"
skin which has only icons.  Ideally the widgets would be genuine, and not have
their behavior emulated, but i understand there are some giant technical
connotations with that.  

This is a major concern however, with increased emphasis being placed on visual
design in the software industry, i don't think we can hide this emerging issue
any longer.

Comment 21

[Andrew Thompson]

Marlon: you're certainly right. This is no shallow issue.

We should consider the other example of widely deployed cross platform UI that 
attempts skinnability and looking native accross different platforms: Java's 
Swing.

Swing represents the second attempt Sun made at doing this (the first was AWT) 
and saw Sun move away from native widgets into emulating look and feel using Java 
based drawing. ie, one can draw a parallel between AWT=Netscape 4 and Swing=XUL + 
skins. [*]

I don't want to debate the merits or not of these approaches - simply to say 
there's a good parallel. The Mac OS 9 (Platinum), Motif and Windows look and 
feels are all implemented purely in Java code. ie, there's nothing stopping you 
using the Windows one on Mac OS, except a tiny piece of code which checks the 
platform and refuses to run a "native" emulation look and feel on the "wrong" 
platform.

On Mac OS X Apple needed to implement an Aqua look and feel for Swing, and 
obviously they wanted it to be as good as possible.

What they did was use the Appearance Manager, a part of the Mac toolbox, to draw 
the visual look of the controls (View), while allowing Swing to handle the data 
(Model) and the user interaction (Controller). Obviously they tweak the 
controller here and there to improve the feel and make it more Mac like, but 
Swing is designed to allow this.

The Appearance Manager was introduced with the Platinum look and feel in Mac OS 8 
to allow one to create custom controls which look like the standard controls the 
OS provides. Of course, its unlikely Apple really meant anyone to do a whole 
application using it (before things like Swing and Mozilla I doubt anyone 
perceived the need) - but it proved up to the challenge of providing the 
functionality to do everything Swing required of it...

So by now my point should be clear - this has already been done. The Aqua 
plugable look and feel for Swing shows its possible to implement a rich widget 
set using the Appearance Manager. It looks and feels pretty damn good - good 
enough for Apple to ship it as part of their OS. 

I like Modern. I think its appropriate to ship it, even to use it as the default, 
but when it comes to a native look and feel I think something built on the 
apperance manager and not native widgets has a much greater chance of succeeding.

This approach is good enough for Apple. If using native widgets was a small 
problem, then I'd be trumpeting it from the rooftops, but currently, even though 
Mozilla has very few native widgets on Mac OS, they suck up a lot of time and 
have fewer features than on other platforms.

(I'm speaking of Mozilla's native menu implementation on Mac OS, which, eg, does 
not support icons in menus).

To me its balance - eg, I'd like to see native contextual menus, I think they'd 
be relatively easy to do (because they float above everythhing) and offer a big 
usability win over the XUL ones - but I also know we don't have the resources to 
develop multiple implementations of the complete widget set (eg, the worst case 
would be XUL + Mac Widgets + Windows Widgets + Linux Widgets) 

I think we should go native where it makes sense or there's no alternative, but 
follow the relatively proven lead of Apple and Java's Swing to minimise the work 
required to support our diverse range of platforms.

Thanks for your  time :)

[*] Contrast IBM's SWT for Java which runs on Windows and Unix but not Mac OS, 
which persues native widgets while trying to avoid the pitfalls of AWT.

Comment 22

[darrend]

One benefit of native widgets is that you don't need to worry about how well
they emulate their correct behaviors. A number of bugs I've been following are
all related to incompatibilities between 3rd party apps and the gfx widgets,
with incomplete emulation of native behavior as the root cause of the reported
problems.

I don't work with the Mac stuff, but here are some examples relating to the
Windows platform:
- Many scrolling apps (like mouse drivers) don't work since the gfx widgets
don't use the Windows VSCROLL style and also don't listen for VSCROLL messages.
- As a separate but related issue, the above also causes problems when certain
form elements are present that still (currently) use native widgets, which
causes unexpected scrolling behavior.
- Many 3rd party apps won't work since the url box is no longer a native Edit
control, and this breaks one or more features of many popular apps like download
managers, icq, im, etc.

It seems to me that maintaining broad compatiblity with 3rd party apps should be
a top priority, and, for all their complexity, the native widgets offer the best
possible future-proof compatibility in all aspects of visual, behavioral and
cross-app integration.

Comment 23

[Andrew Thompson]

Yes.

But there aren't enough engineers to port Mozilla to even the 3 core platforms 
(never mind all of the others) with native front ends. This isn't theory - 
Netscape 4 and what never became the 5.0 release are an elegant proof.

-> Newsgroup n.p.m.ui would be a better place to continue this discussion.

Comment 24

[Dave Miller [:justdave]]

moving dependency on a duplicate bug to the bug it got duped against...

Comment 25

[Nick Kocharhook]

This bug should depend on bug 90823 as well.

Comment 26

[Bill McGonigle (not currently reading bugmail; please contact directly)]

updating URL to reflect reorg at the ADC site.  Old URL was:
http://developer.apple.com/techpubs/macosx/SystemOverview/AquaHIGuidelines/

added depends on for bug 90823, "Relaunching or clicking Dock icon should
display last minimized window or create new window".

Comment 27

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Added depends on for bug 122126, "Save and Print dialogs should be sheets".
Added depends on for bug 129398, "Remove the Print Preview menu item under OS X".
Added depends on for bug 143702, "Mac OS X: need to provide just a Mozilla.app
directory (not a folder w/ app & files".

Comment 28

[riscky]

May I also suggest this bug depends on

bug 150028 option-minimize displays hidden window in dock

bug 149418 Create Dock item when URL text or Bookmark dragged to the Dock

Comment 29

[Bill McGonigle (not currently reading bugmail; please contact directly)]

I think this one is specifically for behaviors & appearances that are in
conflict with HIG.  

It seems to me that bug 150028 is just a bug (someone forgot to ignore the
hidden window), and bug 149418 is an RFE that'd be possible and cool with OS X,
but not necessary to comply with the Aqua HIG.  Correct me if I'm wrong - I
certainly don't have it memorized.

Comment 30

[riscky]

Well I would consider bug 150028 a candidate since the window is normally
hidden, but under certain conditions, it could appear in the dock (minimizing
all Mozilla windows). With 10.2 this could cause some problems. Mozilla uses
hidden window to keep Mozilla running when all other windows are closed. If a
user minimizes all Mozilla windows, closes hidden window from the dock, 10.2
allows one to do this, one could effectively quit Mozilla from the dock by
closing a window. Such a behavior is not very “Mac like” and must violate some
written or unwritten Apple HIG. 

Bug 149418 is very suspect I do agree. I am not sure if it is described in
apples HIG at all. However, I would assume it is. Both IE and OmniWeb support
this; I would assume iCab and Opera do as well. I would assume the idea might
have come from some Apple HIG.

Of the two, I think bug 150028 does fit in the scope of this bug while bug
149418 is a maybe. Just a suggestion, you decide.

Comment 31

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Adding 'Aqua HIG' to summary to make for easier searchs.
Adding bug 52821 since cmd-Q can cause data loss without a warning. 

Comment 32

[Lewis Jardine]

bug 48333 should probably block this bug instead of bug 52821 - bug 52821 is
about removing (or otherwise modifying) accel-Q on platforms _other_than_mac_ ,
as mozilla's accel-Q behaviour is decidedly unusual on other platforms. Bug
48333 proposes to add a warning dialogue when closing mozilla if it would cause
dataloss. 

(dataloss being defined as losing data the user has entered into a form, see my
rant at the end of bug 52821 for why this is sensible mac-like behaviour :)

Comment 33

[Bill McGonigle (not currently reading bugmail; please contact directly)]

This bug predates Firefox.  Should we:

a) add Firefox bugs here
b) keep this for core and Mozilla and add FireFox-specific gaffes to a new bug
c) create a bug for Firefox, one for Core, and one for Mozilla, moving
dependencies as appropriate, making this bug grandfather meta for all Aqua HIG work

a) doesn't fit into the Product/Component hierarchy neatly
b) would lead to duplication of dependencies for Core bugs
c) is the most normal form but results in the most bugs to keep straight

Comment 34

[louis bennett]

i think we should just add a "apple-hig" keyword (or something similar). that way, any mac product can 
use them, and they're much easier to query.

Comment 35

[Prognathous]

Apple Human Interface Guidelines (published 2004-12-02) replaced the, now
deprecated, Aqua Human Interface Guidelines (published 2002-06-01). More here:
http://snipurl.com/c7lv

Changing summary accordingly.

Prog.

Comment 36

[Henri Sivonen (:hsivonen)]

The way I see it is that the Mozilla suite isn't getting significant UI
attention anyway, so focusing on Firefox makes more sense. I would not mind if
this bug morphed to a Firefox tracker. My personal opinion only, though.

Comment 37

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

can we keep bugs in the Mozilla Application Suite component specific to that
product, please? file new bugs for other products.

Comment 38

[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 39

[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 40

[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 41

[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 42

[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 43

[Ashley Bischoff (blog at handcoding.com)]

(In reply to comment #42)
> 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

This tracking bug has dependencies that are unresolved in the current builds. Re-marking NEW.

Comment 44

[Peter da Silva]

Thank you, Alex. There's so much that doesn't work in the latest Firefox.

* It doesn't use the Apple keychain for passwords
* Clicking on the dock icon won't open a browser window if the downloads window is open.
* It doesn't support services.
* It doesn't use Apple's spelling dictionary.

There's so many areas where it's clearly a non-native application. It's almost as bad as using Safari on Windows. :)

Comment 45

[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 46

[Ashley Bischoff (blog at handcoding.com)]

This tracking bug has dependencies that are unresolved in the current builds.
Re-marking NEW. Again.

Comment 47

[Andrea Govoni]

The URL to the Apple Human Interface Guidelines in the details of the bug is wrong. It should be set to:

http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/index.html#//apple_ref/doc/uid/20000957