User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 SUSE/1.0.4-1.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 SUSE/1.0.4-1.1 KDE provides a well thought-out and efficient means of accessing files outside of the root file system. For example, KDE applications can open up and save files to un-mounted Floppy, Network (SMB, SSH, FTP), and other Storage Media. Currently, Firefox can't take advantage of these capabilities because its “Open File” and “Save As” dialogs only see the root filesystem (in other words, only what's currently mounted). It would be very nice for Firefox to use the native KDE “Open File” and “Save As” dialog boxes because it is much more flexible and customizable than the current Firefox dialog boxes. After all, Firefox has always used the native Windows file-accessing dialog boxes when running under Windows, so it should use the KDE counterparts when running under KDE. Reproducible: Always Steps to Reproduce: 1.Use K Desktop Environment (KDE) 2.Click on File -> Open File 3.Click on File -> Save As Actual Results: A limited dialog box shows up that *cannot*: 1)Access files outside of the filesystem 2)Rename any file Expected Results: Wish to see the powerful native KDE filde dialog that *can*: 1)Access files outside of the filesystem 2)Rename files 3)Be customized Here's a screenshot of the native KDE "Open File" dialog (preferred): http://docs.kde.org/development/en/kdebase/userguide/open-file-dialog.png

this would be done only as part of the qt port. Firefox uses the gtk native dialog if you have gtk >= 2.4.

but it should be possilbe to call kfilepicker inside an GTK "powered" app. e.g. the inkscape-team managed this - you may use the GTK-Inkscape with the filedialog from KDE...

the qt port already uses the Qt filepicker. Why should the gtk port use Qt's filepicker instead of gtk's?

I want to note: The Gtk filepicker is also able to choose smb etc. But Mozilla disables that because it could not save to it.

"the qt port already uses the Qt filepicker. Why should the gtk port use Qt's filepicker instead of gtk's?" Unfortunately I never heard from the qt port again - since the message from dot.kde.org last year (september 2004): "aKademy Hackers Port Mozilla to Qt/KDE"

"this would be done only as part of the qt port. Firefox uses the gtk native dialog if you have gtk >= 2.4." If someone could point me to where I can download the QT port that uses the native KDE filepicker, I'd be very grateful. "I want to note: The Gtk filepicker is also able to choose smb etc. But Mozilla disables that because it could not save to it." Can the Gtk filepicker rename files? Mount floppies? Save to SSH, SMB, FTP, WebDav remote locations? As it stands, the *NIX versions of Firefox 1.0.4 that can be downloaded from the main site can't do any of these. The fact that Gtk filepicker might, in theory, do them isn't very consoling if it doesn't do them in practice. Anyway, the purpose of this bug is not to expand the capabilities of the Gtk filepicker, but to ask that Firefox use the KDE filepicker when the user's desktop of choice is KDE, so that users aren't confused about how to navigate "Save As" and "Open File" dialog boxes when they switch from one application to another.

> Can the Gtk filepicker rename files? Mount floppies? Can't rename files, can mount floppies. > Save to SSH, SMB, FTP, WebDav remote locations? Filepickers don't save files. They pick files. The Gtk filepicker can save to such locations, but Mozilla can not. Using Qt's filepicker would not change this. This bug as written does not belong into this component. Not sure where it does belong, trying firefox general for a start.

> The Gtk filepicker can save to such locations I meant "can choose such locations", of course.

> Filepickers don't save files. They pick files. The Gtk filepicker can save to >such locations, but Mozilla can not. Using Qt's filepicker would not change this. Then how does Mozilla save to an SMB share or FTP repository in Windows (provided, of course, the user has write permission)? Can't the same be done in *NIX?

I didn't know Mozilla could save to FTP locations on windows. It can save to SMB because on windows, the normal file i/o functions work with SMB locations. this is not the case on non-windows operating systems. this is still not a bug in ports:qt.

The Mozilla programs for Linux should allow the user to specify which local file manager is used by the program. I should be able to configure firefox to use Konqueror to instruct firefox where to download or upload files.

