Closed Bug 477115 Opened 17 years ago Closed 15 years ago

uriloader/external-protocol-service opens wrong program

Categories

(Firefox :: File Handling, defect)

x86
Linux
defect
Not set
minor

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: to.roma.from.fx, Unassigned)

Details

(Whiteboard: [CLOSEME 2010-11-15])

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121621 Ubuntu/8.04 (hardy) Firefox/3.0.5 X-FirePython/0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121621 Ubuntu/8.04 (hardy) Firefox/3.0.5 X-FirePython/0.1 Under GNU/Linux (Kubuntu 8.04), opening a file as the docs[1] suggest opens a Konqueror window for any kind of file, even if the association is to other program than Konqueror. [1] https://developer.mozilla.org/En/Opening_a_Link_in_the_Default_Browser Reproducible: Always Steps to Reproduce: 1. Install the Download Statusbar[2] add-on; 2. Download any file; 3. Double-click the file’s entry on the panel. [2] https://addons.mozilla.org/en-US/firefox/addon/26 Actual Results: Konqueror opens, which is however smart enough to open the correct application. But the Konqueror window stays on the screen. Expected Results: Firefox should have determined the association itself by using more appropriate tools such as xdg-open(1).
Are you the developer of the statusbar addon ? [1] is for external protocol schemes and if you open a file:// URL it will use the default handler for file:// . That means, the interface does what it should do.
No, just a user who is somewhat annoyed by the behavior. Opening files didn’t work at all in earlier versions of Fx (and of the add-on), now it works as described above. I looked at the add-on’s source, half expecting to see something like “if(env == windows) exec("start " + file); else if(env == kde) exec("konqueror " + file)...” but I only saw references to standard Mozilla APIs. So I filed the bug here because it looks like a Mozilla issue, not the add-on’s. Are you sure that under KDE the API runs the right command? I tried to check but Firebug won’t let me access Components.classes.
I just did a strace. The source of the misunderstanding seems to be mimeTypes.rdf under ~/.mozilla with these lines: <RDF:Description RDF:about="urn:scheme:externalApplication:file" NC:prettyName="konqueror" NC:path="/usr/bin/konqueror" /> Is that the default setting, or did KDE itself mess with the file, or did I unknowingly do something to that effect? I’m pretty sure I didn’t specify Konqueror when asked what to do with a file after clicking on a link, as that would make no sense, and anyway it’s incredibly difficult to pick an application given the GTK autocompletion that always gets in the way and lags in /usr/bin (okay, that’s unrelated to Mozilla itself). KDE is 3.5.10 in case that matters.
The Api is only using the OS default for external protocols (protocols not files !) and isn't Konquere the default KDE filemanager ? I can't see a bug here.
Let me clarify. Konqueror is a file manager, so it can be thought of as a handler for _directories_, not files. One uses Konqueror, or Krusader, or Nautilus, or MC, even Windows Explorer—to move files around, not to work with actual content of files. So it’s wrong to have Konqueror to open a text file, as it will have to run Kate or other text editor for that, and two applications will be started when only one is needed. The KDE’s way of opening files is using kfmclient(1), Gnome uses gnome-open(1), the portable script is the fd.o-supplied xdg-open(1). I’ve just replaced the offending item with xdg-open and now things work perfectly. Please consider making this change for the Mozilla distribution. Or maybe the Konqueror reference came from elsewhere?
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO. Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME. This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
Whiteboard: [CLOSEME 2010-11-15]
No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.