profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jakearchibald/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

GoogleChromeLabs/squoosh 13745

Make images smaller using best-in-class codecs, right in the browser.

GoogleChromeLabs/proxx 1093

A game of proximity

dominiccooney/cache-polyfill 462

Service Worker Cache polyfill extracted from https://jakearchibald.github.io/trained-to-thrill/

GoogleChromeLabs/file-drop 198

A simple file drag and drop custom-element

GoogleChromeLabs/pointer-tracker 98

Track mouse/touch/pointer events for a given element.

startedjakearchibald/request-quest

started time in 5 minutes

startedjakearchibald/idb

started time in 2 hours

startedjakearchibald/idb

started time in 4 hours

PR opened GoogleChromeLabs/squoosh

Specify supported node versions

Closes #1059 (or should it stay open to track docs?)

Supported Node versions are now specified in package.json, meaning npm will warn users that install on an unsupported version.

Note that these files are not up to date! A bunch of changes have been published to npm, but they are not present in the repository.

+9 -0

0 comment

3 changed files

pr created time in 5 hours

issue commentGoogleChromeLabs/squoosh

WASM gifsicle

@surma gifsicle will be used not only for animation, it is still used on legacy sites and will be good to compress them too, also animation gifs can be compressed too and it is good

jakearchibald

comment created time in 6 hours

issue commentjakearchibald/idb

Safari iOS/iPadOS 14.6 Bug: First Attempt at Opening indexedDB gets stuck

Seems sad to add a whole new API for a temporary Safari bug.

I agree with that 😞

jakearchibald

comment created time in 6 hours

issue commentGoogleChromeLabs/squoosh

Add supported node versions to @squoosh/cli and @squoosh/lib readmes

Cool, I'll make a PR for the package.json thing. Ideally, the docs should be updated based on what is set in package.json. I'm not sure if there are plans for a system that facilitates that.

ergunsh

comment created time in 7 hours

issue commentGoogleChromeLabs/squoosh

Add supported node versions to @squoosh/cli and @squoosh/lib readmes

Yeah I was trying to remember if engines in package.json would generate a warning. This SGTM! PRs appreciated :)

ergunsh

comment created time in 7 hours

issue commentGoogleChromeLabs/squoosh

Add supported node versions to @squoosh/cli and @squoosh/lib readmes

My thought process when releasing this was simply that for an experimental program, it was okay to remove support for Node versions that have active security vulnerabilities, and that can very easily be updated to a new version, especially because it gave us some nice perks to be able to use the new import syntax.

I completely agree it should be documented somewhere. In the docs and/or in package.json. If you define it in package.json, npm will warn anyone that tries to install it with an unsupported Node version. I'll happily provide a PR for that :)

ergunsh

comment created time in 7 hours

issue openedGoogleChromeLabs/squoosh

New feature: Signal if an image is lossless or lossy

I have a use case where I need to know if an input image is compressed with a lossy or lossless algorithm. Figuring this out is easy for codecs like png and jpg which only support one type, but it's not that simple when I want to test a webp or jxl image. Ideally, I would be able to get this information directly from Squoosh.

I have build a draft implementation in Squoosh, and it seems relatively simple to add this. I am detecting lossy/lossless encoding by reading the first two chunks of every image. Please let me know if there's a smarter way to get this info :D The signal would be added to libSquoosh as Image.decoded.lossless: true | false.

Apart from helping me out, I also think this could be very useful for Squoosh itself. Currently, Squoosh will default to encoding any image lossy, even if it's an SVG. With this signal, it should be possible to automatically toggle the lossy/lossless switch in the target encoder, matching the encoding type for the input image, resulting in much better defaults.

Adding a system to change defaults based on the input image seems so complex that it's probably better to let the core team do it (or do you disagree?), but if I can get a green light on this, I'll be happy to implement the signal :)

created time in 8 hours

issue commentGoogleChromeLabs/squoosh

Add supported node versions to @squoosh/cli and @squoosh/lib readmes

Yeah, we support all Node version since LTS (so 12, 14, 16), but we do expect the most recent of those respective major releases. Happy to take a PR to update the README accordingly.

(also cheekily cc’ing @atjn if he has opinions on this)

ergunsh

comment created time in 8 hours

issue openedGoogleChromeLabs/squoosh

Add supported node versions to @squoosh/cli and @squoosh/lib readmes

Describe the bug Currently, when I try to run the cli in different node versions, different kind of errors are occurring related to imports.

As far as I understand, support for named exports came to Node at v14.13.0 (Release notes) and we need it. For example, when I run in v14.0.0, I get this error:

import { ImagePool, preprocessors, encoders } from '@squoosh/lib';
                                   ^^^^^^^^
SyntaxError: The requested module '@squoosh/lib' does not provide an export named 'encoders'

I guess there are two possible things we can do:

  • Document the Node versions we support (as v14.13.0 for CLI and I don't know for libSquoosh 😅 )
  • Update build config to support more node versions and document the ones we support in readme

To Reproduce Steps to reproduce the behavior:

  1. Install Node v14.0.0 (via nvm: nvm install v14.0.0)
  2. Use Node v14.0.0 (via nvm: nvm use v14.0.0)
  3. Install @squoosh-cli globally (via npm install -g @squoosh/cli)
  4. Run the CLI (via squoosh-cli)
  5. Observe that there is an error related to imports

Expected behavior The import error shouldn't happen (or people should know and not use CLI prior to Node v14.13.0)

Version:

  • Node version: 14.0.0
  • npm version: 6.14.4

created time in 8 hours

issue commentjakearchibald/idb

Safari iOS/iPadOS 14.6 Bug: First Attempt at Opening indexedDB gets stuck

The main problem here is:

import { openDB, unwrap } from 'idb';

const openPromise = openDB(...args);
const idbOpenRequest = unwrap(openPromise);

I can't introduce a 'wait' into openDB without breaking the unwrap case, since I won't have the real idbOpenRequest yet.

Could add an unwrapAsync to handle this scenario. Is unwrap commonly used by idb users? 🤔

jakearchibald

comment created time in 8 hours

startedjakearchibald/safari-14-idb-fix

started time in 8 hours

issue commentwhatwg/fetch

Consider shifting the "bad port list" to an allowlist.

Would this mean that the allowlist couldn't be expanded since we could similarly never know if it's safe to allow any currently blocked port?

Yes, I think we would never add new ports to the allowlist, only remove them.

Would a devtools configured exception be possible to use while not keeping devtools open (i.e. similar to adding an exception to your firewall)? I've seen many cases where the presence of devtools significantly slows down the site, and it's awkward to lose that screen real estate when you're not working on the site.

So essentially it would be a normal browser setting, but hidden in devtools rather than on the usual setting page? It might work.

Alternately, could we get most of the benefit without some of the pain by not restricting the main navigation, but only restricting sub-resource requests (explicitly allowing them to the ip:port used for the main navigation)?

I think the security benefits of this are not that great, since you can perform many attacks just by using a form with POST. However, it might be a good transitional stage to get web developers used the idea of there being an allowlist.

mikewest

comment created time in 9 hours

push eventGoogleChromeLabs/squoosh

atjn

commit sha 955b2ac1ba4c92da607a6e2cb4064143ad7fc1ce

Fix WebP sniffing some more

view details

Surma

commit sha 61de471e52147ecdc8ff674f3fcd3bbf69bb214a

Merge pull request #1058 from atjn/fix-detectors Fix WebP sniffing some more

view details

push time in 10 hours

PR merged GoogleChromeLabs/squoosh

Fix WebP sniffing some more CLA: Yes

I have a large folder of WebP images that I use to test squoosh. All of them are valid and can be opened in Firefox/Chrome, but libSquoosh is being very dramatic about two of them, telling me [file] has an unsupported format.

Here are the first chunks of the two failing images:

 82  73  70  70  10  19   0   0  87  69  66  80  86  80  56  32
[R] [I] [F] [F]  []  []  []  [] [W] [E] [B] [P] [V] [P] [8] [ ]
 82  73  70  70 236  10   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [ì]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

And here are two functioning images for comparison:

 82  73  70  70 174  18   0   0  87  69  66  80  86  80  56  88
[R] [I] [F] [F] [®]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [X]
 82  73  70  70 202 131   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [Ê]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

The failing images both contain the code point 10, which JavaScript interprets as a newline. RegEx (which libSquoosh uses to sniff the image encoding) won't match across newlines by default. For that to work, you have to add the s flag, which is what this PR does :)

For annoying legal reasons, I can't post the failing images publicly, but I can send one of them privately if you'd like me to.

+2 -2

0 comment

2 changed files

atjn

pr closed time in 10 hours

PR opened GoogleChromeLabs/squoosh

Fix WebP sniffing some more

I have a large folder of WebP images that I use to test squoosh. All of them are valid and can be opened in Firefox/Chrome, but libSquoosh is being very dramatic about two of them, telling me [file] has an unsupported format.

Here are the first chunks of the two failing images:

 82  73  70  70  10  19   0   0  87  69  66  80  86  80  56  32
[R] [I] [F] [F]  []  []  []  [] [W] [E] [B] [P] [V] [P] [8] [ ]
 82  73  70  70 236  10   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [ì]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

And here are two functioning images for comparison:

 82  73  70  70 174  18   0   0  87  69  66  80  86  80  56  88
[R] [I] [F] [F] [®]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [X]
 82  73  70  70 202 131   0   0  87  69  66  80  86  80  56  76
[R] [I] [F] [F] [Ê]  []  []  [] [W] [E] [B] [P] [V] [P] [8] [L]

The failing images both contain the code point 10, which JavaScript interprets as a newline. RegEx (which libSquoosh uses to sniff the image encoding) won't match across newlines by default. For that to work, you have to add the s flag, which is what this PR does :)

For annoying legal reasons, I can't post the failing images publicly, but I can send one of them privately if you'd like me to.

+2 -2

0 comment

2 changed files

pr created time in 10 hours

issue commentGoogleChromeLabs/squoosh

[CLI] Limit the number of decoded images in memory

Async pool seems small and good enough. Not sure if it’s necessary, but whoever takes this on, is welcome to use it.

illycz

comment created time in 11 hours

issue commentGoogleChromeLabs/squoosh

[CLI] Batch Conversion fail

Looking into this, ti seems the wildcards are not working in Windows.

@samdutton is working on adding globs, so this will hopefully get solved through his work!

ianzhuo

comment created time in 11 hours

startedjakearchibald/safari-14-idb-fix

started time in 12 hours

startedjakearchibald/svgomg

started time in 12 hours

PR opened jakearchibald/safari-14-idb-fix

Avoid checking `userAgent` in Chrome

You'll get a DevTools "improvement" suggested for accessing navigator.userAgent. One would might realistically expect this issue to be fixed before Safari adds support for navigator.userAgentData, so this feels like a reasonable addition just in case you want to give it a whirl.

+1 -0

0 comment

1 changed file

pr created time in 13 hours

fork rowan-m/safari-14-idb-fix

Working around a Safari IndexedDB bug

fork in 14 hours

startedjakearchibald/safari-14-idb-fix

started time in 15 hours

startedjakearchibald/safari-14-idb-fix

started time in 17 hours

startedjakearchibald/idb

started time in 17 hours

startedjakearchibald/svgomg

started time in 18 hours

startedjakearchibald/idb

started time in 18 hours

startedjakearchibald/svgomg

started time in 18 hours