Skip to content

Don't require action within a Promise reaction microtask. #570

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

jan-ivar
Copy link
Contributor

@jan-ivar jan-ivar commented Apr 26, 2025

Copy link
Contributor

@jyasskin jyasskin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jan-ivar. I've left a bunch of suggestions for @martinthomson to review, and you're welcome to apply any that you agree with or make other changes in response, but we can also take it from here.

@jyasskin jyasskin requested a review from martinthomson May 8, 2025 21:59

<p>If an algorithm requires that callback functions respond
synchronously (e.g. to take or veto some action), then that is a
synchronous API, and should not be modelled with a promise. Instead,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
synchronous API, and should not be modelled with a promise. Instead,
synchronous API, and should not be modeled with a Promise. Instead,

you may not require action within
a fixed number of microtasks.</p>

<p>This protects promise composition: patterns like <code>await</code>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p>This protects promise composition: patterns like <code>await</code>,
<p>This protects Promise composition: patterns like <code>await</code>,

Comment on lines +1986 to +1989
If developer-supplied code needs to be able to call <code>event.{{Event/preventDefault()}}</code>
or choose a response object with
<code>fetchEvent.{{FetchEvent/respondWith()}}</code>,
it needs to be a callback rather than a reaction passed to <code>Promise.{{Promise/then()}}</code>.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a good example or a bad one?

Comment on lines +1992 to +1994
A non-event example is the <code>captureController.{{CaptureController/setFocusBehavior()}}</code>
method to push a window the user has chosen to screen-capture, to
the front. Applications can decide this based on the window chosen.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A non-event example is the <code>captureController.{{CaptureController/setFocusBehavior()}}</code>
method to push a window the user has chosen to screen-capture, to
the front. Applications can decide this based on the window chosen.
A non-event example is the <code>captureController.{{CaptureController/setFocusBehavior()}}</code>
method, which pushes a window the user has chosen to screen-capture to
the front. Applications can decide this based on the window chosen.

A non-event example is the <code>captureController.{{CaptureController/setFocusBehavior()}}</code>
method to push a window the user has chosen to screen-capture, to
the front. Applications can decide this based on the window chosen.
But any delay risks click-jacking.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
But any delay risks click-jacking.
The challenge is that allowing delay creates an opportunity for click-jacking attacks from sites.

A link defining click-jacking would be helpful.

But any delay risks click-jacking.

Instead of requiring the method be called synchronously on the
reaction microtask of the promise from `getDisplayMedia()`, the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
reaction microtask of the promise from `getDisplayMedia()`, the
reaction microtask of the promise from `getDisplayMedia()`, the

A link to getDisplayMedia() would also be helpful.

<h4 id="sync-callbacks">When to use callback functions instead</h4>

<p>If an algorithm requires that callback functions respond
synchronously (e.g. to take or veto some action), then that is a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
synchronously (e.g. to take or veto some action), then that is a
synchronously (e.g., to take or veto some action), then that is a

I'm not sure about our conventions here; this is the one that I've been taught to use.

... checks ...

damn. Well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

New principle: Support common promise practices
3 participants