Last Comment Bug 745928 - navigator.mozApps.install(url) does not take relative URL
: navigator.mozApps.install(url) does not take relative URL
Status: NEW
:
Product: Core
Classification: Components
Component: DOM: Apps (show other bugs)
: unspecified
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 703714 746592 785393 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-16 13:39 PDT by Ian Bicking (:ianb)
Modified: 2014-11-17 00:47 PST (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
potential patch (4.22 KB, patch)
2012-05-10 13:41 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
no flags Details | Diff | Review

Description Ian Bicking (:ianb) 2012-04-16 13:39:53 PDT
If you try to install an app like:

  navigator.mozApps.install("/manifest.webapp");

it causes a MANIFEST_PARSE_ERROR response, which is in turn due to NS_ERROR_UNKNOWN_HOST in the install method in Webapps.js.  URLs should be resolved relative to the calling site.

The install button on this page demonstrates the problem (the button should work):

  http://app1.ianbicking.org/relativeurl.html
Comment 1 Ian Bicking (:ianb) 2012-04-16 13:41:21 PDT
*** Bug 703714 has been marked as a duplicate of this bug. ***
Comment 2 Jason Smith [:jsmith] 2012-04-18 08:34:31 PDT
*** Bug 746592 has been marked as a duplicate of this bug. ***
Comment 3 Jason Smith [:jsmith] 2012-05-09 12:39:59 PDT
Nominating for k9o, as this is a likely use case for app developers hosting their own app install buttons.
Comment 4 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-10 13:41:37 PDT
Created attachment 622891 [details] [diff] [review]
potential patch

This code seems to have a few issues:
- creation of new URI objects unnecessarily (equivalent objects are retrievable from the window/document)
- use of URI specs and prePaths all over the place to determine "origin"
- the "origin" is based on the document location after the XHR has completed - can't that be different than the actual document that triggered the installation?
- failure to resolve the passed-in argument as a relative URI

I don't have time to investigate all of these issues (or write tests for all of these changes), but I think all of these need to be fixed. This patch fixes some of them, but hasn't been tested and may not be complete.
Comment 5 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-10 13:42:49 PDT
This API in general could benefit from an SR pass, I think... Or review from a DOM peer.
Comment 6 Boris Zbarsky [:bz] 2012-05-10 13:59:23 PDT
The "right" way to get an origin from a document is probably document.nodePrincipal.origin for what it's worth.  Or if we need the HTML5 origin (it's subtly different in system and nullprincipal cases) we should just expose a getter for it.
Comment 7 Ken Walker 2012-05-15 08:53:16 PDT
Also found this while trying out our Orion App on the Firefox Nightlies.  Previous version of my javascript worked on all browsers.  I think this would be great to fix then I can also share the same JavaScript file on multiple hosts referencing a relative URL.
Comment 8 Jason Smith [:jsmith] 2012-05-16 15:33:29 PDT
*** Bug 755937 has been marked as a duplicate of this bug. ***
Comment 9 Ian Bicking (:ianb) 2012-06-12 09:11:56 PDT
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #4)
> - the "origin" is based on the document location after the XHR has completed
> - can't that be different than the actual document that triggered the
> installation?

This problem is tracked in Bug 752060
Comment 10 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-14 15:23:13 PDT
(In reply to Ian Bicking (:ianb) from comment #9)
> This problem is tracked in Bug 752060

I don't think that's the same problem. The scenario I'm worried about isn't a manifest URL that redirects, it's a website triggering an installation, then navigating itself to trusted.com, and having trusted.com recorded as the app's origin.
Comment 11 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-14 15:45:32 PDT
I filed bug 765063 for that.
Comment 12 Jason Smith [:jsmith] 2012-08-24 12:13:50 PDT
*** Bug 785393 has been marked as a duplicate of this bug. ***
Comment 13 David Rajchenbach-Teller [:Yoric] (please use "needinfo") 2013-01-21 10:13:36 PST
This is worrying me for the whole bunch of hackatons we have schedule this week. I realize it's too late, but some devs are going to bring back some homework, and they'll really need this feature for testing purposes.
Comment 14 Ian Bicking (:ianb) 2013-01-23 12:07:50 PST
As a workaround in code you can do:

  navigator.mozApps.install(location.protocol + "//" + location.host + "/manifest.webapp");
Comment 15 Chris Lord [:cwiiis] 2013-05-03 17:28:09 PDT
(In reply to Ian Bicking (:ianb) from comment #14)
> As a workaround in code you can do:
> 
>   navigator.mozApps.install(location.protocol + "//" + location.host +
> "/manifest.webapp");

This isn't really a work-around, as your manifest and appcache need to have absolute paths, making the whole thing a bit awkward.

It'd be good to have a decent path from dev-on-local-machine -> deploy-from-subdirectory that doesn't involve a preprocessor.
Comment 16 [:fabrice] Fabrice Desré 2013-05-03 17:29:53 PDT
(In reply to Chris Lord [:cwiiis] from comment #15)
> (In reply to Ian Bicking (:ianb) from comment #14)
> > As a workaround in code you can do:
> > 
> >   navigator.mozApps.install(location.protocol + "//" + location.host +
> > "/manifest.webapp");
> 
> This isn't really a work-around, as your manifest and appcache need to have
> absolute paths, making the whole thing a bit awkward.

What do you mean? In your manifest, you simply use something like:
"launch_path": "/index.html" , no need for the full url.
Comment 17 Chris Lord [:cwiiis] 2013-05-03 17:34:03 PDT
(In reply to Fabrice Desré [:fabrice] from comment #16)
> (In reply to Chris Lord [:cwiiis] from comment #15)
> > (In reply to Ian Bicking (:ianb) from comment #14)
> > > As a workaround in code you can do:
> > > 
> > >   navigator.mozApps.install(location.protocol + "//" + location.host +
> > > "/manifest.webapp");
> > 
> > This isn't really a work-around, as your manifest and appcache need to have
> > absolute paths, making the whole thing a bit awkward.
> 
> What do you mean? In your manifest, you simply use something like:
> "launch_path": "/index.html" , no need for the full url.

You can't say "launch_path": "./index.html", or equivalent, unless I've missed something (which is quite likely :))

Where as working locally, whatever directory the manifest is in acts as the root.

Real-world example, I have an app at http://chrislord.net/demos/timer/ and all the paths have to be prefixed with /demos/timer/, where as locally, they don't (and in fact, this breaks running it locally).
Comment 18 Jonas Sicking (:sicking) 2013-05-12 02:26:02 PDT
If

  "launch_path": "./index.html"

isn't working, please file a separate bug on that. That's not related to this bug as this bug is about the mozApps.install() function specifically.

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