application:// URIs are malformed
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:
According to the Nameprep RFC (http://
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 "SearchAndRescu
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:/
2) Or change the form of the "application://" URI so that the desktop file name is not the host name, e.g. "application:
Solution 1 is probably simpler as ultimately client code will likely convert the "application://" URI back to the real "file://…" URI anyway.
Related branches
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 |
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) |
Changed in unity-2d: | |
milestone: | none → 4.12 |
Changed in unity (Ubuntu): | |
status: | New → Fix Released |
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.