317895 - button placement counterintuitive in 'save as' dialog

Status: RESOLVED WONTFIX

(SeaMonkey :: General, defect)

Description

[Keith MacLeod]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050913 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050913 SeaMonkey/1.0a

The positions of the save and cancel buttons are reversed as compared to the standard placement in Mozilla in the 'save as' dialog.

It's not clear to me if this is a bug in Seamonkey per se, or whether it's with the Gnome component, since it seems that that's what is being used, but the behavior is now different from what it was previously, and inconsistent with other UI components, both functionally and visually.

Reproducible: Always

Steps to Reproduce:
1.Pick any link, right-click, choose 'Save Link Target As...'
2.Note the cancel button to the left of the save button.
3.Allow your mind to boggle at the complete inconsistency with the rest of the interface.

Comment 1

[Adam Guthrie]

According to bug 110647 we don't do this in the Suite yet...

Comment 2

[Andrew Schultz]

bug 110647 is actually the reverse of this bug.  The problem here is that gtk2 builds invoke the gtk2 file picker which has gnome-ordered buttons while the rest of the app is backwards (as described in bug 110647) and Keith is requesting that the buttons in the file picker get switched...

But since it's not our dialog and we can't control it this is INVALID

fixing bug 110647 would switch everything else to match the gtk2 file picker

Comment 3

[Keith MacLeod]

(In reply to comment #2)
> bug 110647 is actually the reverse of this bug.  The problem here is that gtk2
> builds invoke the gtk2 file picker which has gnome-ordered buttons while the
> rest of the app is backwards (as described in bug 110647) and Keith is
> requesting that the buttons in the file picker get switched...
> 
> But since it's not our dialog and we can't control it this is INVALID
> 
> fixing bug 110647 would switch everything else to match the gtk2 file picker
> 

Well, then, I hope that noone decides to go and fix bug 110647, then all the buttons on Seamonkey will be exactly reversed from what I (and others I would imagine) are accustomed to.

Seriously, there is a usability issue here. Waving one's hands in the air and saying 'it's not ours' doesn't make it disappear. The real question is why is the Gtk dialog being used at all? Or am I missing the part where someone said that this was a temporary measure until the bugs were ironed out of the new and improved Mozilla-chrome-native save dialog?

Comment 4

[Andrew Schultz]

The idea is to make the dialogs familiar to gnome users (have a common UI across all gtk apps).  I think this change is probably inevitable.  You can get the XUL dialogs if you use a gtk1 build.

Comment 5

[Tony Mechelynck [:tonymec]]

You can even get the XUL file picker (which, by now, has its buttons in Gnome ordering) by setting ui.allow_platform_file_picker to false in about:config

Resolving WONTFIX as the trend is to match the platform's button ordering.