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)

PowerPC
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

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.
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
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
Bugs that could be considered as bugs blocking this bug: bug 36305, bug 35996, bug 62462, bug 40700, bug 39375 and bug 74242.
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: 81814
Removing dependencies on bugs which, while worthy of fixing, do not actually block adherence to the OS X HIGs.
No longer depends on: 35996, 36305, 62462, 74292
CC-ing self, sorry for the spam
Depends on: 103422
-> nobody, helpwanted
Assignee: ben → nobody
Keywords: helpwanted
Depends on: 104503
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
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 ???!)
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")
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
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
stop believing. some of us have alterior motives
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
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
we already suport double ended arrows, you can have any variation (including some which are sometimes unavailable on macos).
BTW: See bug # 83643 for a diff which adds basic sheet support. Not perfect yet by any means, but a first step. :)
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.
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.
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.
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.
Depends on: 115265
Severity: normal → enhancement
Depends on: 127704
Depends on: 16203
Depends on: 131243
Depends on: 120284
Depends on: 124622
Depends on: 114445
moving dependency on a duplicate bug to the bug it got duped against...
Depends on: 134447
No longer depends on: 131243
This bug should depend on bug 90823 as well.
Depends on: 124617
Depends on: 141007
Depends on: 54488
Depends on: 133963
Blocks: 102998
No longer blocks: 102998
Depends on: 62495
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".
Depends on: 122126, 129398, 143702
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.
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: 53927
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)
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: 14211
Depends on: 206636
Depends on: 177945
Flags: blocking-aviary1.0mac?
Depends on: 262389
Depends on: 262381
Depends on: 231313
Depends on: 206649
Product: Core → Mozilla Application Suite
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
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.
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.
can we keep bugs in the Mozilla Application Suite component specific to that product, please? file new bugs for other products.
Depends on: 282193
No longer depends on: 282193
Depends on: 393227
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
QA Contact: bugzilla
Depends on: 456506
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
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
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
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
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
(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
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. :)
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
This tracking bug has dependencies that are unresolved in the current builds. Re-marking NEW. Again.
Status: UNCONFIRMED → NEW
Depends on: 460699
Depends on: 88686
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
Assignee: jag-mozilla → nobody
Depends on: 1692205
No longer depends on: 1692205
You need to log in before you can comment on or make changes to this bug.