"This function must be called during a user gesture" error on save in Page Editor

[twschiller]

Context

• @MMirandi encountered the error on 1.7.4-beta.1 when saving the playground blueprint (which has 6+ extensions in it)
• https://pixiebrix.slack.com/archives/C02CN01JXAA/p1660423174849619
• This does not prevent saving, the blueprint/extension is still saved

Discussion/Hypotheses

• If useCreate's callback is called for each extension in a blueprint, we could be running into an issue with large blueprints where internal timer for user action is being exceeded?

  • pixiebrix-extension/src/pageEditor/panes/save/useRecipeSaver.ts

    Line 139 in f4d8b80

    await Promise.all(

• The alert should have a warning style (because it's a warning not an error). I opened an issue here: Differentiate warning toast from error toast style #4020

Workaround

• On the Blueprints Screen click the grant permission button (if it's showing)

Related Tickers

• Regression: "This function must be called during a user gesture" when saving extension #3961

[twschiller]

Deprioritizing because we haven't seen users encountering issue in awhile

[fregante]

The issue only exists when we inadvertently delay the permissions.request call, technically it was fixed.

However, what can we do to avoid it in the future? Example:

• wrap the request API in a event handler
• expose the API exclusively through the handler

This would let us set up early notifications if the API is called "too close to the timeout":

<Button onClick={permissionHandler(async (request) => {
	await whateverLongRunningTask();
	await request(permissions); // `console.warn('request was called 1000ms after the click handler, reduce this delay to avoid #4019')
})}>

Also are these errors already automatically reported?

[twschiller]

However, what can we do to avoid it in the future?

I think that approach is reasonable. It would still be hard to catch introducing a delay during PR review though, as it would depend on the timing.

Also are these errors already automatically reported?

IIRC, they should be because of the top-level rejection handler

[fregante]

Just thought of this: must we set the permission on "Save"?

We already have a dedicated "Grant permission" button that does one thing and will never cause this issue.

Another problem with the current situation is that a permission will be requested every time the user saves the brick, even if they reject it or don't need it (think contextMenu and the like)

[twschiller]

This issue is no longer relevant because we're getting all permissions up-front