In GTK, as in Windows and Mac, there is a common control used for selecting files. For Windows and Mac Mozilla uses the control of each platform. However, when it comes to Linux, it uses a different one, confusing the user at first and anoying it later when it lacks many of the features the regular one has (creating directories, deleting files, moving files, filtering on part of the name and with Ximian's Gnome 1.4 GTK's modifications: going to your home directory, to your documents directory and to your desktop). Other thing to notice is that the current one is generally very slow to move between directories, not a case with the native one. There are some bugs with Mozilla's current filepicker that would vanish if this bug is fixed. Check bug 75838, bug 57214 and bug 57215.

->bryner.

I think this would be the right solution to bug 72482.

Until the GTK filepicker properly handles Unicode strings, there is no way we can use it... The Windows/Mac controls actually support this, so we have no need to roll our own there.

So that means that you can't convert the strings from/to whatever GTK uses? If not then, what would you exactly need from GTK so that I can file a bug in GTK's bugzilla about that particular issue? From personal experience I think that this is a very important usability bug, since the current filepicker is used a lot and it does not work well at all.

GTK uses single-byte strings. This is acceptable for languages that can be written in single-byte encodings. It completely fails for ones that need a multi-byte encoding (many Asian languages). This issue is known to the GTK developers, afaik -- it's just not high on their priority list. However, Mozilla is commited to being localizable to whatever language its users are using. If we want to be able to label things in the filepicker with multi-byte strings or if we want to browse filenames which include multi-byte characters we have to use our own filepicker.

I guess I'll have to hold onto this bug until GTK's filepicker progresses to the point that we can use it.

Hmmmm. In principle, this sounds like a reasonable thing to do, but the last time I checked the GTK filepicker box, the user-experience seemed just plain bad. So I'm not convinced this is the right thing to do even if the i18n issues get sorted out.

I've created a new bug that discusses the need for directory bookmarks and "create new directory" features in XP filepicker. See bug 112900, which I'm adding to this bug's dependencies (eventual resolution of bug 112900 will make most of this bug obsolete).

Bug 115981 has nothing to do with the Linux filepicker, sorry. It's a Windows bug.

I suggest to close this bug as invalid, since there is no platform consistency on Linux in any way. The filepickers in Gnome apps, KDE apps, and other apps like StarOffice differ wildly and offer different features, and similar features in a different way. The discussion in related bugs (eg bug 125133) are open to consider the best of any of these different filepickers for inclusion, but I am strongly against mimicking a single one (and especially against mimicking the Gnome filepicker because it lacks several features, e.g. the KDE picker or the StarOffice picker have).

I think this has been fixed.

No specific bug / patch mentioned as the fix. -> WORKSFORME

For what it's worth, we know exactly what fixed this -- turning on the GTK filepicker. It's just that it's not worth my time to search for that bug number (or to correct the now-incorrect resolution on this bug).

Per comment 13.