Open
Bug 73812
Opened 24 years ago
Updated 4 years ago
Browser doesn't fit with Mac OS X UI Specs (Apple HIG)
Categories
(SeaMonkey :: UI Design, enhancement)
Tracking
(Not tracked)
NEW
People
(Reporter: daniel, Unassigned)
References
(Depends on 10 open bugs, )
Details
(Keywords: helpwanted, meta)
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•24 years ago
|
||
Sending to UI:DF for UI review and comment.
Assignee: hewitt → mpt
Status: UNCONFIRMED → NEW
Component: Themes → User Interface: Design Feedback
Ever confirmed: true
QA Contact: pmac → zach
Comment 2•24 years ago
|
||
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.
Assignee: mpt → ben
Component: User Interface: Design Feedback → XP Apps: GUI Features
Keywords: meta
QA Contact: zach → sairuh
Adding dependecies.
Comment 5•24 years ago
|
||
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.
Depends on: 68098
Depends on: 75546
Depends on: 75898
Depends on: 75934
Depends on: 56995
Depends on: 74292
Depends on: 83705
Comment 6•23 years ago
|
||
Removing dependencies on bugs which, while worthy of fixing, do not actually
block adherence to the OS X HIGs.
Comment 7•23 years ago
|
||
CC-ing self, sorry for the spam
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.
No longer depends on: 104503
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
stop believing. some of us have alterior motives
Comment 15•23 years ago
|
||
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•23 years ago
|
||
ok. i'm not quite sure why i did it, but i filed bug 106312
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.
Depends on: 74292
Comment 18•23 years ago
|
||
we already suport double ended arrows, you can have any variation (including
some which are sometimes unavailable on macos).
Comment 19•23 years ago
|
||
BTW: See bug # 83643 for a diff which adds basic sheet support. Not perfect yet
by any means, but a first step. :)
Comment 20•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•23 years ago
|
Severity: normal → enhancement
Comment 24•23 years ago
|
||
moving dependency on a duplicate bug to the bug it got duped against...
Comment 25•23 years ago
|
||
This bug should depend on bug 90823 as well.
Depends on: 137523
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".
Depends on: 90823
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•22 years ago
|
||
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
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•22 years ago
|
||
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.
Depends on: 116441
Depends on: 134649
Adding 'Aqua HIG' to summary to make for easier searchs.
Adding bug 52821 since cmd-Q can cause data loss without a warning.
Depends on: 52821
Summary: Browser doesn't fit with Mac OS X UI Specs → Browser doesn't fit with Mac OS X UI Specs (Aqua HIG)
Comment 32•22 years ago
|
||
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 :)
Depends on: 193052
Updated•20 years ago
|
Flags: blocking-aviary1.0mac?
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Updated•20 years ago
|
Flags: blocking-aviary1.0mac?
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•20 years ago
|
||
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•20 years ago
|
||
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.
Summary: Browser doesn't fit with Mac OS X UI Specs (Aqua HIG) → Browser doesn't fit with Mac OS X UI Specs (Apple HIG)
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•20 years ago
|
||
can we keep bugs in the Mozilla Application Suite component specific to that
product, please? file new bugs for other products.
Updated•16 years ago
|
Assignee: nobody → jag
QA Contact: bugzilla
Comment 38•15 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 39•15 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 40•15 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 41•15 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 42•15 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 43•15 years ago
|
||
(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.
Status: UNCONFIRMED → NEW
Comment 44•15 years ago
|
||
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•15 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 46•15 years ago
|
||
This tracking bug has dependencies that are unresolved in the current builds.
Re-marking NEW. Again.
Status: UNCONFIRMED → NEW
Comment 47•15 years ago
|
||
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
Updated•12 years ago
|
Updated•8 years ago
|
Assignee: jag-mozilla → nobody
You need to log in
before you can comment on or make changes to this bug.
Description
•