745928 - navigator.mozApps.install(url) does not take relative URL

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Ian Bicking (:ianbicking)]

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 3

[Jason Smith [:jsmith]]

Nominating for k9o, as this is a likely use case for app developers hosting their own app install buttons.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Attachment: 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: [e-mail]]]

This API in general could benefit from an SR pass, I think... Or review from a DOM peer.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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]

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 9

[Ian Bicking (:ianbicking)]

(In reply to :Gavin Sharp (use [e-mail] 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: [e-mail]]]

(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: [e-mail]]]

I filed bug 765063 for that.

Comment 13

[David Teller [:Yoric] - still alive but not very active]

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 (:ianbicking)]

As a workaround in code you can do:

  navigator.mozApps.install(location.protocol + "//" + location.host + "/manifest.webapp");

Comment 15

[Chris Lord [:cwiiis]]

(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é]

(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]]

(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]

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]

[Tracking Requested - why for this release]:

Comment 20

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.