← Back to team overview

touch-packages team mailing list archive

[Bug 784478] Re: application:// URIs are malformed

 

** Changed in: unity (Ubuntu)
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity in Ubuntu.
https://bugs.launchpad.net/bugs/784478

Title:
  application:// URIs are malformed

Status in Unity:
  Fix Released
Status in Unity 2D:
  Fix Released
Status in Unity Applications Lens:
  Fix Released
Status in “unity” package in Ubuntu:
  Fix Released
Status in “unity-lens-applications” package in Ubuntu:
  Fix Released

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/784478/+subscriptions