Error while trying to use the following icon from the manifest

«Error while trying to use the following icon from the Manifest» in browser console #3260

Seeing following error in the Javascript console of Chromium (Version 81.0.4044.138 (Official Build) (64-bit))

Error while trying to use the following icon from the Manifest: https://wild-water.nl/dokuwiki/_media/wiki/dokuwiki.svg (Download error or resource isn’t a valid image)

when looking in the network tab I can see that the image is presented as a download:

Firefox 76 apparently does not request the manifest nor the image

It seems that SVG is not a known file extension in the DW mime config

The text was updated successfully, but these errors were encountered:

This looks like that, if the mime type is unknown, then the media manager is strict in handling it. Even while we offer it our self i.e. it is already in the media manager.

I expect this file is offered via the mediamanager because it allows administrators easy uploading other icons. (but I guess that uploading a svg is default not allowed, because it is not permitted in the mime config.) @micgro42 did you try when developing this feature, to replace the image?

According to #1045 we would not offer default svg support, due to lack of sanitizing options in DokuWiki. Svg-files could contain javascript.

the easy/safe fix is to replace the svg with a png then, such as lib/tpl/dokuwiki/images/logo.png

I guess all locations that are not via /_media/ url could work with svg. e.g. in the https://github.com/splitbrain/dokuwiki/tree/master/lib/images folder. Users can override all entries of the manifest and use any location, see https://www.dokuwiki.org/devel:manifest. But default it search the images in de media directory.

png looks as reasonable alternative indeed, but is of course no vector format.

Mh, I looked into it a bit just now and I can reproduce it with a current Chrome version and both current code and with a git checkout back from when this code was created in 2018. Maybe the Chrome version from back then didn’t complain?

Replacing it with a .png would remove much of the scaling efficiency of being able to use the same file for different sizes.

Moving the fallback to lib/images sounds a viable solution. OTOH, we might lose some caching-control that way? But I’m not sure if that is really important for a last-stage fallback image.

I haven’t looked into it, but couldn’t we add svg to mime.conf with a leading ! ? That seems like it would sufficiently address the security concerns related to included javascript. However, I feel like I’m missing some angle here, because otherwise, I would have expected to have been done already.

I looked only very briefly into the options mentioned above, so some assumptions might be wrong. I’d be happy to fix this, but don’t have much time right now. More input welcome 🙂

As written here, there is probably an easy fix for disallowing the execution of JavaScript in SVG uploads. If this is our only concern, we could then enable them by default and thus fix this issue.

#1045 is solved, so this issue is solved as well?

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Created app has wrong favicon «sizes» value in the manifest file, which results in console error. #3284

Is this a bug report?

Can you also reproduce the problem with npm 4.x?

Did not try. Doesn’t seem to be related to that.

Which terms did you search for in User Guide?

Environment

1. node -v : v8.7.0
2. npm -v : 5.5.1
3. yarn —version (if you use Yarn):
4. npm ls react-scripts (if you haven’t ejected):

1. Operating system: macOS 10.13
2. Browser and version (if relevant): Chrome 61

Steps to Reproduce

1. Go to the created app’s manifest file in public folder.
2. The icons array has wrongly mentioned the favicon.ico size as 192×192 instead of 16×16 size of the included favicon file.
3. Run the app. Go to Dev Tools’ Application section. Open Manifest.
4. Click Add to homescreen. This results in console error:
   Error while trying to use the following icon from the Manifest: http://localhost:3000/favicon.ico (Resource size is not correct — typo in the Manifest?) Site cannot be installed: icon downloaded from the manifest was empty or corrupted

Expected Behavior

Should have searched for 144×144 image, where it would fail if we fix the size now.

Actual Behavior

Reproducible Demo

The text was updated successfully, but these errors were encountered:

The included favicon.ico file I found was 64×64 instead of 16×16, so I used that value in #3287.

@ryansully yes, you are right, it’s 64×64. My IDE wrongly showed it to be 16×16. My bad.

@ryansully have you signed the CLA here https://code.facebook.com/cla to get your PR approved?

That’s odd, I’ve signed it and contributed before, should I sign again?

Actually, #3287 has the CLA Signed label:
#3287 (comment)

PR should be ready to go.

I see this warning but icon size is 64×64 how remove this warning?

I see this warning but icon size is 64×64 how remove this warning?

@camux, in your app, go to public folder, right click on favicon.ico file and select Properties , then Details tab and check Dimensions value. Then open manifest.json file (which is in the same public folder) in a code editor and under «icons» , change «sizes» value to whatever dimensions the favicon.ico file had. That should fix the console error.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Chrome Extension Tutorial: Migrating to Manifest V3 from V2

See the detailed steps you need to take to migrate your extension from Manifest V2 to Manifest V3

