pixiebrix-extension icon indicating copy to clipboard operation
pixiebrix-extension copied to clipboard

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

Open twschiller opened this issue 3 years ago • 1 comments

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?
    • https://github.com/pixiebrix/pixiebrix-extension/blob/f4d8b80b2253519d366b0cb4aed83bb7106cb781/src/pageEditor/panes/save/useRecipeSaver.ts#L139-L139
  • The alert should have a warning style (because it's a warning not an error). I opened an issue here: https://github.com/pixiebrix/pixiebrix-extension/issues/4020

Workaround

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

Related Tickers

  • https://github.com/pixiebrix/pixiebrix-extension/issues/3961

twschiller avatar Aug 13 '22 21:08 twschiller

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

twschiller avatar Oct 19 '22 18:10 twschiller

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?

fregante avatar Oct 23 '22 09:10 fregante

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

twschiller avatar Oct 23 '22 21:10 twschiller

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)

fregante avatar Jan 25 '23 05:01 fregante

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

twschiller avatar Nov 06 '23 18:11 twschiller