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

NEW
Unassigned

Status

()

Core
DOM: Apps
5 years ago
10 months ago

People

(Reporter: ianb, Unassigned)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(blocking-kilimanjaro:-)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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
(Reporter)

Updated

5 years ago
See Also: → bug 703714
Whiteboard: [mozappsapi]
(Reporter)

Updated

5 years ago
Duplicate of this bug: 703714

Updated

5 years ago
Blocks: 746465

Updated

5 years ago
Whiteboard: [mozappsapi]

Updated

5 years ago
Duplicate of this bug: 746592
Nominating for k9o, as this is a likely use case for app developers hosting their own app install buttons.
blocking-kilimanjaro: --- → ?
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.
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.

Comment 7

5 years ago
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.

Updated

5 years ago
blocking-kilimanjaro: ? → -

Updated

5 years ago
Duplicate of this bug: 755937
(Reporter)

Comment 9

5 years ago
(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.

Updated

5 years ago
No longer blocks: 746465
Component: DOM: Mozilla Extensions → DOM: Apps

Updated

5 years ago
Duplicate of this bug: 785393
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.
(Reporter)

Comment 14

5 years ago
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.
Comment hidden (spam)
tracking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.