Spec differentiates between ImageDecoder initialization with unsupported non-image MIME type and an unsupported image MIME type
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
調査の方向性
issue にリンクされている ImageDecoder constructor、valid ImageDecoderInit、valid image MIME type、Configure the ImageDecoder の各セクションを読みます。記載されているエラーを、image-decoder.https.any.js の 163 行目にある WPT と比較します。仕様とテストのどちらを修正する必要があるかについて合意に達し、解決した動作を文書化できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
There is a WPT that checks for a NotSupportedError promise rejection when the MIME type "junk/type"
https://github.com/web-platform-tests/wpt/blob/53a1437dcfc754a3dc8ffe0bd34f9a6524e49fcf/webcodecs/image-decoder.https.any.js#L163
This conflicts with a strict reading of the spec:
From https://w3c.github.io/webcodecs/#imagedecoder-constructor:
"If init is not valid ImageDecoderInit, throw a TypeError."
From https://w3c.github.io/webcodecs/#valid-imagedecoderinit:
"1. If type is not a valid image MIME type, return false."
From https://w3c.github.io/webcodecs/#valid-image-mime-type:
"A valid image MIME type is a string that is a valid MIME type string and for which the type, per Section 8.3.1 of [RFC9110], is image."
From https://w3c.github.io/webcodecs/#configure-the-image-decoder
"1. Let supported be the result of running the Check Type Support algorithm with init.type."
"2. If supported is false, run the Close ImageDecoder algorithm with a NotSupportedError DOMException and return "processed"."
If we put all this together, my reading of it says that if the MIME type supplied is anything besides "image/XXX", we should throw a TypeError in the ImageDecoder constructor. If we don't support XXX, then we should reject the ImageDecoder [[completed promise]] and ImageTrackList [[ready promise]] with NotSupportedError.
Is this what we want? I don't have any strong feelings either way, just want to understand if the test is wrong, or if this is an inconsistency in the spec that we want to correct.
- 主要言語
- HTML
- スター
- 1.3k
- フォーク
- 192
- 平均マージ
- 21時間 7分
- マージ済み PR（30日）
- 8
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
w3c/webcodecs のほかの issue
-
privacy-needs-resolution
難易度 1/5 1時間未満 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
editorial
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
w3c/webcodecs#972 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
w3c/webcodecs#971 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
effort: low prio: low ready
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
digitalfabrik/integreat-cms#4616 ·
メンテナーはふだん 5 日以内に返信
-
refactor topic-map
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
Add an EPUB parserオープンarea: core good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
openapi/gknowledge#21 ·
-
get() for StrEnum対応中かも @FeJo5952 が今日担当しました。 オープンgood first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
collective/icalendar#1921 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
ETQ admin, le select de condition d'une annotation répétable liste les champs publics deux foisオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
demarche-numerique/demarche.numerique.gouv.fr#14301 ·
メンテナーはふだん 1 日以内に返信