Shahed Nasser

Read more posts by this author.

Shahed Nasser

In November 2020, Chrome introduced Manifest V3. For a long time, extensions have been using Manifest V2, so this is a big transition, especially with the new features in V3.

In this tutorial, we will see the steps needed to go from Manifest V2 to V3. I will be using the extension from a previous tutorial (Chrome Extension Tutorial — Replace Images in Any Website with Pikachu) with a new branch. If you’re not familiar with it, we built a chrome extension that replaces all images in a website with random Pikachu images that we retrieved through an API. You can checkout the repository here.

Why Migrate to Manifest V3?

As Chrome’s Documentation puts it:

Extensions using MV3 will enjoy enhancements in security, privacy, and performance; they can also use more contemporary Open Web technologies adopted in MV3, such as service workers and promises.

Changes to manifest.json

Changing the Version

The first obvious step is that you need to change the version of your manifest. In your manifest.json file, change it as follows:

If you try to add your extension to chrome now (or reload it if it’s already there), you’ll see different errors regarding changes that you still need to make to your manifest.json file.

Host Permissions

In Manifest V2, there were two ways to get permission for your apis or any host you will need to make requests to from the extension: either in the permissions array or in the optional_permissions array.

In Manifest V3, all host permissions are now separate in a new array with the key host_permissions . Host permissions should not be added with other permissions anymore.

Going back to our example, this was our permissions array:

Now, it should change to this:

In our case, we just needed to change the key from permissions to host_permissions . However, if your extension has other values in permissions , then you should keep them in it and just move your host permissions to host_permissions .

Background Scripts

Manifest V3 replaces background scripts with service workers. We’ll talk about how to make the transition in a bit, but first the transition need to be made in manifest.json.

The background object currently looks like this in our extension:

What we need to do is change the scripts array key to service_worker , and now you should have one service worker instead of multiple background pages or scripts. So, it should look like this:

Note that we don’t need to add persistent anymore. Also, if you have page inside background , that should be changed to a service worker as well.

Actions

Actions used to be browser_action and page_action , but now they’re unified into action in Manifest V3. This is due to the fact that over time they became similar, and separating them became unnecessary.

We don’t use it in our extension, but this is an example of how it should be like:

There are also changes in the code needed, we will get to that later.

Content Security Policy

Again, this is not used in our extension, but we still need to go over it. If your extension had a Content Security Policy (CSP), then you need to change it from a string (the way it was in Manifest V2) to an object (the way it is in Manifest v3).

An example of how it should be like in Manifest V3:

Web-Accessible Resources

The last change you need to make in the manifest.json is changing the web_accessible_resources array to an object detailing all the resources. Here’s an example of how it should be like in V3:

The object also will support in future releases the keys matches (array of URLs), extension_ids (array of keys), and use_dynamic_url (boolean).

Adding the Extension

Now if you go to chrome://extensions in your browser and add your extension or reload it, it will change to a Manifest V3 extension successfully. However, in our case it will show you an error button in the extension box, and when you click it, it will say «service worker registration failed.» That’s because there’s still more work to do in our code.

From Background Scripts to Service Workers

First, what are service workers and what’s the difference between them and background scripts?

Background scripts are essential in almost all extensions. They allow you to do some actions or execute code without the need for the user to open a certain page or do something. This can be used to send notifications, manage communication with content scripts, and much more. Background scripts are generally always running in the background.

Service workers are executed when needed. Unlike background scripts, they are not always running in the background. At the top level, service workers should register listeners to some events that would allow them later on to be executed.

The shift from background scripts to service workers depends on your code in extension. Some extensions might need a lot of reworking, while others not so much.

The first step you need to do is move your file that was previously a background script or page to the root of the extension. This is actually why in our extension we received the error stating that the registration of the service worker failed. Our background script’s path was js/assets/background.js relative to the root of our extension.

If your case is similar, move your background script to the root of your extension, then change the value of service_worker in your manifest to reflect the change:

If you reload the extension, the service worker should register successfully.

Now, let’s look at the code. In our extension, our background script looked as follows:

Basically our background script listened to a message using chrome.runtime.onMessage.addListener , and if the message was asking for an image, it would send a request to the API, and then return the data to our content script.

Our background script actually does not need any additional change. The reason behind that is that the background script that is now a service worker just registers an event listener and executes code when that event occurs, which is exactly what a service worker should be doing.

However, not all extensions are like that as there are different use cases. Here’s what you need to check for and amend in your background script:

Global Variables

As stated above, background scripts previously were always running in the back. Meaning if I had the following code:

Each time the background script received a message, the count would increment. So, at first it would be 0, then 1, then 2, and so on.

