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

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

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.

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

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.

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.

(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

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

I filed bug 765063 for that.

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.

As a workaround in code you can do: navigator.mozApps.install(location.protocol + "//" + location.host + "/manifest.webapp");

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

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

(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).

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.

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