Skip to content
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

Warning in Chrome: Declaring an icon with purpose: "any maskable" is discouraged. It is likely to look incorrect on some platforms due to too much or too little padding. #679

Closed
frederikhors opened this issue Sep 18, 2021 · 8 comments
Labels
bug Something isn't working released

Comments

@frederikhors
Copy link

Describe the bug
I'm having this warning in Chrome 93 (Win 10).

Screenshots
image

@frederikhors frederikhors added bug Something isn't working needs verification Bug needs to be verified with reproduction labels Sep 18, 2021
@atjn
Copy link
Collaborator

atjn commented Sep 26, 2021

I just looked into this, and the conclusion is pretty much what the warning says:

  • maskable icons are supposed to have a certain amount of padding around the central icon, allowing the OS to cut the image to a custom shape without cutting away anything important.
  • any icons on the other hand, are designed to be shown as-is, so they should have as little padding as possible.

pwa-asset-generator is currently generating a single icon for both purposes. The image has a lot of padding, making the icon smaller than it needs to be for any images, but if you put the image into something like maskable.app, you will see that the padding is not enough for maskable images, and some of the icon will often be cut away.

We should solve this by generating separate icon files for the two different purposes.

@atjn atjn removed the needs verification Bug needs to be verified with reproduction label Sep 27, 2021
@onderceylan
Copy link
Collaborator

Hi @frederikhors, thanks for reporting this issue. It's not recommended to use both maskable and any purposes together anymore. With the upcoming fix, when maskable option is provided, PAG will only be adding maskable as a purpose.

@frederikhors
Copy link
Author

I'm using PAG with the default options (I love convention over configuration).

Will it still be like this?

@onderceylan
Copy link
Collaborator

Maskable will stay as the default option, but the purpose output will be 'maskable' instead of 'maskable any'.

onderceylan added a commit that referenced this issue Oct 7, 2021
It's not recommended to use the maskable and any purposes together anymore. This setting also raises
issues with the new lighthouse audit. With this fix, when maskable is provided as an option to the
library, it will be only setting maskable as a purpose in the manifest.

BREAKING CHANGE: Instead of setting 'maskable any' as a purpose, the library will be setting
'maskable' value only when provided the maskable option.

fix #679
onderceylan added a commit that referenced this issue Oct 7, 2021
As both maskable and non-maskable icons can be built and defined for the same app, there should be a
distinction on the icon file name depending on maskable option usage.

BREAKING CHANGE: The file name template of the manifest icons is updated.

fix #679
onderceylan added a commit that referenced this issue Oct 7, 2021
It's not recommended to use the maskable and any purposes together anymore. This setting also raises
issues with the new lighthouse audit. With this fix, when maskable is provided as an option to the
library, it will be only setting maskable as a purpose in the manifest.

BREAKING CHANGE: Instead of setting 'maskable any' as a purpose, the library will be setting
'maskable' value only when provided the maskable option.

fix #679
onderceylan added a commit that referenced this issue Oct 7, 2021
As both maskable and non-maskable icons can be built and defined for the same app, there should be a
distinction on the icon file name depending on maskable option usage.

BREAKING CHANGE: The file name template of the manifest icons is updated.

fix #679
onderceylan added a commit that referenced this issue Oct 7, 2021
As both maskable and non-maskable icons can be built and defined for the same app, there should be a
distinction on the icon file name depending on maskable option usage.

BREAKING CHANGE: The file name template of the manifest icons is updated.

fix #679
onderceylan pushed a commit that referenced this issue Oct 7, 2021
# [5.0.0](v4.3.9...v5.0.0) (2021-10-07)

### Bug Fixes

* **main:** prevent unnecessary newlines on index HTML file ([a40d016](a40d016)), closes [#434](#434)
* **meta:** fix wrong file types of icons' html ([a6d2c58](a6d2c58)), closes [#495](#495)

### Features

* **file:** add maskable keyword to the manifest icons' file name ([47a09c6](47a09c6)), closes [#679](#679)
* **main:** use either 'maskable' or 'any' as a purpose ([4bdce80](4bdce80)), closes [#679](#679)

### BREAKING CHANGES

* **file:** The file name template of the manifest icons is updated.
* **main:** The newlines created when re-saving meta tag changes on the same index HTML file
will be removed. The prettier step to re-format after library execution is now optional and nice to
have.
* **main:** Instead of setting 'maskable any' as a purpose, the library will be setting
'maskable' value only when provided the maskable option.
@onderceylan
Copy link
Collaborator

🎉 This issue has been resolved in version 5.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@Adnan-Bacic
Copy link

Adnan-Bacic commented Oct 20, 2021

I just used this library for the first time today and i now have errors in chrome BECAUSE "any" is not present in the "purpose":

"purpose": "maskable"

image

if i manually add "any" or only use "any" as the error suggests:

"purpose": "maskable any"

or

"purpose": "any"

error 1 and 3 go away.

so its a little confusing if it should be there or not.

EDIT:
i did not have the newest version of chrome installed. i just went from 89->95 and now i get the same error as the OP when my "purpose" has "any".

though i still get the same errors when i dont have "any":

image

so chrome is complaining either way for me

@xavax31
Copy link

xavax31 commented Nov 7, 2021

Same problem for me in chrome 95.0.4638.69

@onderceylan
Copy link
Collaborator

Thanks for reporting the warnings. You can track the updates on this issue: #725

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working released
Projects
None yet
Development

No branches or pull requests

5 participants