We need to determine what is the correct behavior when we request a manifest against a given origin, and the location of the manifest does a redirect to a different origin containing the manifest. Right now, the behavior is that we always install off the origin of where we originally requesting the manifest. We aren't taking the redirect into account if say, yourhost.com/manifest.webapp does an immediate redirect to www.yourhost.com/manifest.webapp. An example of app as of today that does this is BarFight - see below. Steps with http://tubagames.net/barfight_manifest.php: 1. Install BarFight from http://tubagames.net/barfight_manifest.php 2. Launch BarFight 3. Select Play Now Results: Play Now fires up the default browser going to http://www.tubagames.net/barfight_manifest.php, as play now goes to the www.tubagames.net origin. Checking http://tubagames.net/barfight_mainfest.php - we see it does a HTTP 301 to redirect immediately to http://www.tubagames.net/barfight_manifest.php. When I check the %APPDATA% on windows after install, I notice that the origin that was installed was tubagames.net. Steps with http://www.tubagames.net/barfight_manifest.php: 1. Install BarFight from http://tubagames.net/barfight_manifest.php 2. Launch BarFight 3. Select Play Now Results: The next page in BarFight loads correctly within an app, as you remain on the same origin (www.tubagames.net). We need to figure out what is the correct behavior in this scenario with a redirect on the manifest.

It seems like this issue occurs when the manifest request receives a 301 response (possibly 302), regardless of whether redirect's origin is different from the initial origin. We should probably follow in-origin redirects, I'd understand hesitance about cross-origin redirects.

Related discussion at bug 732556 - but let's keep this bug to track the changes in navigator.mozApps.

I don't think there's a problem with the current implementation when it receives in-origin redirects. The original URL is held in manifestURL (which is arguably the right thing), but otherwise there's no difference between two in-origin manifest URLs. Only when the redirect is cross origin does it cause a serious problem.

(In reply to Ian Bicking (:ianb) from comment #3) > I don't think there's a problem with the current implementation when it > receives in-origin redirects. The original URL is held in manifestURL > (which is arguably the right thing), but otherwise there's no difference > between two in-origin manifest URLs. Only when the redirect is cross origin > does it cause a serious problem. What about something like: app install location - yourhost.com/manifest.webapp manifest.webapp launch_path is /start /start redirects /different When launching the app, does yourhost.com/different launch?

In reply to Jason Smith [:jsmith] from comment #4: I don't see the problem with those redirects. If http://yourhost.com/start redirected to http://www.yourhost.com/start then that'd be more problematic. Given our current expectations I think it would work, but you'd lose any special App features. That would be confusing, but a different confusion than what was described in comment #1.

Nominating for k9o - from the apps webRT perspective, this can be a bit of a pain to not have logic to handle redirects (I've seen two apps so far hit this issue, which results in always firing the browser up, given that the starting URL vs. origin URL are different). Also affects setting up pre-auth during an in-app purchase in the web runtime for desktop (see bug 755077).

This could also be reasonably handled with a validation on the Marketplace. It wouldn't handle self-installs. Also the validation wouldn't really be making up for this bug, as it's reasonable to reject redirects in the marketplace anyway.

Please re-test with in payment test app in marketplace and make sure its still occurring.

Re-tested. Actually, bug 755077 and the issue with regards to in-app purchases is not relevant to the underlying problem here. This bug talks about when you are installing an app that has a manifest do a redirect immediately. So this isn't a k9o blocker at all.

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