I vote for this bug, because the Gtk filepicker is (for me) even less usable, than the one used up to Firefox 1.0. I miss editable path and name fields, the possibility to rename files, create folders, and reload. The KDE filepicker would be the best choice for me.

I would appreciate it to have the Qt file selector too. Maybe this could be realised with an extension which simply maps calls to the GTK+ file picker to the Qt file picker. Of course the extension should check if Qt is available during the installation. But I do not know if Firefox extensions are powerful enough to do this.

SuSE Linux comes with a Firefox that has the QT file picker. I upgraded to a binary 1.5 and lost that, though. I haven't tried it, but this may be a solution http://www.kde-look.org/content/show.php?content=36077 One has to wonder what the GTK GUI designers were thinking when they made such a cumbersome file picker. Sure it's "pretty", but I value "useful" more

Oh yes please! Betting on the gtk+-horse (and recently even more so with that full Gnome-targeted integration) completely disappoints the many passionated KDE&&FF-users! It would be wonderful to be able to choose between an integration into one of the two big DEs when it comes to loading/saving files and bookmarks! Please do not take it as an offense but I think I will never be able to enjoy that standard gtk-filepicker. As opposed to some comments beforeI don't think that a complete port of FF to qt is necessary at all -- even more so since the FF-team doesn't seem to be happy and supportive about it. Why not make it a little more modular instead when it comes to those features where the app communicates with DE-features? And please don't slaughter me, I'm not a developer, just a very passionate FF-user who is not too happy about the Gnome-only way. Thanks, Daniel

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

