I am wondering what the path and issue is for this error from Lighthouse Audit:
Web app manifest does not meet the installability requirements
Failures: Manifest icon failed to be fetched.
I have all of my images icons from 72x72 to 512x512 so I am wondering what the problem is?
in the public folder i have a folder: assets/icons/(all the icons)
This is the manifest.json
{
"name": "Chronowell",
"short_name": "Chronowell",
"theme_color": "#000099",
"background_color": "#000099",
"display": "fullscreen",
"Scope": "/",
"start_url": "/",
"icons": [
{
"src": "assets/icons/icon-72x72.png",
"sizes": "72x72",
"type": "image/png"
},
{
"src": "assets/icons/icon-96x96.png",
"sizes": "96x96",
"type": "image/png"
},
{
"src": "assets/icons/icon-128x128.png",
"sizes": "128x128",
"type": "image/png"
},
{
"src": "assets/icons/icon-144x144.png",
"sizes": "144x144",
"type": "image/png"
},
{
"src": "assets/icons/icon-152x152.png",
"sizes": "152x152",
"type": "image/png"
},
{
"src": "assets/icons/icon-192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "assets/icons/icon-384x384.png",
"sizes": "384x384",
"type": "image/png"
},
{
"src": "assets/icons/icon-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"splash_pages": null
}
Make sure that the icons are accessible. You can find the URL that chrome is trying to access under "Application" tab under "manifest", they will be shown there if there is a problem.
One problem I had was that the icons and the manifest are requested without sending cookies. My server would return "Unauthorized" in that case.
The manifest can be adjusted to send cookies like this:
<link rel="manifest" href="/app/manifest.json" crossorigin="use-credentials">
For the icons I'm not sure if there is a option to send them with credentials. I resolved the issue by putting them in a publicly accessible folder and updating the manifest to contain absolute URL's.
You are not able to fetch your icons because you're setting the URL in the wrong way. Your URL should be: "/assets/icons/icon-72x72.png" in this case. First of all, make sure you're passing the right URL, and test if your icons are accessible first. Hope this answer helps you.
Related
I fetched two emails from Gmail via their APIs, one contains an inline picture, the other contains an picture attachment. See their HTTP response below.
By comparing these two sections, I am not able to tell which picture is attached and which is inline. "Content-Disposition" shows that both are attachments, though one of them is actually an inline photo.
Is there a way to identify inline pictures with the response from Gmail API?
// inline
{
"partId": "2",
"mimeType": "image/heic",
"filename": "image_50410497.JPG",
"headers": [
{
"name": "Content-Type",
"value": "image/heic; name=\"image_50410497.JPG\""
},
{
"name": "Content-Disposition",
"value": "attachment; filename=\"image_50410497.JPG\""
},
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "X-Attachment-Id",
"value": "18334b929992fd46a211"
},
{
"name": "Content-ID",
"value": "\u003c18334b929992fd46a211\u003e"
}
],
"body": {
"attachmentId": "ANGjdJ8FshN6fd_2OoZEttwPYHk_8q1mVOJevilskBM-6yOZZ6aMMSMblU3Vo5pw-V1_SeDzxkVx0zOg5R-9fGkaSGvGzd6Wi9yVBe4dAn03HDCghyUWFC2jyodeWYmttzzaXyCNRUVPdVxmO7l8yTaeEsQ4Ep1Ze7Nc3bnLNozWHeKZQHQLqGyfLKDdEI1GKjT8X6OuyEY6EWMo8djE30c-BvYjuY95vmomjkjzfoIqTFfpUlMMktNUfvC1SZMHL0arymXmTTM6uVg5N0U2TngVfbKNx0x8hI0bhccB-AiIhwrSqCxM_CZkyXrGRcY",
"size": 2607632
}
},
// attached
{
"partId": "1",
"mimeType": "image/jpeg",
"filename": "unnamed.jpeg",
"headers": [
{
"name": "Content-Type",
"value": "image/jpeg; name=\"unnamed.jpeg\""
},
{
"name": "Content-Disposition",
"value": "attachment; filename=\"unnamed.jpeg\""
},
{
"name": "Content-Transfer-Encoding",
"value": "base64"
},
{
"name": "Content-ID",
"value": "\u003cf_l83jtl4x0\u003e"
},
{
"name": "X-Attachment-Id",
"value": "f_l83jtl4x0"
}
],
"body": {
"attachmentId": "ANGjdJ_6KFGMzvKW6XFwD4BaSjCDSQGWPEMpL97DE1Lx31cKi2cSzSTOMDIdTEV8wyvnLiB8iqg5_1CVlDOOofl4NiEll2IwrxDuE-IdDXP9PmryOXbMp0pFgIQ961UQWQk8yhObqPcx8xWnqQaPWI3pwirH6hhoe3JtswoLXQ1NDs7FjJZ2iivLZHoTvMlh-i4VQIK6JVaEdIcQBejI6WruTi7DuC_ZpRwewfReZ2JsPKtncVCFwOkb0Ov1vElLS7Y1BTATiRzurXQw1A4lYOn5-XDKqXk90p_HxEQO5zEsvdz2MigVSa803-mIvK8RFTyOOuA4iVWEzad0I3mEFVE6bxTfFQ_YnAYm1FLKImnMEkJf5MuyZofZleyu8fjTGGqzvWmjikDGLvAzdM2O",
"size": 1553427
}
}
UPDATE:
Max mentioned 'Content-ID', I can confirm it works for some emails I have, here is an example:
// header of the attachment part
{
"name": "Content-ID",
"value": "\u003cii_l83jb7dh0\u003e"
}
// decoded HTML body
<img src="cid:ii_l83jb7dh0" alt="20190906-2P2A3622.jpeg" width="361" height="542"><br>
Sometimes the only thing that distinguishes them is whether the Content-ID is referenced in the HTML body of the message. More precisely, by any reasonable definition, that image is an attachment, but it may also be referenced as a cid: url in an <img> tag in an HTML mime part. The header information alone cannot tell you that.
this is my first time working with service workers and I am having difficulties because I always get this error in the Network - Application - Manifest tab:
Some technical details:
package.json
"#angular/animations": "~9.1.0",
"#angular/common": "~9.1.0",
"#angular/compiler": "~9.1.0",
"#angular/core": "~9.1.0",
"#angular/forms": "~9.1.0",
"#angular/localize": "~9.1.0",
"#angular/platform-browser": "~9.1.0",
"#angular/platform-browser-dynamic": "~9.1.0",
"#angular/pwa": "^0.901.12",
"#angular/router": "~9.1.0",
"#angular/service-worker": "~9.1.0",
angular.json
"configurations": {
"production": {
"fileReplacements": [
{
"replace": "projects/appName/src/environments/environment.ts",
"with": "projects/appName/src/environments/environment.prod.ts"
}
],
"optimization": true,
"outputHashing": "all",
"sourceMap": false,
"extractCss": true,
"namedChunks": false,
"extractLicenses": true,
"vendorChunk": false,
"buildOptimizer": true,
"budgets": [
{
"type": "initial",
"maximumWarning": "5mb",
"maximumError": "5mb"
},
{
"type": "anyComponentStyle",
"maximumWarning": "6kb",
"maximumError": "10kb"
}
],
"serviceWorker": true,
"ngswConfigPath": "projects/appName/src/ngsw-config.json"
manifest.webmanifest
{
"name": "app name",
"short_name": "app",
"description": "test test",
"theme_color": "#003f8b",
"background_color": "#ffffff",
"display": "standalone",
"orientation": "portrait",
"scope": "/",
"start_url": "/",
"icons": [
{
"src": "favicon.ico",
"sizes": "16x16",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/flatwork.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/icon-withdrawal-mark.png",
"sizes": "27x23",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/incoming.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/input.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/master_data_icon.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/outgoing.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/output.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/rental_outfit.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/repair.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/scanned_on.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
},
{
"src": "assets/images/icons/tooltip_icon.svg",
"sizes": "150x150",
"type": "image/png",
"purpose": "any"
}
]
}
index.html
<meta name="theme-color" content="#003f8b" />
<link rel="manifest" href="manifest.webmanifest" />
<body>
<bar-root></bar-root>
<noscript
>Please enable JavaScript to continue using this application.</noscript
>
</body>
app.module
imports: [
BrowserModule,
ServiceWorkerModule.register('../ngsw-worker.js', {
enabled: environment.production
}),
... // other imports
],
providers: [
{
provide: SwRegistrationOptions,
useFactory: () => ({
enabled: environment.production,
registrationStrategy: 'registerImmediately',
}),
},
]
ngsw-config.json
{
"$schema": "../../../node_modules/#angular/service-worker/config/schema.json",
"index": "/index.html",
"assetGroups": [
{
"name": "app",
"installMode": "prefetch",
"resources": {
"files": [
"/favicon.ico",
"/index.html",
"/manifest.webmanifest",
"/*.css",
"/*.js"
]
}
},
{
"name": "assets",
"installMode": "lazy",
"updateMode": "prefetch",
"resources": {
"files": [
"/assets/**",
"/*.(eot|svg|cur|jpg|png|webp|gif|otf|ttf|woff|woff2|ani)"
]
}
}
]
}
Also, here is the project structure to check the path imports:
What am I missing? Also, what is the best way to test any config changes?
I found a solution regarding my issue, some small changes were required:
app.module - adjusted the service worker registration
ServiceWorkerModule.register('ngsw-worker.js', {
enabled: environment.production,
// Register the ServiceWorker as soon as the app is stable
// or after 30 seconds (whichever comes first).
registrationStrategy: 'registerWhenStable:30000',
}),
In angular.json if you have multiple builds for different environments, lets say production and qa, you can add these configs on both:
"serviceWorker": true,
"ngswConfigPath": "projects/appName/ngsw-config.json"
// or whichever path you have for the ngsw-config.json, but this will probably be generated automatically when installing #angular/pwa.
To test your changes, run ng build or ng build --prod or any other environments you want to test on.
To see the build for the prod environment I used http-server, which you can find in npm and install it. Your build will be created in a dist folder, and in the root folder of the app run(9191 being the port, you can change it to whatever you like, just make sure nothing runs on it):
http-server -p 9191 -c-1 dist/appName
You can open you 9191 localhost port and check in the Deveoper Tools, Application tab, under Manifest and Service Workers to make sure everything is running.
I also removed ngsw-worker.js from my project because it is moved automatically from node_modules when you do the builds.
I get the following error when creating API in Postman: "Invalid data type. Must be either, array, boolean, integer, number, object or string"
The error is fixed when converting the line "type": "file" to "type": "object", but I am not sure if there is a proper way for this situation. Because with this update, the request may not be passed when sending request in Postman.
"parameters": [
{
"in": "body",
"name": "file",
"description": "file",
"required": false,
"schema": {
"type": "array",
"items": {
"type": "file"
}
}
},
...
]
So, how can I fix the problem in Postman?
The problem is not with Postman, but with the API definition. "type": "file" is not a valid type value for use in schemas and body parameters, this type can only be used in in: formData parameters.
On the other hand, I do not add file while trying to test my app via Postman. For this reason, I just want to suppress the errors
In this case you could change "type": "file" to "type": "string" to suppress import errors. Or remove the entire problematic operation from the API definition.
How to properly define file uploads in OpenAPI
The API definition is trying to describe uploading of a file array - but this is not supported in OpenAPI 2.0 (swagger: '2.0'). OAS2 only supports upload of individual named files via multipart/form-data, in which case the API definition would look like this:
{
"swagger: "2.0",
...
"paths": {
"/something": {
"post": {
"consumes": [
"multipart/form-data"
],
"parameters": [
{
"in": "formData",
"name": "file1",
"type": "file" // A single file sent via form field "file1"
},
{
"in": "formData",
"name": "file2",
"type": "file" // Another file sent via form field "file2"
}
]
...
}
Uploading an array of files is supported in OpenAPI 3 though:
{
"openapi": "3.0.0",
...
"paths": {
"/something": {
"post": {
"requestBody": {
"content": {
"multipart/form-data": {
"schema": {
"type": "object",
"properties": {
"file": {
"type": "array",
"items": {
"type": "string",
"format": "binary"
}
}
}
}
}
}
},
...
}
}
}
}
I made a PWA. Currently is deployed on heroku. URL - https://plain-js-pwa.herokuapp.com/.
My PWA installs service worker and manifest.json file. If I open it on chrome on mobile phone and put my phone on flight mode, then refreshing the url still gives shows me my application. Its expected as my service worker is doing offline caching.
But when I add my PWA to home screen, and try to open it on flight mode then it doesn't work. This is probably my first PWA, so please help me. I am generating my service worker file from 'sw-precache-webpack-plugin'.
My manifest.json file is:
{
"name": "VanillaJS-webpack App",
"short_name": "VanillaJS-webpack App",
"description": null,
"dir": "auto",
"lang": "en-US",
"display": "standalone",
"orientation": "any",
"start_url": "/?homescreen=1",
"background_color": "#ee6e73",
"icons": [
{
"src": "android-chrome-36x36.png",
"sizes": "36x36",
"type": "image/png"
},
{
"src": "android-chrome-48x48.png",
"sizes": "48x48",
"type": "image/png"
},
{
"src": "android-chrome-72x72.png",
"sizes": "72x72",
"type": "image/png"
},
{
"src": "android-chrome-96x96.png",
"sizes": "96x96",
"type": "image/png"
},
{
"src": "android-chrome-144x144.png",
"sizes": "144x144",
"type": "image/png"
},
{
"src": "android-chrome-192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/android-chrome-256x256.png",
"sizes": "256x256",
"type": "image/png"
},
{
"src": "/android-chrome-384x384.png",
"sizes": "384x384",
"type": "image/png"
},
{
"src": "/android-chrome-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
]
}
When loading from home screen it should work in the same way as when loaded from the browser.
In your example, a quick debugging seems to indicate that the problem is related to the query string: https://plain-js-pwa.herokuapp.com/?homescreen=1
It does not work offline when the query string is added (irrelevant if loaded from home screen or otherwise). Without looking at your service worker configuration, most likely you need to instruct your service worker to ignore query string params using ignoreSearch (https://developer.mozilla.org/en-US/docs/Web/API/Cache/match) or ignoreUrlParametersMatching if using sw-precache.
I've been successfully fetching only photos posted at my Facebook page via Opengraph api and now I want to display some links shared at the page through the similar method that I've been using to fetch photos.
The problem is that type=link posts don't contain object_id, which can be used to fetch a bigger thumbnail for photos like https://https://graph.facebook.com/<%= post['object_id'] %>/picture. What a type=link post returns is as follows.
Response
"id": "127100524044142_757791214308400",
"from": { ... },
"to": { ... },
"message": "...",
"message_tags": { ... },
"picture": "https://fbexternal-a.akamaihd.net/safe_image.php?d=AQA5ofIEKR1dK6_T&w=158&h=158&url=http\u00253A\u00252F\u00252Fyeondoo.kr\u00252Fassets\u00252Fstaffs-88e474e70d16794e898d5f4bb200f710.jpg",
"link": "...",
"name": "...",
"caption": "...",
"description": "...",
"icon": "https://fbstatic-a.akamaihd.net/rsrc.php/v2/yD/r/aS8ecmYRys0.gif",
"privacy": {
"value": ""
},
"type": "link",
"status_type": "shared_story",
"created_time": "2015-01-25T06:08:11+0000",
"updated_time": "2015-01-25T07:54:28+0000",
"likes": { ...
],
"paging": { ... }
},
"comments": { ...
],
"paging": { ... }
}
I could get the url for "small" thumbnails via picture property, but this is too small to display on the website. Is there any solution to get a larger thumbnail for Facebook page, if that matters although I don't think it would, link posts via Opengraph API?
I happen to find a field which is not specified as default. It is full_picture and it returns the url for the "larger" thumbnail.
/posts?fields=full_picture
"full_picture": "https://fbexternal-a.akamaihd.net/safe_image.php?d=AQBHe3GKoga49ZHw&url=http%3A%2F%2Fyeondoo.kr%2Fassets%2Fstaffs-88e474e70d16794e898d5f4bb200f710.jpg",
"id": "127100524044142_757791214308400",
"created_time": "2015-01-25T06:08:11+0000"