In service workers, this will not work anymore. Service workers will run only when they need to, and terminate when they’ve finished their job. So, the above code would always print in the console «1».

Changing this depends on your use case. In the above example, the count could be passed back and forth between your background script and content script to get the result needed. An even better way would be to use Chrome’s Storage API.

Using that, the code will look something like this:

Again, it depends on your code, so make sure to make the changes based on what’s best for you.

Timers and Alarms

Timers were used in background scripts with no problems as they are always running in the background. However, this will not work in service workers. You should replace all timers with the Alarms API.

Accessing the DOM

Service workers do not have access to windows or the DOM. If your extension needs that, you can use libraries like jsdom or use chrome.windows.create and chrome.tabs.create. It depends on your usage and what fits your needs.

This is also needed if your background scripts record audio or video, as that is not possible in service workers.

Creating Canvas

If your background script previously created canvas, you can still do that with the OffscreenCanvas API. All you have to do is replace document with OffscreenCanvas .

For example, if this was your code:

Then you should change it to:

Checking Your Extension

After you are done with making the changes need to change your background script to a service worker, reload your extension in the browser to see if it is working properly.

In our case, there was no change needed in background.js other than moving it to the root. So, if you reload the extension and go to a page, you will find that images have been replaced with Pikachu images successfully.

Actions API

As mentioned before, browser_action and page_action are now merged into action . The same should be applied in your code. If you are using browserAction or pageAction like below:

It should be changed to use the new Actions API as follows:

So, make sure to replace all browserAction and pageAction usages with action .

executeScript

If your code executed arbitrary strings using executeScript’s code property, you have two ways to change it. Also, instead of using chrome.tabs.executeScript , you need to replace tabs with scripting so that it will be chrome.scripting.executeScript .

Moving the Code To a New File

You need to move the value of code to a new file and use executeScript’s file property.

For example, if your code had something like this:

You should move the value of code , which here is alert(«Hello, World!») to a new file (let’s call it hello-world.js ):

Then change your previous code to the following:

Put the Code in a Function

If your code can be put in a function instead, like the example code, then just move it to a function in the same file, then assign the function property of executeScripts to the function you created:

Additional Work

There is a list of other changes and things you need to look for in your code:

1. If your extension uses the webRequest API, which is typically used in an enterprise setting where the extension is forced-installed, you need to replace it with the declarativeNetRequest API.
2. If you are making any CORS requests in your content scripts, make sure to move them to your service worker.
3. Remotely-hosted code is not allowed anymore. You need to find another way to execute your remotely hosted code. Chrome’s documentation suggests using either Configuration-driven features and logic which means you retrieve a JSON file with the configuration needed and you cache it locally for later use, or Externalize logic with a remote service which means you have to move your application logic from your extension to a remote web service.
4. Check the API Reference for any deprecated APIs or methods you might be using.

If you like my content and want to support me, please share this article on your social media or Buy me a coffee!

Subscribe to Newsletter

Subscribe to the newsletter to be notified of new tutorials and articles!

Thank you!

You have successfully joined our subscriber list.

Источник

Answer by Alan Good

«Error while trying to use the following icon from the Manifest: http://localhost:3000/favicon.ico (Resource size is not correct — typo in the Manifest?)»,

I encountered the following problems when using foreach:

,The issue was with the icon I was no longer using still in manifest.json. Once that information was removed, I did not see any error anymore

Try this:

"sizes": "16x16" 

Answer by Alessandro Collins

Click Add to homescreen. This results in console error:
Error while trying to use the following icon from the Manifest: http://localhost:3000/favicon.ico (Resource size is not correct — typo in the Manifest?) Site cannot be installed: icon downloaded from the manifest was empty or corrupted,The icons array has wrongly mentioned the favicon.ico size as 192×192 instead of 16×16 size of the included favicon file.,@ryansully have you signed the CLA here https://code.facebook.com/cla to get your PR approved?

Fixes facebook#3284.

Answer by Kairi Blankenship

However, on chrome mobile the icon is updated(confirmed using add to homescreen),Error-«Error while trying to use the following icon from the Manifest:»
When I modifed the manifest.json with following change , it worked for me .,GET http://localhost/android-icon-144×144.png 404 (Not Found)
(index):1 Error while trying to use the following icon from the Manifest: http://localhost/android-icon-144×144.png (Download error or resource isn’t a valid image)

However, on chrome mobile the icon is updated(confirmed using add to homescreen)