(In reply to comment #16) > *** Bug 331054 has been marked as a duplicate of this bug. *** > As the reporter of that bug, I'd just like to join the chorus of people hollering "WTF!" The Gnome filepicker is a classic example of bad UI design. When Phil Ringnalda closed the bug, he stated that the XUL filepicker is dead, forever for reasons he wouldn't go into. Since I do other things besides follow the thousands of posts going into bugzilla every day, I'd just like to know why the heck not? Anything would be an improvement over this horrible mess that we're stuck with now. The reason I choose KDE is that the UI is intrinsically _better_. I have no idea why mozilla has chosen to cram an inferior UI down our throats, but I'd sure like resolution to it. Also would like to retag this from Enhancement to Normal, as the current status is overly dismissive of the problem from the point of view of people experiencing it.

For better or for worse, Firefox is a GTK-based app. If you want better integration with your KDE desktop, help the qt port get to a working and shippable state, but that seems to have died not once, but twice, due to lack of solid interest. Marking WONTFIX, this bug seems to have morphed into a "mix and match GTK and KDE" and we don't want to play that game.

Well, of course in the KDE forums what they say is the QT port of Firefox was never finished because the QT developers weren't given write access to the CVS tree, so they couldn't go forward. Is it that hard for Firefox to ask for a file picker to the windowing environment? Or was it marked non fix because everybody just started bashing the GTK file picker?

Don't believe everything you read in forums. http://bonsai.mozilla.org/cvsquery.cgi?who=zack%25kde.org&date=explicit

To fix this without doing a full Qt port, we'd end up carrying a lot of evil bloat in the form of extra integration and fallback code to somehow detect KDE as the environment and use that where appropriate. For the record, Bug 297788 tells the sordid tale of mozilla.org brutally enforcing equal treatment in getting full CVS access.

(In reply to comment #21) > For the record, Bug 297788 tells the sordid tale of mozilla.org brutally > enforcing equal treatment in getting full CVS access. > From my reading of that bug, it would appear that those who had the ability to handle things were being awfully stubborn in making comments like the one Boris Zbarsky made at the end of that bug - I'm guessing he didn't try google before he said that. From an outsider's point of view, it currently appears as though the QT port has been stalled by the fact that a well-known KDE developer was given the cold shoulder when he came in to help. Not good!

I've read developers saying implementing a change like this would require a huge effort because Firefox would have to figure what Window manager a user is using. It's not quite the KDE file picker, but with the change of one line of one file it can be reverted. Just follow the directions here http://konquefox.free.fr/index.html#trick_filepicker

Let's open this back up. The GTK filepicker is getting worse, along with the rest of gnome. To avoid mincing words here, it _sucks_ badly right now.

I add that GTK File Picker has a nasty bug from a lot of time: when you create a new directory where to save a downloading file the file picker lose the name of the file that you are downloading. So you have to abort the download and restart it again, then you can choose the previously created directory. This is ridicolous, also for gnome users, and cushioned only by the new ui.allow_platform_file_picker available in Firefox 2 that you can use to revert the old but good working XUL file picker.

This is ridiculous. I hate to see good software (firefox) getting ruined because of internal politics. The 'good' filepicker was replaced with a terrible filepicker. Now sensible people are asking for a great filepicker (the KDE one) and are being turned away. Is firefox developed for the developers' sake, or for the users' sake? Because if it is being developed for the users than there is no reason that the KDE dialog should not be used. I find the Gnome project very pigheaded. The recent fights with Linus (who is pigheaded himself) are proof of this. Gnome is made for idiots to use: that has been my opinion since way before Linus opened his pigheaded mouth and said that. Firefox, on the other hand, is made for intelligent, knowledgeable people to use. Those who won't use Internet Explorer or Windows just because it is shoved down their throats at every opportunity. That is why Firefox users should not stand to have these stupid UI regressions forced down their throats. I personally would love to see a QT port of Firefox.

Advocacy comments aren't helpful, and a basic violation of Bugzilla etiquette. Regardless, this isn't about internal politics, this is about whether the Linux version is built to work with GNOME or KDE. We use GNOME/GTK stock icons on dialogs, GNOME HIG conventions throughout the UI, GTK widgets where we use native pieces at all. Using a KDE filepicker, while everything else is GTK, just makes the filepicker seem like a weird bolt-on, rather than an integrated part of the experience. Good user experience is not built on building a Frankenstein of "best" parts, which is why this is WONTFIX. I don't disagree that the GNOME filepicker is annoying at times. Maybe the best solution is to resurrect and clean up the XUL filepicker, but ultimately the distros can make that call, since they're going to be driving most of the Linux-specific decisions in Fx3. As a note, it was those distros who pushed for the change because their (mostly GNOME) userbase wanted a consistent experience. In the meantime, flip the pref, use the old filepicker if the GNOME one doesn't work for you.

I agree that Firefox should not be frankensteined of best parts- and no two developers would agree on what the best parts are. But swapping out a good peice for an obviously bad one because of 'policy' (the policy of using as many Gnome parts as possible) means that the policy needs reasdresing. I did of course 'flip the pref', but I'm afraid about what will happen to Firefox in the future if decisions such as these are allowed to pass.

If the XUL filepicker (http://kb.mozillazine.org/Ui.allow_platform_file_picker set to false in about:config) isn't good enough, use gtk-qt-engine to translate GTK calls to QT ones. Works for me.

Even GTK-based Chrome / Chromium 17 is support Qt file picker since release 17. Maybe now, when Firefox lose market share to Chrome, it's time to change this five-years-old decision?

Reopen this bug! If firefox are the multiplatform browser with this not implementation not represent this idea. The browser Opera and Chrome support thsi feature!

Firefox is really behind in so many "small" but important ways. This is yet another. I'm typing this on Chrome in KDE which uses KDE's native filpicker AND file associations (mime type). Download a file, open it in Chrome, and it opens it given what KDE's file associations are set to. With firefox you have to muck around with xdg-open to get this effect.

This should be configurable. Favoring Gnome over KDE is not proper for DE agnostic Firefox.

Is Firefox really DE agnostic? Not that I've seen. What's changed since comment 27 (over six years ago) that you'd argue it's built in an agnostic way?

In my view GTK ≠ Gnome. May be I'm wrong, but it's not stated that Firefox is supposed to be targeted for Gnome only, and to treat other DEs as loosely targeted. It's based on GTK, yes. But GTK itself isn't tied to Gnome and can be integrated with other DEs properly, including KDE.

AIUI, Firefox is built on top of GTK, so it calls into that layer for most native-ish things. Isn't the KDE filepicker part of Qt? I don't think we gain much by trying to support a hodgepodge of both. gtk-qt-engine looks promising as a way to better integrate GTK apps with KDE...

> I don't think we gain much by trying to support a hodgepodge of both. Have you ever seen KDE filepcker? Have you tried to compare currently used filepicker and KDE filepicker in different use-cases? For instance - choosing photos while uploading.

Maybe some of you don`t care but I prefer Chrome/Chromium instead of Firefox when I upload photos. I just want to say that I am so disappointed.

any news?

gtk-qt-engine is dead, no support for gtk 3 where firefox is moving firefox’ qt port is also dead (i’d love to be convinced of the opposite) so i’d like to see this reopened. it’s only a matter of detecting KDE as currently open DE (i bet DE detection is done already in this codebase) and using a system call to "kdialog [--getopenfilename|--getsavefilename|--getexistingdirectory]" as backend for file pickers in that case.

First, please don't fall into the common fallacy of "this should be trivial" without knowledge of the code involved. It's rarely correct in any project, and tends to polarize responses rather than provoking action. I would still argue that a half-baked solution doesn't make sense. Having one dialog be out of place (button ordering, appearance, theme) within the app doesn't seem like a better UX overall, even if it checks more boxes. It's another behaviour to test, more code to maintain, and I don't think it gives us much.

I'm not stepping up to code this as I realize that it is NOT trivial, but Mike, I just had to reply. Please don't fall into the common fallacy of "button ordering, appearance, theme makes a solution half-baked". It might not be shiny and look like it came out of an Apple California design studio, but it _is_ better than "missing features and annoying to use" (which, arguably, _is_ half-baked). Note that "annoying to use" are even your own words (comment #27) and the missing features have been pointed out by other users here (such as trying to upload photos, see comments #39 and #40). Additionally, I am of the opinion that the file chooser dialogue should match the desktop environment, not the application. Thus, in KDE it is actually the GTK file chooser dialogue which is out of place.

comment 27 is from six and a half years ago, I would be pretty sad if that accurately represented the current state of things. (Please don't tell me if everything is the same. I would like to exist in a state of blissful ignorance instead.) That said, it's not a fallacy that a mix of UI conventions makes apps harder to use. That's pretty much down to cognitive psychology (context switching). That Firefox as a whole doesn't fit well with a KDE environment means it's actually less usable because all of the conventions are wrong compared to everything else. That context switch sucks, and IMO it's even worse if you have to context switch within an app. That's a subjective argument, of course, but I haven't seen the mix and match thing feel anything but deeply broken, whether on Linux, Mac, Windows or even on mobile OSes.

(In reply to Mike Connor [:mconnor] from comment #43) > First, please don't fall into the common fallacy of "this should be trivial" > without knowledge of the code involved. It's rarely correct in any project, > and tends to polarize responses rather than provoking action. point taken. however, code for this already exists, is tested and used in OpenSUSE.

For info about the patch that exist and tested by openSuse a new link about the subject of this ticket http://blog.martin-graesslin.com/blog/2013/12/firefox-kde-integration-in-debian-testing/

If Mozilla devs would have started their Australis... initiative with that feature then maybe the most popular "Australis Contest" addon wouldn't be the one that tries to get rid of it. Because if any feature should be copied from Chrome and people are expecting, it's this. An improved XUL picker would suffice too. More "WONTDO" for DRM, Chrome and monochrome - less "WONTFIX" for this, please. Also, OpenSUSE KDE integration for Firefox has some kind of naming bug with "#" character and probably something else. It's also semi-abandoned, which makes it not much of an option. GTK3 file picker not much better either, so just porting to it will not solve the issue.

I would like to bring this to the attention of the developers again. I really appreciate what Firefox has done to set apart most of its UI from the underlying desktop environment (with the new menu system), but not using GTK still harms Firefox' usability. Not having a native file picker is a severely limiting feature because the usual desktop-centric locations (including favorites and various network locations and virtual filesystems) are plain unavailable through any of Firefox' functions. The GTK or even worse, the XULRunner file picker is just bad and hinders any logical use (just try saving a pdf file from within pdf.js: the filename is selected but the text box is not in focus so typing will instead search in whatever directory you are looking at). Not to mention it just looks out of place. But that is secondary to the functional handicap induced by the current hodgepodge implementation defaulting to GTK. And yes, I fully understand Firefox is a GTK app under the hood. Yet it isn't, really, and even less so since the new GUI. Writing a Qt version of Firefox on the other hand is silly (as was proven by the double failure of it picking up speed before), because the duplication of effort is just ginormous. There have been patches integrating with KDE since, well, long ago, and in the eyes of anyone using KDE and Firefox, a WONTFIX is just plain silly when we know there is an existing solution. As far as I can tell, the currently available patches have not even been looked at. I would appreciate a Mozilla developer taking a serious look at the current patches to make this work. Currently, I can find ready-to-apply patches for Firefox 35.0.1 linked on the Arch User Repository here: https://aur.archlinux.org/packages/firefox-kde-opensuse/ The same OpenSUSE guy seems to already have Firefox 36 patches ready here: http://www.rosenauer.org/hg/mozilla/file/4d52d2b45cf0 I would beg you guys to take another look, but I have too much self-worth to do so. So I ask you: please, take a look and at least tell the world why you're refusing to recognize and help more than half of your users. Note that this statistic is quite ungrounded, yet if you look at the Arch Linux stats (https://www.archlinux.de/?page=FunStatistics), you will see most use Firefox, and a whole bunch use KDE. That doesn't imply all KDE users use Firefox, far from it, but still, it says you won't be catering for a niche market.

This is the reason I don't use Firefox. The reason presented for why this won't be fixed doesn't make sense either. Consistency right? Seriously? Maybe you need to realise that Firefox is not the only application on the desktop. What do you think would happen is every application on the desktop decided that because they use kit X they need to use different file picker Y? Each with its own separate configuration options and different behaviour. Would that be consistant for you? As far as I am concerned, that would be a bloody mess. One that already plagues KDE to some extent thanks to project decisions like Firefox

My first though when I found this problem is "it's probably a config issue". Little did I know that this most basic thing is a 10 YEAR OLD issue that's been tagged WONTFIX because of completely broken logic. The file picker IS NOT (and SHOULD NOT BE) a part of the application. It's a basic system utility and should be (is) provided by the system. No matter what toolkit the application uses. FF for Windows uses the Windows file picker, FF for OSX uses the OSX file picker. Why is this not the case on Linux?. The Windows users would go absolutely insane if you replaced their file picker with something else. I guess most Linux users already switched to Chromium/use Gnome. To be clear: I don't want to trivialize your work. I'm just a puny web dev who doesn't know how any of this works. What I do know is that this is not a technical problem, but a problem of priorities. I know that projects like Electrolysis are important, but what good does it do you when the most basic things are completely broken.

How can this be "Resolved"!? I am astonished to find that this has been reported over such a long time, but still haven't been fixed. The logic is simple enough. Don't re-invent the wheel. KISS. Use whatever file picker the environment is using by default. In KDE, use KDE file picker. Using anything else is dumb to the extremes.

I know this may be some religious battle going on, but seriously it does break usability when you are in your environment and try and save a file and none of your "Favorites" or pin folders are on the left because the application installs and uses some random file picker dialog prompt. It is such a small and trivial thing I don't understand why it would be fixed.

Seems KDE improve build-in support for Firefox: https://community.kde.org/Plasma/Browser_Integration but can't implement hook of file picker. Here https://launchpad.net/~plasmazilla/+archive/ubuntu/releases is plasmazilla project, that implement native file KDE picker in Firefox. Can Mozilla developers lookup those patches and integrate to Firefox core?