Fix clipboard.readText() algorithm
#238
Conversation
|
The markup error should be fixed by #234. |
annevk
left a comment
annevk
left a comment
There was a problem hiding this comment.
You removed task queueing, but you cannot resolve or reject promises while in parallel without queueing a task first.
Oh, right, I added it back. Thank you. |
annevk
left a comment
annevk
left a comment
There was a problem hiding this comment.
The commit message body could explain a bit more about why this change is being made.
| 1. Abort these steps. | ||
|
|
||
| 1. [=Reject=] |p| with {{"NotFoundError"}} {{DOMException}} in |realm|. | ||
| 1. Resolve |p| with empty string. |
There was a problem hiding this comment.
| 1. Resolve |p| with empty string. | |
| 1. Resolve |p| with the empty string. |
| 1. If |mimeType|'s [=MIME type/essence=] is "`text/plain`": | ||
|
|
||
| 1. If |representation|'s [=representation/MIME type=] [=MIME type/essence=] is "text/plain", then: | ||
| 1. Resolve |p| with |systemClipboardRepresentation|'s [=system clipboard representation/data=]. |
There was a problem hiding this comment.
[=system clipboard representation/data=] can be a string or a blob, right? But we want to always return a string. How is that going to work now?
There was a problem hiding this comment.
Actually, data is defined as a sequence of bytes. So, should we always return the result of [=UTF-8 decoding=] data's bytes?
3 participants
Fixes #236.
For normative changes, the following tasks have been completed:
Editing WG resolution on the proposed changes, with at least two implementers participating and not objecting:
For browsers that are shipping the feature, implementation bugs are filed for the proposed changes (link to bug, or write "Not Implementing"):
Preview | Diff