No preview for WebP images
Categories
(DevTools :: Netmonitor, defect, P3)
Tracking
(Not tracked)
People
(Reporter: pmenzel+bugzilla.mozilla.org, Assigned: bomsy)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
MC_89a1_2021-03-23.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0
Steps to reproduce:
Start developer tools, and go to network analysis tab.
Open https://www.ecosia.org/. Hover over the WebP image.
Actual results:
No preview is shown as with other image formats.
Expected results:
The preview should be shown.
The suffix is *webp, but the type is octet-stream.
$ curl -I https://cdn-indexpage.ecosia.org/img/bfdfa41.webp
HTTP/2 200
content-type: binary/octet-stream
content-length: 35182
date: Tue, 16 Mar 2021 11:39:36 GMT
last-modified: Fri, 12 Mar 2021 14:46:00 GMT
x-amz-expiration: expiry-date="Thu, 09 Sep 2021 00:00:00 GMT", rule-id="tf-s3-lifecycle-20200312122402000500000002"
etag: "bfdfa412d78a267c3900f88b2631c602"
cache-control: max-age=31536000,public
accept-ranges: bytes
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 8002c303d4f2295f77566a349deba122.cloudfront.net (CloudFront)
x-amz-cf-pop: FRA2-C1
x-amz-cf-id: m9zbjhxV5J1_Z39RDaW66y802DRIity0UAxJ5zuvzzubaeK5twFd4g==
age: 71856
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•4 years ago
|
||
Seems like a devtools issue?
The suffix is *webp, but the type is octet-stream.
I can confirm that the preview works when the content-type is image/webp.
We should figure out if we want this to work for octet-stream, and if not raise a web-compat issue with ecosia.
Note: our preview shows the ascii encoded bytes. Chrome shows an actual image.
|
||
Comment 3•4 years ago
•
|
||
Thanks for the report!
I can easily reproducible on my machine (Win10, Nightly). I don't see preview for the image/webp image
Also, when filtering the panel content using "Images" filter - the image isn't visible
We should properly support image/webp content type?
Honza
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Comment 5•4 years ago
|
||
Bomsy, can you reproduce this one?
|
Assignee | |
Comment 6•4 years ago
•
|
||
MC without fix e.g (89.0a1 (2021-03-23) )
The webp image shows as the type octet/stream and the image does not show on preview.
|
|
Assignee | |
Comment 7•4 years ago
|
||
MC with fix (89.0a1 (2021-03-26) )
The webp image shows as the type webp and the image previews properly
|
|
Assignee | |
Comment 8•4 years ago
|
||
So i see that when the type is webP it works fine (The image is previewed properly). It does not work when the type is octet-stream.
From the attached images, it seems like something has been fixed recently on MC.
Honza,
can you confirm that you see this on the latest MC?
|
|
||
Comment 9•4 years ago
|
||
I tested on my m-c build (pulled this morning), Nightly and also the current Release channel (all on Win10) and I am always seeing octet-stream for the bfdfa41.webp resource. No preview available.
Honza
|
|
Assignee | |
Comment 10•4 years ago
|
||
So the inconsistency here seems to be related to the OS ... linux and Win seems to detect the mimeType for webp as application/octet-stream while Mac OS shows image/webp. We came across same issue in some other work relating to fonts. See https://searchfox.org/mozilla-central/rev/49e0a928390a8013a4eb08b7b3bbff025f01913a/devtools/client/netmonitor/test/browser_net_fonts.js#54-59
I think we could fix this by checking if the the type is octet-stream and if the file extension is .webp and allow previews for those as well.
That can be done here https://searchfox.org/mozilla-central/rev/71515d047cbdd02687a1b9b7265f2ffb51300bf1/devtools/client/netmonitor/src/components/request-list/RequestListContent.js#237
|
|
Assignee | |
Comment 11•4 years ago
|
||
|
||
Updated•4 years ago
|
|
Reporter | |
Comment 12•2 years ago
|
||
Using Nightly 106.0a1 (20220829094551) and visiting the WebP image galleries, the preview works (for files not loaded from cache with cache disabled).
|
|
Reporter | |
Comment 13•2 years ago
|
||
The WebP image galleries has content-type: image/webp, so my test was moot.
$ curl -I https://www.gstatic.com/webp/gallery3/1_webp_ll.webp
HTTP/2 200
accept-ranges: bytes
vary: Origin
content-security-policy-report-only: require-trusted-types-for 'script'; report-uri https://csp.withgoogle.com/csp/on2-prod
cross-origin-resource-policy: cross-origin
cross-origin-opener-policy: same-origin; report-to="on2-prod"
report-to: {"group":"on2-prod","max_age":2592000,"endpoints":[{"url":"https://csp.withgoogle.com/csp/report-to/on2-prod"}]}
content-length: 81836
x-content-type-options: nosniff
server: sffe
x-xss-protection: 0
date: Mon, 19 Dec 2022 11:24:51 GMT
expires: Tue, 19 Dec 2023 11:24:51 GMT
cache-control: public, max-age=31536000
last-modified: Fri, 23 Apr 2021 09:38:00 GMT
content-type: image/webp
age: 101500
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
|
|
Reporter | |
Comment 14•2 years ago
|
||
Ecosia still uses content-type: binary/octet-stream, and I just tested that it works with (at least) Nightly 110.0a1, 20221219162526.
$ curl -I https://cdn-indexpage.ecosia.org/img/above-fold@2x.16f30ae.webp
HTTP/2 200
content-type: binary/octet-stream
content-length: 97934
date: Tue, 20 Dec 2022 15:33:50 GMT
last-modified: Tue, 20 Dec 2022 10:27:04 GMT
x-amz-expiration: expiry-date="Mon, 19 Jun 2023 00:00:00 GMT", rule-id="tf-s3-lifecycle-20200312122402000500000002"
etag: "439a8c480ff5fdacd2e8d15146c8f0c4"
cache-control: max-age=31536000,public
accept-ranges: bytes
server: AmazonS3
x-cache: Miss from cloudfront
via: 1.1 99d54fc6a14abf3079ffadd5aa7c99de.cloudfront.net (CloudFront)
x-amz-cf-pop: TXL50-P1
x-amz-cf-id: reNZs17TBliPSJBwiWr1wDKliUEAE37P_C4JeJ5MOKtod6Gy1WHEAg==
Description
•