233893 - OK / CANCEL buttons are reversed in all dialog boxes.

Status: RESOLVED WONTFIX

(Firefox :: General, enhancement)

Description

[Gary Russell]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

OK / CANCEL buttons are reversed in all dialog boxes.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.



Expected Results:  
This is a 20+ year old standard started by IBM in the DOS days.  left to right
and top to bottom.  I believe that KDE uses this same standard so Why have you
chosen to reverse theM?  Makes no sense.  Perhaps the Mac users and Red Hat
users would be comfortable with this arrangement, but Window's users and KDE
users would not be.  do the math!  How many users are you willing to alienate? 
I know that I will not be using Firefox or any browser based on that code until
these buttons are fixed.

Comment 1

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

firebird issue, as you seem to be using firebird.
mozilla uses a different button layout.

Comment 2

[PikeUK]

(In reply to comment #0)
> Perhaps the Mac users and Red Hat
> users would be comfortable with this arrangement, but Window's users and KDE
> users would not be.  do the math!  How many users are you willing to alienate? 

The change does not affect Windows users. I believe the intention is for Firefox
to follow the GNOME Human Interface Guidelines, hence the backwards buttons.

Comment 3

[Gary Russell]

Change does not affect Windows users?  DOH! What do you think I was using? the
linux version?  Yes, it does affect the Window's version.

Besides, why Gnome standard? Then you should have a KDE VERSION , too. If Gnome
wants to be like a MAC - -fine.  But as a Windows user and part-time KDE Linux
user, I WILL NEVER use Firefox if the OK/CANCEL buttons are reversed. Besides,
there are still MORE KDE USERS than Gnome users. Who is buying you off?

If this is where Mozilla is headed, then I will have to find another browser to
use.  I have been using Netscape since before IE was even out and then moved on
to Mozilla.  It's extremely disappointing that you can even get the buttons right.

Comment 4

[Jason Barnabe (np)]

A suggestion from
http://forums.mozillazine.org/viewtopic.php?t=52251&highlight=ok+cancel

Add this to userChrome.css

.dialog-button-box {
  -moz-box-direction: reverse;
  -moz-box-pack: center;
}

.dialog-button-box spacer {
  display: none ! important;
}

This is likely going to be resolved wontfix. Hopefully adding those entries will
put it the way you like it.

Comment 5

[Gary Russell]

Thanks for a possible 'fix', but i have a better solution. I simple will not
support the Firefox project until it IS FIXED. Desktop Linux will not be using
Gnome if they want to attract Window's users. PERIOD

Comment 6

[Erich 'Ricky' Iseli]

Having a good integration into the system is important, agreed. But Linux !=
Gnome. So if some Gnome specification is being followed, then a KDE
specification should be followed as well.

Is there a way for Mozilla to know on what desktop it's running and position the
icons accordingly? I wouldn't be bugging about this if this "feature" wouldn't
be causing a dataloss in some situations.

I've just tried Gimp on KDE and the OK button is always on the left, the cancel
being in the right bottom corner.

Comment 7

[Marek Stępień [:marcoos, inactive]]

(In reply to comment #6)
> Having a good integration into the system is important, agreed. But Linux !=
> Gnome. So if some Gnome specification is being followed, then a KDE
> specification should be followed as well.

But for Firefox as a GTK2 application, Gnome is the natural primary platform.
So it's nothing wrong in supporting Gnome Human Interface Guidelines. And it's
better to support Gnome's HIG than not support any HIG at all.

(However, if the buttons appear this way in Windows - then it's a real bug)

> Is there a way for Mozilla to know on what desktop it's running

Probably yes. Mozilla could check if such things as gnome-panel and/or Metacity 
are running on the same XFree86 virtual screen, or is it kwm and kdesomething.

The problem is that users can make themselvs hybrid environments. (E.g. use kwm
as window manager but don't use other KDE tools).

> I've just tried Gimp on KDE and the OK button is always on the left, the cancel
> being in the right bottom corner.

Which version of the GIMP have you tried? The old GIMP 1.x is not HIG-compliant.

The new GIMP 2.0 has OK on the right and Cancel on the left, just as other Gnome
HIG-compliant apps (such as GNUmeric, Bluefish or GEdit).

Comment 8

[Yannick Koehler]

Argh, this explains a lot.  This changes really get my use of firefox slowed
down.  Now I have to double-check every dialog.

I'm switching to Mozilla if it doesn't do it.  

Comment 9

[Brian Bennett]

(In reply to comment #8)
> Argh, this explains a lot.  This changes really get my use of firefox slowed
> down.  Now I have to double-check every dialog.
> 
> I'm switching to Mozilla if it doesn't do it.  

Just to balance the vocal opposition, I for one *prefer* the GNOME HIG button
layout that is used by Firefox.  I think that Apple did the right thing, GNOME
did the right thing, and Firefox is doing the right thing.  I'm right handed so
my mouse cursor ususally hangs out on the right side of the screen for me when I
grab it.  When I request an action and the application prompts me, I'm naturally
going to click ok because that's what I wanted to do.  Having GNOME-HIG ordered
buttons means I don't have to move my mouse as far to get my work done.

Secondly, I've used Firefox on Windows and Linux ever since it was called
Phoenix and I've never once had an issue with button placement because I read
the buttons.

Thirdly, Firefox should not be trying to guess the order that I want my buttons
at runtime because I don't use GNOME or KDE.  Take for example this scenario:

1.  Running just wmaker, launch Firefox.  Doesn't detect G or K, defaults to G.
2.  Running just wmaker, launch kmail, then launch Firefox.  Detects kdeinit
running and changes my buttons.  User thinks "WTF??  These buttons are moving
around like crazy!"

Furthermore, IMHO, the already setforth button reversal directives for
UserChrome.css is sufficient.  People don't need their preference dialogs
ladened down with such trivial things as button order.

In conclusion, don't listen to the KDE whackos.  Firefox is better off the way
it is.

Comment 10

[Gary Russell]

Calling users names is certainly not productive -- however -- I'm no more of a
wacko than you are. Each to their own opinion and I FOR ONE DO NOT THINK that
Apple got it right. Apparently, you are dyslexic.  THE STANDARD was written
almost 30 year ago by IBM with DOS applications THE WAY WE READ IN THE USA. 
LEFT TO RIGHT, TOP TO BOTTOM.  THE OK button has been and should always be on
the LEFT or on the TOP.

Call it a HIG or what ever you want to call it.  IBM's standard has been around
much longer than Apple, Microsoft, or Gnome!  If you are ass-backward, then BUY
an Apple.  IF linux wants Windows converts, then use the IBM standard.  Simple
as that.  I certainly will not use or recommend Firefox or Gnome or ANY app/OS
that has the buttons reversed. 

Comment 11

[David P James]

Does anyone happen to know what checkin was responsible for this bit of 
insanity? So I can check it back out on my own builds (assuming I even bother 
to build them anymore - this pro-GNOME/anti-KDE BS that keeps occurring at 
Mozilla is becoming too much). 
 
Anyway, now we're flipped with respect to Mozilla, with respect to Firefox on 
Windows and with respect to KDE, which, as Gary has pointed out, is where most 
of the Linux growth is going to be. And most importantly we're flipped with 
respect to most users' experience for... what? The sake of GNOME's HIG? That 
same HIG, btw, says that preferences should be under Edit (they even take a 
shot at KDE in the HIG itself), so I guess we should go back to Edit | 
Preferences too then... 
 
Let's just back this change out, stick with what works and those who really 
really prefer GNOME's HIG can flip it using some userChrome.css hack. 
 
But I doubt this will be fixed, more likely to be WONTFIXed in fact. Whatever. 
It took me this long to notice it since I've been using Konqueror anyway for a 
multitude of other reasons (faster, saner, no "mailto: is not a registered 
protocol" errors, decent stock of default features, etc) 

Comment 12

[Mike Connor [:mconnor]]

its a GNOME app, not a KDE app.  There is a bug that GTK1.2 builds use the GTK2
button ordering, but that's not really the issue reported here.

David, we might actually move to Edit->Preferences on GTK2 builds, I've been
meaning to talk to Ben on that one.  

Like it or lump it, on Linux and other platforms that use GTK, we're going to
integrate as much as possible with platform standards and defaults.  We do that
with OS X (although we could be better) and with Windows.

Comment 13

[Kuba Suder]

Hi,

  I believe Gary is right, although he hasn't chosen the best way to tell you
that. Firefox should detect what environment is it working in. KDE and Windows
users really can get confused if the button order is other than the one they are
used to. I have personally had a few situations where I have clicked the wrong
button, because I am used to having OK on the left, and this time it was cancel
not OK.

  If you want to respect Gnome users and let them have their own standard, you
should also respect the rest of the world and their standards. You want Firefox
to be used not only by Gnome users, but also KDE users, Windows users and the
entire world :) don't you ?

Comment 14

[Mike Connor [:mconnor]]

sure, better integration with KDE would be nice, but we can only really go one
way or the other on this one.  Builds using the GTK2 toolkit will absolutely
utilize GTK2 button ordering conventions (and eventually more GNOME
conventions).  We're aiming for much better GNOME compliance where possible.  If
we still had a qt (KDE) port this wouldn't be an issue, but the port didn't have
maintainers/developers and was eventually dropped.

Like I said, there is a bug on GTK1.2 button ordering vs GTK2 builds, but only
GTK builds would see the fix.  If you want GTK2+XFT you'll need to deal with the
button ordering.  Once the GNOME stock images are hooked up it should be easier
to tell the buttons apart.

Comment 15

[PikeUK]

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