Meeting minutes
feature detection for clipboard
github: https://
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://
Anupam: I think we need Bo for this.
Annevk: +1
clarification on pickling
github: https://
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://
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://
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://
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:
end
On TPAC: we need to prepare for a hybrid meeting regardless.
Regrets BoCupp