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
:
: [:fabrice] Fabrice Desré
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: 2016-08-17 10:07 PDT (History)
25 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 | Splinter 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] (still a bit busy) 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 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) No longer reading bugmail consistently 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.
Comment 19 waxmigs2902 2016-06-20 03:41:55 PDT Comment hidden (spam)

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