Web Editing WG Meeting March 10, 2022

10 March 2022


Alex Keng, annevk, Anupam, johanneswilm, Travis, whsieh

Meeting minutes

feature detection for clipboard

github: https://github.com/w3c/clipboard-apis/issues/170

snianu: Didn't have time to discuss internally; but authors should have an ability to get the available formats on the clipboard.
… not really sure if this is should be a new API or not.
… if the proposal sounds good to everyone then we don't have any objections.

johanneswilm: Will MS be able to take this up next month?

annevk: I was wondering what happens if you create a clipboard item for an unsupported format and try to write it?

snianu: chromium throws today.

annevk: Is that an OK single to know it isn't supported?

whsieh: I think that's right... If the author tries to write and it throws an exception...
… Trying types until it doesn't throw is the current approach.

Travis: maybe that's good enough, barring any other customer signal?

johanneswilm: Scenario: say I have a format that takes a lot of time to prepare for a test (say WebP conversion before clipboard test)
… if that's the case, then I understand why authors would like to know before doing all that work.
… did I understand that correctly?

Anupam: in chromium, that's the way it is.

<whsieh> those three are image/png, text/plain, and text/html I believe?

Anupam: there are some "manditory" formats that everyone supports.
… There are open questions about how some custom formats could become mandatory formats.
… suppose we could check for the prefix?

johanneswilm: Scenario: I create a JS-based image format, then browsers change what they support. When I export to the clipboard I will need to keep a list of what browsers support and export as needed.
… I might first try one that is accepted, then try again if it throws.

annevk: As I wrote... I think this does need addressing.
… if you wanted to write multiple at a time, you won't know which one wasn't supported.
… I think there is a real need for something like this.
… alternative is all browsers support the same formats.

whsieh: I think there is compelling need if some browsers will support new formats that others won't... but in the current climate, this isn't very pressing.
… Do agree, we should investigate this.
… This is just about writing to the clipboard. The term "supports" is a little vague... would like to see a name more accurately reflecting that it's about writing.
… I will bring it up with my peers.

johanneswilm: So we will want to hear from both Microsoft and Apple next meeting.

Annevk: on the name, I think "supports" is probably OK. Seems like the most prominent thing and there is precident.
… I think it's OK from that perspective.

Remove clipboard write permission?

github: https://github.com/w3c/clipboard-apis/pull/164

Anupam: I think we need Bo for this.

Annevk: +1

clarification on pickling

github: https://github.com/w3c/editing/issues/393

annevk: I haven't had time to look at this.

Anupam: opener hasn't responded to my comments.
… concerns about writing 1000 of formats. (I tested and it does indeed bog-down my computer.)
… I think a hundred is reasonable.
… Went through security review and they were OK with that.

Annevk: are you saying global total is 100?

Anupam: I think there may be a security problem on your hands...

(Sorry that comment was Annevk)

Anupam: new windows APIs have a global limit.

Anupam: So, attack vector is that two origins use different custom formats to communicate. (Similar to socket connections.)

Travis: can you explain the attack?

annevk: one origin takes all 100 formats, then another tries to use a custom format and is denied.
… Then the first origin can know which formats were attempted based on which ones had been added previously.

(editor's note: Sorry didn't capture that very well)

Annevk: suggests looking over: https://xsleaks.dev/

whsieh: Yep, this is why Webkit blocks cross-origin custom pasteboard access.

Travis: so some of us will need to revisit restrictions...?

Anupam: raising the limit to 16K is Windows' limit--that could be a problem.

annevk: you could add a limit-per-origin

<whsieh> platform info is in the UA already, no?

annevk: Each type that the origin uses adds a "salt" to add randomization to prevent the other origin from guessing.

+1 (I like that)

johanneswilm: This is just some advice to chromium folks.
… anything spec-wise?

Anupam: I think we need more discussion? Needs to be a limit and have it documented somewhere.

meeting times

github: https://github.com/w3c/editing/issues/359

johanneswilm: Masayuki could meet at other times...
… we would like to have more inclusion. We currently have N. America, Europe. Would like to include folks in Asia.
… last time we asked Masyuki if he wanted to attend--couldn't do it in 2021, want to check again.

Alex: I can contact Masayuki.

johanneswilm: great!

concern for screen reader users

github: https://github.com/w3c/virtual-keyboard/issues/15

johanneswilm: Last update: bo indicate no progress, will comeback next month? Can we discuss with without Bo present?

Travis: scanning the issue to try to understand.

Anupam: on iOS isn't the content overlaid?

whsieh: confirmed, yes that is what happens.

johanneswilm: on iOS/MacOS when a virtual keyboard is overlaying page content, does the screen reader treat the overlaid content as visible (e.g., "keyboard is visible"). Does Voiceover keep reading content underneath?

ACTION: whsieh to check with accessibility folks to see if screen readers continue reading content covered up by virtual keyboards? (Or similar overlays).

Travis: Had an opportunity to observe this behavior with screen reader users--it absolutely happens that screen readers keep reading what is underneath surprise popups (e.g., ads) that happen on popular pages all the time. (I'm not sure this is a new or unique problem.)

johanneswilm: was this what Bo was going to look into? Is this something the OS could address?

Anupam: not sure if the OS could address. In some cases OS is allowed to resize the content--other times, not so much.

johanneswilm: wondering is this is something that Firefox is concerned about?

annevk: I would suspect this would be resolved in the same way that IME resolves this issues.
… (IME for virtual keyboards). My brief assessment is that this should just fundamentally work.
… I think we should ask for more details.

ACTION: ask @becka11y to help clarify the scenario in light of other things that can be occluded for screen readers.

johanneswilm: And that was the last topic!

end topic:


On TPAC: we need to prepare for a hybrid meeting regardless.

Regrets BoCupp

Summary of action items

  1. whsieh to check with accessibility folks to see if screen readers continue reading content covered up by virtual keyboards? (Or similar overlays).
  2. ask @becka11y to help clarify the scenario in light of other things that can be occluded for screen readers.
Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).


Maybe present: Alex, snianu