Closed Bug 245862 Opened 20 years ago Closed 20 years ago

Preferences dialog should be at the same place on all OS

Categories

(Firefox :: Settings UI, defect)

defect
Not set
major

Tracking

()

VERIFIED INVALID

People

(Reporter: askwar, Assigned: bugzilla)

References

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040606 Firefox/0.8.0+ (NESI) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040606 Firefox/0.8.0+ (NESI) In bug 245765, the Preferences menu entry moved to the Edit menu again for XP_UNIX, but not for XP_MACOSX and also Windows. Because of this, Firefox users cannot find Preferences on the same spot for all the supported OS. That's *EXTREMELY* bad, because one of the MOST important pros of Firefox (and Mozilla) is that it is cross-platform and thus should AS MUCH as possible behave the same everywhere. With the introduced change, it no longer does. Reproducible: Always Steps to Reproduce: Start Ff on Windows, Linux, MacOS X and try to find the Preferences menu entry. Actual Results: On Linux, it is under Edit. On all the other OS, it is is still under Tools. Expected Results: According to bug 245765, GNOME HIG dictates that Preferences has to be under Edit. Because of that, the other OS have to follow. Or GNOME HIG should not be followed, and Preferences should be under Tools again. Either way is fine - it just *HAS* to be consistent. Because it makes Firefox harder to use, I'm setting severity to Major.
Depends on: 245765
This should probably be resolved as invalid. See bug 245765 comment 8.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
No longer depends on: 245765
Gnome HIG should be followed in Gnome, Apple HIG should be followed on Mac, and Microsoft HIG should be followed in Windows. It *is* consistent - with the operating system.
(In reply to comment #1) > This should probably be resolved as invalid. > > See bug 245765 comment 8. No, it should not. As I said, one of the most important aspects of Firefox/Mozilla is the cross platform aspect. If Firefox should be a cross platform application (which I hope it still should be), then it REALLY should be consistent to itself in the first place and to the OS only in the 2nd place. When menu entries are at different spots on different OS, it is no longer consistent to itself. (In reply to comment #2) > Gnome HIG should be followed in Gnome, Apple HIG should be followed on Mac, and > Microsoft HIG should be followed in Windows. > > It *is* consistent - with the operating system. So cross platform constency is not important anymore? Firefox should behave completely differnt on all the different OS it's running on?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Firefox should be consistant with the Operating System it is running on - at least in this respect. -> Invalid
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → INVALID
Verified.
Status: RESOLVED → VERIFIED
Verified.
So firefox should behave differently on each OS and should not be cross platform anymore. Further, "GNOME" is not an OS - what about KDE? There, Preferences should NOT be under Edit, as pointed out in bug 245765 comment 10.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Firefox is a GTK application, not a QT application, not to mention that integration with GNOME is being actively worked on. In this case, the GNOME HIG would most certainly apply. -> Invalid, again.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → INVALID
In that instance, Firefox's behavior should match whatever is standard for that enviroment. but this bug is still invalid, as all OS'es should not have the same behavior. -- Verified, again.
Status: RESOLVED → VERIFIED
Another question - you're saying that it should be consistent to the OS. If that's the case, why is a new "standard" theme being introduced? This theme doesn't look as "native" as the old theme on Windows. But the argument for introducing the new theme was (to my understanding), that Ff should be consistent *across differnt OS*. Now, IMO those changes contradict each other. If cross-OS consistency is wanted by introducing a non-natively looking theme, the app should behave the same on all OS. But, if the app should not behave the same on all OS (like you're saying in this bug here), then I don't understand why a new standard theme should be introduced. -> Reopened again.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
(In reply to comment #10) > Another question - you're saying that it should be consistent to the OS. If > that's the case, why is a new "standard" theme being introduced? The new theme has introduced because of licensing issues with Qute. The Winstripe theme is not the same as the Pinstripe theme, it's only similar. So Windows and Linux versions look different than the Mac OS. Invalid, again.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
> Firefox is a GTK application, not a QT application, not to mention that > integration with GNOME is being actively worked on. In this case, the GNOME > HIG would most certainly apply. A gtk application is not necessary a gnome application. There are many examples for that. And a qt application is not necessary a kde app. Again there are also many examples for that. IIRC, the so called "Gnome integration" that is being worked on, is done by Firefox developers, and not by gnome-developers. Btw, it IS confusing that under the "edit" menu one can find content-area specific commands "copy, cut, paste", and then Preferences which is completely unrelated to the other content-area. But that's not the point of this bug. Either follow the HIG of the desktop Firefox runs under (good luck with that... xfce, kde, gnome, blackbox, windowmaker, etc), or let it behave equally regardless of the desktop, and use the windows hig as base. I guess nobody ever complained about "Tools->Options" under Linux.
Fine, we're a GNOME app. Happy now? Unless someone decides to step up to maintain a KDE/qt port, we'll continue to act like a GNOME app. And plenty of people complained, GNOME people first and foremost.
(In reply to comment #13) > Fine, we're a GNOME app. Happy now? Unless someone decides to step up to > maintain a KDE/qt port, we'll continue to act like a GNOME app. Ok, I am fine with that. But be aware that I was talking about HIG and not toolkits! Toolkits don't matter for users. > And plenty of people complained, GNOME people first and foremost. I guess soon you'll have the KDE people start complaining... ;-)
no. unfortunately KDE people aren't even able to port Fx to QT :/
*** Bug 248906 has been marked as a duplicate of this bug. ***
I find it utterly idiotic to make different menues for different OS's. Consider a guidebook for firefox, you have to make different screenshots and descriptions for each OS instead of just one. Shouldnt SIMPLICITY stand above all ?? The reason that KDE people havent ported FF to qt, is most likely due to the fact, that it works just fine as it is, so why waste time.
Of course simplicity is good, but for, say, an OS X user, the expected place to find the preferences is under the menu that has the application's name in it. Anywhere else will confuse someone who is an experienced OS X user but a new FireFox user; On the other hand, there is no equivalent on Windows to the application menu. It comes down to a question of whether we're more interested in consistency cross-platform for the Firefox user who uses the app on multiple platforms, or consistency within a platform for the new user. I'd argue that since the latter is more likely to have difficulty finding things, we should design for that user, but an argument can be made either way. On the mutant third hand, is there a reason the Prefs item can't be located in more than one menu on some platforms? That way people who are new to the browser can find it where they expect from their OS (and perhaps its default browser *cough*IE*cough*), but people who use the browser cross-platform can also expect to always find it in the same place....
It just took me over a month to gather enough ambition to figure out where the options dialog went. For those of us who disabled the 'Edit' menu in userChrome.css, this is not a very happy move. I was completely boggled why all my Windows-using friends still had Tools->Options. Since the rest of the edit menu has nothing to do with functionality and everything to do with text, this is rather confusing.
Perhaps I am re-opening an ugly can of worms but... Could someone do usability testing? Instead of arguing arcane technical points and guessing what users think, wouldn't it be better to gather data and do what the users are observed to think? I am not experienced in usability testing, or else I would volunteer to do this myself.
For the 800th time since we did this: The platforms we currently support (Windows, GNOME, Mac OS X) all have "expected" locations for preferences. Obviously, this is different on these different platforms. Our goal is to behave like a regular app on all three platforms, NOT to behave like some universal browser that can be used in many places but doesn't quite fit anywhere.
*** Bug 255609 has been marked as a duplicate of this bug. ***
Can an option be added to move the options dialog between tools and edit? The only way to control cache, cookies, saved passwords, etc, etc, etc is under the options dialog. It's extremely disruptive to my computing behavior when I have to stop and actively think about which OS I'm currently running, so where the control might be right now. I use windows half the time (at work) and linux half the time (at home). Same goes for the many different keyboard shortcuts. If you believe it's best to integrate into the OS to become a "standard app" for that OS fine, it's a valid point. But make these sorts of things customizable and Firefox will be much more usable for /everyone/.
I just added my vote to this bug. It's really annoying to have two different things in Windows and in Linux when (nearly?) all the rest is the same. FYI, I'm a KDE user. Am I using an unsupported platform?
We're not going to make a cross-platform app that doesn't respect the target platform's conventions. KDE isn't unsupported, its just not the platform we're using as our baseline on *nix. With the fresh resurrection of the Qt port, I can forsee having to rework some of the #ifdefs to follow KDE's HIG as a build option (so that KDE-based distros/users can build something that feels more KDE-like). But that's future fodder, really, and outside of the context of this bug. It wouldn't change the defaults for GTK2 builds etc.
I use Firefox in Linux and Windows and I've read all the arguments here. I have a suggestion -- in addition to the the 'Options' and 'Preferences' commands in the menu, place a button on the tool bar and add a command to the right-click menu to call up the Options/Preferences dialog. This will help the multiple-operating-system-user avoid accidentally clicking on the wrong menu item ('Edit' or 'Tools'). I would add the button to my toolbar myself, but apparently there is no Tools/Preferences button available in the toolbar customizer.
*** Bug 292053 has been marked as a duplicate of this bug. ***
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
Would it be possible to make everybody happy and provide an option for this? Even if it's just one of those about:config ones. I am also pretty annoyed by the current behavior but I think it's because I use both Windows and Ubuntu every single day, Ubuntu at work, Windows on my laptops. Maybe people should have such a configuration, however, I see the point that there are also many "only Windows" or "only Linux" users which might want to see the menu item where they first expect it to be. IMHO it's a pretty sad state anyway that n different HIG exist but, well, better than none at all. Having an option would give everyone the opportunity to choose.
You need to log in before you can comment on or make changes to this bug.