application:// URIs are malformed

Bug #784478 reported by Olivier Tilloy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Unity
Fix Released
Medium
Robert Carr
unity-2d
Fix Released
Undecided
Unassigned
unity-lens-applications
Fix Released
Medium
Robert Carr
unity (Ubuntu)
Fix Released
Undecided
Unassigned
unity-lens-applications (Ubuntu)
Fix Released
Undecided
Mikkel Kamstrup Erlandsen

Bug Description

For installed applications, the applications place daemon returns URIs of the form "application://filename.desktop", for example "application://gnome-sudoku.desktop".
According to the Nameprep RFC (http://www.rfc-editor.org/rfc/rfc3491.txt), host names should always be converted to lower case. The way those "application://" URIs are built, the desktop file name is the hostname. This is not a problem if the filename is already all lowercase (this is the case of most desktop files), but it becomes a problem with e.g. "SearchAndRescue.desktop".

This is a problem with the implementation of drag’n’drop from the dash to e.g. the desktop in unity-2d, because the underlying toolkit (Qt) strictly enforces the Nameprep RFC for URIs, and as a consequence "SearchAndRescue.desktop" is converted to "searchandrescue.desktop".

I can think of at least two ways to fix this issue in the daemon itself:

 1) For installed applications, pass around the actual "file:///usr/share/applications/filename.desktop" URI
 2) Or change the form of the "application://" URI so that the desktop file name is not the host name, e.g. "application://packagename/filename.desktop" like what is done with "unity-install://" URIs (this may be an issue though if package names are authorized to have upper case letters)

Solution 1 is probably simpler as ultimately client code will likely convert the "application://" URI back to the real "file://…" URI anyway.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Note: this already generated nasty issues in Unity-2d (see for example bug #723604) which so far have been worked around one way or another.

Revision history for this message
Olivier Tilloy (osomon) wrote :

See also http://doc.qt.nokia.com/qurl.html#FormattingOption-enum for details on Qt’s implementation of URI handling (note that drag’n’drop events in Qt manipulate QUrl objects, there is no clean workaround available there).

Changed in unity-place-applications (Ubuntu):
status: New → Confirmed
Changed in unity-place-applications:
status: New → Confirmed
Changed in unity-place-applications (Ubuntu):
assignee: nobody → Mikkel Kamstrup Erlandsen (kamstrup)
Changed in unity:
status: New → Invalid
Changed in unity:
status: Invalid → Confirmed
Changed in unity-2d:
status: New → Confirmed
Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

The silent agreement in the Unity lens interactions is that the URI column is very free form and mostly internal (wow, can we get more sloppy? ;-)). We've introduced another address mechanism for results which is, for now, called the "external uri" - or maybe justifiably a URL. This external URI *must* be correct and addressable from the outside (hence URL makes sense). So I think we can document our selves out of this problem?

Robert Carr committed a fix to the apps lens to support this:

revno: 227.1.1
    committer: Robert Carr <email address hidden>
    branch nick: unity-lens-applications
    timestamp: Fri 2011-09-09 11:20:33 -0400
    message:
      Use the get_path method of AppInfoManager to pass full URIs for desktop files to unity. Lets us drag and drop an application to the desktop fo example

Changed in unity:
milestone: none → 4.16.0
assignee: nobody → Robert Carr (robertcarr)
importance: Undecided → Medium
status: Confirmed → Fix Committed
Changed in unity-lens-applications:
assignee: nobody → Robert Carr (robertcarr)
importance: Undecided → Medium
milestone: none → 0.4.6
status: Confirmed → Fix Committed
Changed in unity:
status: Fix Committed → Fix Released
Changed in unity-lens-applications:
status: Fix Committed → Fix Released
affects: unity-place-applications (Ubuntu) → unity-lens-applications (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-lens-applications - 0.4.6-0ubuntu1

---------------
unity-lens-applications (0.4.6-0ubuntu1) oneiric; urgency=low

  * New upstream release.
    - [dash] Category filters is sorted according to their english names,
      even when another language is used (LP: #838023)
    - application:// URIs are malformed (LP: #784478)
    - Games Filter in Unity doesn't work (LP: #842240)
  * debian/control:
    - build-dep on latest libunity-dev
 -- Didier Roche <email address hidden> Thu, 15 Sep 2011 14:27:11 +0200

Changed in unity-lens-applications (Ubuntu):
status: Confirmed → Fix Released
Changed in unity-2d:
milestone: none → 4.12
Revision history for this message
Alberto Mardegan (mardy) wrote :

I think this has already been fixed in Unity 2D back in August (revno 645).

Changed in unity-2d:
status: Confirmed → Fix Released
Changed in unity (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.