{
  "name": "Duckr",
  "short_name": "Duckr",
  "theme_color": "#2196f3",
  "background_color": "#2196f3",
  "display": "standalone",
  "orientation": "portrait",
  "Scope": "/",
  "start_url": "/",
  "icons": [
    {
      "src": "icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "icons/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "icons/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "splash_pages": null
}

Answer by Thiago Portillo

I am getting this error (see below) in a small test project that has no images.
,They should be able to enter ‘none’ into the field. It will revert to the default.,Here is the zipped file — the project icon property shows;
nsb/images/LauncherIcon57.png

Answer by Lainey Drake

Error while trying to use the following icon from the manifest: http://localhost:8080/img/icons/android -chrome-192×192.png (Download error or resource isn’t a valid image),The main reason for this error is that the android-chrome-192×192.png image in the icons folder under img under public is deleted by mistake
my solution: re create the same folder and file (if you find a picture, you won’t report an error!)
,
The URL is timestamped to avoid caching problems when requesting the current path again

Answer by Blaine Kaur

Error while trying to use the following icon from the Manifest: https://domain.com/forum/manifest.webmanifest (Download error or resource isn’t a valid image),Hi, I have installed a new Discourse using the discourse_docker with a specific configuration (using subfolder). Everything is working fine except I have an error in my webmanifest:,Here’s my manifest content:

Answer by Avi Haynes

But after packaging you will still have the exception:“Error while reading manifest.json: Failed to find icon”… Why??,I have also seen this when you create a connector and download the Manifest. So what is the problem. Well since the 0.4 Microsoft teams api and 1.0 api a lot has changed.,Last week we did organise a event called Office365Bootcamp. With 2 other i guided the Microsoft Teams Track. One question I heard a couple of times was. He Microsoft Teams gives a exception when i try to sideload the package. “Error while reading manifest.json: Failed to find icon” Icon name.. What is the issue here and why are we unable to load the manifest

Answer by Alden Briggs

And this is another paragraph..,This is some example content.,

Members

Current visitors

New profile posts

Search profile posts

Answer by Elianna Delacruz

The lang option is part of the web app manifest specification and thus is required to be a valid language tag.,gatsby-plugin-manifest,The web app manifest (part of the PWA specification) enabled by this plugin allows users to add your site to their home screen on most mobile browsers —
see here. The manifest provides configuration and icons to the phone.

npm install gatsby-plugin-manifest

{
  "name": "Duckr",
  "short_name": "Duckr",
  "theme_color": "#2196f3",
  "background_color": "#2196f3",
  "display": "standalone",
  "orientation": "portrait",
  "Scope": "/",
  "start_url": "/",
  "icons": [
    {
      "src": "icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "icons/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "icons/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "splash_pages": null
}

Ответы

"icons": [
{
  "src": "favicon.ico",
  "sizes": "64x64 32x32 24x24 16x16",
  "type": "image/x-icon"
}

 {
      "src": "icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },

"icons": [
    {
      "src": "/favicon/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    }
]

<link rel="icons" type="image/png" sizes="144x144"  href="/favicon/android-icon-144x144.png">

<link rel="icon" type="image/png" sizes="144x144"  href="/favicon/android-icon-144x144.png">

Thanks so much for this great module! It’s a huge help out of the box.
I’ve got it successfully running on a live D7 project and trying to do the same on a D8 project that I’m currently developing.
Since the D8 version is different in some ways, I hope, you can help me to solve some image-related mysteries.

When I upload an image on /admin/config/pwa/settings, I see this error in the browser console:
Error while trying to use the following icon from the Manifest: http://localhost/sites/default/files/pwa/android-chrome-512x512.pngcopy2.png (Download error or resource isn't a valid image)

Here are a couple situations:
#1: The module has appended copy2.png to the original file name. It appears to be the same issue as mentioned in comment #31 of Fully working D8 version based on D7 Serviceworker. But #2 is the actual problem that breaks stuff.

#2: The full URL should be http://localhost/mysite/web/sites/default/files/pwa/android-chrome-512x512.pngcopy2.png
So, mysite/web/ is missing. The generated preview of the uploaded image on this config page is missing as well, due to the broken URL. The preview image URL in the HTML source code looks like that: <img src="/sites/default/files/pwa/android-chrome-512x512.png" width="200">.
I haven’t looked at the module code but since the image URL is starting with /sites, my guess is that some sort of $base_url is missing there.

#3: The image upload field on config page /admin/config/pwa/settings expects 512x512px images.
On PWA Extra’s config page /admin/config/pwa/pwa_extras it provides this uploaded image in 192x192px, though:

192×192″ href=»/sites/default/files/pwa/android-chrome-512×512.pngcopy.png»>.
Would it make sense to either adopt the 512×512 to 192x192px or to provide a separate image upload for this 192x192px touch icon?
Is there a hook function, like in D7, for those images that I could use instead?

I’m on Drupal 8.7.9, with PHP 7.3 on the latest MAMP 5.5.

Please, let me know if I can provide more specific info to help solve the issues.

Thanks again for your valuable work!