New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong relative URLs in generated manifest.json #270

Closed
bschwarzent opened this Issue Aug 15, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@bschwarzent

bschwarzent commented Aug 15, 2016

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

This comment has been minimized.

Contributor

phbernard commented Aug 16, 2016

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

@phbernard phbernard added the bug label Aug 16, 2016

@ve3

This comment has been minimized.

ve3 commented Aug 17, 2016

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

@bschwarzent

This comment has been minimized.

bschwarzent commented Jan 25, 2017

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.

bschwarzent added a commit to BSI-Business-Systems-Integration-AG/org.eclipse.scout.docs that referenced this issue Jan 25, 2017

Fix icon paths in manifest.json
"manifest.json" files generated by realfavicongenerator.net contain
wrong relative paths:

RealFaviconGenerator/realfavicongenerator#270

This prevents 404 errors in log when browsers of the Chrome family
access the application.

bschwarzent added a commit to BSI-Business-Systems-Integration-AG/org.eclipse.scout.docs that referenced this issue Jan 26, 2017

Fix icon paths in manifest.json
"manifest.json" files generated by realfavicongenerator.net contain
wrong relative paths:

RealFaviconGenerator/realfavicongenerator#270

This prevents 404 errors in log when browsers of the Chrome family
access the application.
@phbernard

This comment has been minimized.

Contributor

phbernard commented Feb 21, 2017

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

This comment has been minimized.

Contributor

phbernard commented Feb 24, 2017

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

This comment has been minimized.

Contributor

phbernard commented Feb 1, 2018

Deployed a minute ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment