Skip to content

Instantly share code, notes, and snippets.

@tmcw

tmcw/gestures.md

Created April 14, 2022 15:47
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tmcw/bd00eb0530f8bf3dcb2670e6dc47acfa to your computer and use it in GitHub Desktop.
Save tmcw/bd00eb0530f8bf3dcb2670e6dc47acfa to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gestures.md

My least favorite part of the web platform

Behold, the worst part of the web platform: user gestures.

In short, let's say you've built a web application that edits maps, or… does something else, hypothetically. You implement file saving in that application using the fancy new native browser APIs. Then you have to do some stuff to process or load the file when you click Save - like if you're converting the file and you want to do it in a WebWorker for optimum smoothness. Soon, you will meet this error message:

SecurityError Failed to execute 'showSaveFilePicker' on 'Window': Must be handling a user gesture to show a file picker.

This is just one example of "user gesture" restrictions: you can also find them when you request permissions or attempt to open windows. Basically, to crack down on bad actors or misuse, the browser restricts certain functions to only being called in connection with a click handler.

This would be okay, like barely okay, if that was all it did. But it's not just "in connection with a click handler". If you have an async click handler that takes 1 second to call showSaveFilePicker, it'll probably work! If it takes 5 seconds, it probably won't.

The workarounds are terrible, just absolutely trash. Maybe you have to click the button again? Or you generate the results before you click the button, but in that case do you convert the file every time someone tweaks an export option?

Why this is terrible

  1. It's barely documented. You don't see it on the MDN page, you see a quick shoutout on web.dev. The WICG standard doesn't mention it. It's just a nasty surprise.
  2. It's vague. How much asyncness does it take to trip the tripwire? It's not documented anywhere. It's not zero. It's not infinite. It's somewhere in the middle.
  3. There's basically no clean workaround for it.
  4. This is only there to crack down on bad actors, and it does so in a way that makes it really annoying to use the web platform. Desktop applications can read and write files willy-nilly after they've requested wildly broad access to your Documents directory, or on Windows or Linux, just whenever. But web applications have a million little restrictions and gotchas.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment