w3c / w3c/payment-request

Missing tasks in parallel steps in Payment Request API

Open
#1,032 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
510
Forks
139
PR merge metrics
No merged PRs in 30d

Description

While crawling Payment Request API, the following algorithms fire an event, or resolve or reject a Promise, within a step that runs in parallel without first queuing a task:

  • The algorithm that starts with "The show(optional detailsPromise) method MUST act as follows:" resolves/rejects a promise directly in a step that runs in parallel
  • The algorithm that starts with "The complete() method MUST act as follows:" resolves/rejects a promise directly in a step that runs in parallel
  • The can make payment algorithm algorithm resolves/rejects a promise directly in a step that runs in parallel

See Dealing with the event loop in the HTML specification for guidance on how to deal with algorithm sections that run in parallel.

Cc @dontcallmedom @tidoust

This issue was detected and reported semi-automatically by Strudy based on data collected in webref.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Payment Request API algorithms beginning with “The show(optional detailsPromise) method MUST act as follows:”, “The complete() method MUST act as follows:”, and the can make payment algorithm. Read HTML’s “Dealing with the event loop” guidance first, then verify each parallel step that resolves or rejects a Promise. Done means all three algorithms queue the required task before those operations.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
api, payments
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.