Meeting minutes
Announcements?
Next meeting will be at TPAC 2022 in Vancouver, on Thursday 15 September.
https://
I think we should extend our meeting to 2-3 hours instead of just one (at TPAC)
(heard support, no objections)
async clipboard read & race conditions
github: https://
snianu: we looking to figure out if the clipboard content changes between reading system clipboard and santization step... should we just return the content read from the clipboard, throw an error, or return empty clipboard.
… macOS, iOS have limits as noted by whsieh in the issue.
Travis: do you have a preference?
snianu: came up while working on image sanitization... encode/decode takes some time.
… when the author makes the read call, the user gave them permission.
… at that moment, the user is expecting the data in the clipboard.
… I think it makes sense to return the data (not throw)
… what if the user switches to another apps, puts something else on the clipboard?
… if the browser already read the data, then the clipboard content could have changed.
… currently (in chromium) plan is to return an empty image.
… we could also throw a data error.
Travis: interesting that the plan is to return an empty image.
… what to do with non-image cases?
whsieh: I think we should try to match behavior of other apps on the system (for copy/paste)
… this isn't a common scenario.
… might be able to craft an image to take a lot of time to decode and switch...
… in that sense, it probably affects images more than other types (like markup)
… Always possible to hold a clipboard item and re-read it over and over...
… wondering what web author expectation is?
… expect authors to be prepared to handle exceptions.
travis: returning old data (original data post processing) sounds good to me.
whsieh: Q: if the change occurs before the first raw clipboard read, then what happens?
snianu: In Chromium we read all the data at once... I see the issue because with delayed rendering, we don't want to do that...
whsieh: In a delayed world, might make sense to throw an error. Other actions might lead to unpredictable behavior (depending on whether you've read the raw data or not)
snianu: Sounds good.
smaug: There's always a possibility of a race condition.
snianu: So, will resolve to throw an error in this case.
whsieh: Might be interesting to test this for interop as well.
… having the platform stomp over the clipboard content.
… we should continue thinking about that.
Should reading clipboard throw or return empty?
github: https://
snianu: Seems like a similar issue to 180.
… if there's no HTML format in the clipboard, and the author tries to read HTML format, then what?
… makes sense to throw a DataError.
… even though the clipboard has some data, just not what is desired.
snianu: If authors are trying to read HTML, but the clipboard has something that's not in the supported types.
… the clipboard item won't have any data.
whsieh: interesting to note: clipboard being empty is a valid system state.
… ex: calling clear contents from the OS. The technical truth is that there are no items in the clipboard.
… how would authors use this knowledge?
… (trying to come up with a scenario)
… I guess it makes sense (either way we go) to have some consistency.
snianu: Currently we throw DataError in Chromium. So does Firefox.
whsieh: Pretty sure Webkit will return an empty array of items.
… I think we can adjust our behavior to match; a DataError seems pretty sensible.
reviewing any other clipboard-api issues?
snianu: found a bunch of presumably duplicate items.
… many issue are looking for a way to discover supported types. Adding an API for this could help resolve many of those.
Selection API for Shadow DOM
github: https://
masonf: Hi folks! I'm masonf, TL at Google.
<masonf> https://
masonf: (presenting slides)
… Selection API has no idea about ShadowDOM. Things don't work so well when selection crosses the boundary.
… window.getSelection does different things depending on browsers, and things are somewhat inconsistent.
… we need to add some info to selection API so it knows what to do in these cases.
… note: getRangeAt returns a Range which has to be in one tree.
… BTW, had a big discussion on this last year. TAG reviewed and was OK with it.
… Proposal: new API getComposedRange.
… returns a StaticRange.
… takes options: list of shadow roots
… (so that it knows that the author knows about them)
… another option: selection root. (Enables easy to scope scenarios)
… Proposal pt. 2. Other stuff in the Selection API that needs to be rationalized with the new changes.
… define a "true range". Platform will know the real end-points, and can adapt what it returns to conform.
… other APIs (setBaseAndExtent) can be adjusted to accept Nodes from different trees.
… (we hope that will be web-compatible)
… Presentation includes a few follow-up links at the end.
Travis: what is desired from this group?
masonf: Editing WG has lots of good knowledge here. Would love your feedback.
… chromium is interested in implementing.
… also, if we have volunteers to write PRs, that would be awesome.
whsieh: The selection root, is it a convenience?
masonf: Yes, essentially.
… must pass in (at least) your own ShadowRoot. But also, you may want to "chop off" parts of the range out of your component. So it can handle both cases.
whsieh: Selection is scoped to editable regions (when it starts in an editing range)...
masonf: I believe "it depends".
whsieh: Silly little demo: http://
… can't seem to make the selection cross boundaries.
Megan: can select outside-in, but not vice-versa.
smaug: In Firefox, highlight can be partial.
snianu: Isn't that a problem with execCommands?
… e.g., delete? I guess there must be smarts to find the deletable content.
smaug: How does that work in other browsers?
snianu: Just the whole editing sub-component is selected (no partial selection inside) so we side-step the problem.
… behavior was different in old Edge/IE
… (Travis didn't catch the full details)
… the algorithm for adjusting the DOM is complicated.
whsieh: if selection contains any non-editable ranges, then the entire thing is non-editable (presumed Firefox behavior).
masonf: So is the implication that the selection root isn't necessary because it doesn't happen in practice?
whsieh: The case for scoping to editable roots is a less interesting case (because all browsers already do that). There are other use cases, perhaps, where it would be useful.
… e.g., scoping to certain regions in an editor?
Megan: Why StaticRange?
masonf: from my POV, it was "Live Ranges" are icky.
smaug: I don't think Live Ranges can have selections between different trees. This may be why.
masonf: Was looking for that, but didn't find that restriction..?
smaug: Well, Static Ranges may also be limited -- that part of the spec may have to change.
whsieh: Another motivator is Performance.
smaug: Depending on implementation, Perf may not be that significant (internal mechanism may not be able to avoid tracking logic used in live ranges)
whsieh: As the number of live regions scale up, you could be in perf trouble.
megan: anything we'll loose by not having live ranges?
masonf: TAG said let's deprecate the old getRangeAt... but there were some unique use cases that would be lost.
… we're not losing anything by having both.
masonf: Please file comments/feedback in the related issue (linked from the end of the slide).