Wrong relative URLs in generated manifest.json

[bschwarzent]

I prefer placing all resources generated by RFG in a seperate folder, e.g. http://www.example.com/myapp/resources/favicons. To achieve that, I use the "I cannot or I do not want to place favicon files at the root of my web site. Instead I will place them here" option and specify the relative path "resources/favicons".

This generates the following manifest.json:

{
    "name": "MyApp",
    "icons": [
        {
            "src": "resources\/favicons\/android-chrome-192x192.png",
            "sizes": "192x192",
            "type": "image\/png"
        },
        {
            "src": "resources\/favicons\/android-chrome-512x512.png",
            "sizes": "512x512",
            "type": "image\/png"
        }
    ],
    "theme_color": "#ffffff",
    "display": "standalone"
}

And the following include for http://www.example.com/myapp/index.html:

...
<link rel="manifest" href="resources/icons/manifest.json">
...

This results in 404 errors because Chrome tries to access http://www.example.com/myapp/**resources/favicons/resources/favicons/**android-chrome-192x192.png (the part resources/icons appears twice in the URL).

I think, the manifest.json should not contain the specified relative prefix, because the manifest file is already at that location. The specification (https://w3c.github.io/manifest/#src-member) states, that if the src attribute contains a relative URL, it is interpreted relative to the manifest's URL.

[phbernard]

Absolutely. Thank you for reporting. I should fix this next week.

[ve3]

Not just manifest.json but also wrong relative URL in browserconfig.xml too.

[bschwarzent]

Not just manifest.json but also wrong relative URL in browserconfig.xml too.

@ve3 Are you sure about this? I just had the opportunity to test my application with a Windows 10 tablet. When the browserconfig.xml just references the image filenames (in the same subfolder), they cannot be found when pinning the page to a tile. The paths generated by RFG (including the subfolders) however are working as expected.

Thank you for reporting. I should fix this next week.

@phbernard Are there any updates on the manifest.json related issue (#270)? So far, we have to manually correct the files generated by RFG.

[phbernard]

First, I'm very sorry for this late feedback. This is an important issue and it should have been fixed long ago.

I tested the different platforms. To do this, I created the following site:

/main_dir
  /index.html => references files in /main_dir/my_images
  /my_images
      manifest.json, browserconfig.xml and yandex-manifest.json use path "my_image/an_icon.png"
      "blue" icons (ie. the touch icons, favicon.ico, etc... are blue)
      /my_images
        "red" icons

So whatever the browser behavior (use HTML page or manifest as the reference), there is an icon to load. The goal is to note the color of the displayed icon.

The results:

• Web App Manifest (aka manifest.json), tested with Android Chrome: relative to the manifest (not the HTML page), as reported by @bschwarzent
• Edge / IE manifest (aka browserconfig.xml): relative to the HTML page (not the manifest), as reported by @bschwarzent
• Yandex Browser manifest: relative to the HTML page (not the manifest)
• Firefox OS App Manifest: not tested, but not really an issue since this manifest is now obsolete.

In the end, only Android Chrome needs to be fixed.

The next steps:

• Fix Android
• Add a global test in the API test suite to make sure RFG is consistent with the results above.
• Fix the favicon checker. I'm confident it is impacted by the issue, too.

[phbernard]

The fix is implemented and unit-tested.

However, it raises another issue. Some API clients cannot regular paths. For example, the Ruby on Rails generator needs to generate code such as <%= asset_path "my_icon.png %>. Because RFG has nothing to do with this kind of templating syntax, the RoR generator provides a dummy path to RFG. Later, it search/replace the path in the generated files (manifests...) in order to use the particular RoR code.

If the fix for #270 is deployed as is, the RoR client (and maybe others) is suddenly broken. Because it expects to find a placeholder everywhere but don't anymore.

A long-term solution would be for RFG to provide a templating system support. For example, RoR could pass <%= asset_path "$FILEPATH$" %> and RFG would return something like <%= asset_path "icon.png" %>. But #270 needs a short-term solution.

What I'm thinking of right now is an extra parameter which means "I want the path to appear everywhere no matter what". Its default value is true, so existing clients are not broken. RFG classic site sets it to false in the background so regular users (who want vanilla HTML or Gulp or...) get a valid Web App manifest for Android Chrome without paying attention.

[phbernard]

Deployed a minute ago.