Add `unsanitized` option to async clipboard API.

[snianu]

Closes #????

For normative changes, the following tasks have been completed:

• [X] Modified Web platform tests (link to pull request) https://github.com/web-platform-tests/wpt/pull/35528

Implementation commitment:

• [ ] WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• [X] Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1268679)
• [X] Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1867331)

---

Preview | Diff

[snianu]

@evanstade Made spec changes for unsanitized option. Please let me know if you have any comments/concerns. Thanks!

[yisibl]

I would like the unsanitized option to be applied to image/svg+xml as well, which would solve the problem of losing <style> when copying SVG. See https://bugs.chromium.org/p/chromium/issues/detail?id=1226150

[snianu]

Tagging @EdgarChen in this PR as well. Could you please take a look if you are OK with this change? Thanks!

[snianu]

https://github.com/w3c/clipboard-apis/pull/197#discussion_r1378176413

Clarified in the latest iteration.

[snianu]

@evanstade I think the latest iteration addresses all your concerns, but please let me know if there is anything missing. I would like to restart the I2S process as I'm not receiving any response from Mozilla folks.

[snianu]

Landing this PR. Please let me know if you have any comments and I'll address it in separate PRs.

[zcorpan]

It looks like some of the checkboxes in the issue template weren't completed before merging. Was that intentional?

[snianu]

@zcorpan Sorry I created a new bug in Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1867331 Here is the request for position: https://chromestatus.com/feature/5192271976988672?gate=5118722541092864 For Webkit they weren't interested in this feature as their sanitization process in async clipboard APIs aligns with the DataTransfer APIs.

[saschanaz]

"Implementation commitment" doesn't sound like just filing bugs but more about implementation interest 🤔, in that sense I'm not sure the checkboxes are correct.

[snianu]

@saschanaz We have also filed a request for position: https://github.com/mozilla/standards-positions/issues/769

[saschanaz]

That's nice, but my understanding of commitment is that there at least should be some interest. Having a bug does not mean an interest, right?

[snianu]

@saschanaz right and in that case the bug can be resolved as "Won't fix" with a comment that the user agent is not interested in this feature, and the request for position should be marked accordingly.

[saschanaz]

Sure. What I feel off here is the checkbox for Gecko is filled, when there's no public implementation commitment from Gecko.

Edit: ... which means there should be only one filled checkbox for commitment, which should have blocked this PR from being merged I guess.

[snianu]

@saschanaz We can remove it from the spec if we only have one implementor interest, but waiting indefinitely for a signal is probably not the right way to decide whether there is interest from a particular browser. If the official stance of Firefox is negative, then please let me know and I can revert this PR and create another PR and mark it as BLOCKED. That way if Firefox or Webkit changes their stance and decide to support this feature in the future, we can unblock the PR and merge it.

[saschanaz]

I see your point, but then how are we going to track which part doesn't have implementer consensus and which part does? Having an open PR is easier for that and doing so automatically prevents any part of the spec without consensus from accidentally becoming CR.

[snianu]

Note that the IDL and the language in the algorithms already allow non-supporting implementors to be in compliant with the spec while also allowing implementors who are interested in the new feature. I don't see any parts in the PR that is contentious unless I'm missing something?

[saschanaz]

I'm talking about the general process rather than the PR itself. And also I don't think we'll want to add any kind of optional features without consensus, just because it's okay to not implement it.

[snianu]

And also I don't think we'll want to add any kind of optional features without consensus

We spent over two years trying to get consensus on this API, but we couldn't. Safari has clearly stated their position, so since you commented that you are not in favor of an optional parameter, should I mark Firefox's position as negative?

[saschanaz]

Our position will be announced in our standards-position issue probably by Edgar. I definitely see your frustration, but still I think merging PRs without consensus makes it hard to make sure every part of the spec has consensus (which is needed for recommendation track), and I see no benefits to merge it early.

[snianu]

@saschanaz Let's discuss this in the EditingWG meeting which is going to happen next Thursday. Without any clear stance on this API, it's hard to assume whether we have consensus or not. If you can officially state your position before that, we can definitely revert the PR, else, we will have to decide what to do with it in the EditingWG meeting where hopefully someone from Firefox can give us clear official stance on this issue. Thanks!