Bug 125104 - problem running url launcher of the desktop
problem running url launcher of the desktop
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nautilus (Show other bugs)
2
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Alexander Larsson
:
: 126279 127444 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-02 14:53 EDT by Roi Illouz
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-12 06:34:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Adds the .desktop extension to links (692 bytes, patch)
2004-07-09 14:50 EDT, Carlos Rodrigues
no flags Details | Diff

  None (edit)
Description Roi Illouz 2004-06-02 14:53:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040510 Epiphany/1.2.4

Description of problem:
when dragging the url from the mozilla 
browser to the desktop the result is a
desktop entry in the name of the url 
example:
easy_enter_bug.cgi
this entry cannot be run by double click because there is no
file association to the specific file extenstion. 
there is a nice message telling me because of the reason above 
I should rename the entry and take out the file extension
this works but or nautilus will regard browser url nicley
or the browsers should fit to nautils schema
either way my 10 year old girl have trouble saving here url's
on the desktop and the entire idea is that she could work on Linux
not me :-)


Version-Release number of selected component (if applicable):
[roi@chayelx roi]$ rpm -q nautilus
nautilus-2.6.0-4

How reproducible:
Always

Steps to Reproduce:
1.drag & drop a mozilla url to the desktop
2. double click on the result

    

Actual Results:  can't run the url need to rename it

Expected Results:  the browser opens with the saved url 

Additional info:
Comment 1 Carlos Rodrigues 2004-07-09 14:50:04 EDT
Created attachment 101764 [details]
Adds the .desktop extension to links

The links are broken because the file gets no .desktop extension. This patch
adds the .desktop extension to URL links, thus fixing the problem.
Comment 2 Alexander Larsson 2004-08-26 09:42:18 EDT
This is very strange. The contents of the desktop file should be
enought to get it recognized as such.
Comment 3 Alexander Larsson 2004-08-26 09:57:32 EDT
*** Bug 126279 has been marked as a duplicate of this bug. ***
Comment 4 Alexander Larsson 2004-08-26 10:00:09 EDT
The patch is wrong btw. This is a very lowlevel function that creates
a file with a given filename. It should not create a file with a
different filename. All sorts of things will break.

If adding .desktop is right in this case we should do that at the
place where we accept mozilla drops.
Comment 5 Carlos Rodrigues 2004-08-26 14:21:56 EDT
The contents should be enough but when the file ends up with an 
extension other than .desktop, it takes precedence over the content. 
Since the .desktop extension doesn't show, I see no problem in just 
adding it in the appropriate place.
Comment 6 Alexander Larsson 2004-09-02 08:11:56 EDT
I'm not saying when doing that operation you shouldn't add desktop.
Just that its the wrong place in the code to do so. It will break code
that expects that when you create "foo.desktop" with this API, a file
called "foo.desktop" appears, not "foo.desktop.desktop".
Comment 7 Carlos Rodrigues 2004-09-04 19:43:28 EDT
I wasn't defending the correctness of my patch, I see why it isn't
good (although I fail see a point in having a ".desktop" file not
ending in ".desktop" as these functions allow) but I've been looking
into this and I don't really know how to do this without being
invasive. If the ".desktop" part is added some levels above, where
nautilus accepts the URL drop, the link ends up with "Name=" ending in
".desktop", because the "Name=" is assumed to be the same as the name
of the file being created.
Comment 8 Alexander Larsson 2004-10-05 09:07:44 EDT
*** Bug 127444 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Larsson 2004-10-12 06:34:00 EDT
Fixed in 2.8.1-2

Note You need to log in before you can comment on or make changes to this bug.