Re: [w3c/editing] [Delayed Clipboard Rendering] What happens to the clipboard data on Tab/Browser Close? (Issue #424)

(TPAC meeting minutes)
Anupam: What happens to data if browser tab closes? Do we render before closing the tab? We discussed different options. We came up with hybrid of solution 2 and 4. Solution: one built-in format that has to be written to clipboard without delay. If a callback is already running, then we cancel it after timeout. Potentially put empty item into clipboard.
Johannes: Will not this create same issues as other solutions: User will get different results at different times without knowing why?
Anupam: This is only if the site has no beforeunload event handler. This is just fallback for that case. Website can show dialog: “You are losing clipboard formats if you close now…”
Olli: not blocking bf cache in any of the browsers
Anupam: Beforeunload event loader can choose one of 3: 
Show dialog with generic text about losing clipboard formats (text provided by browser). 
Render clipboard formats
Not do anything
RESOLUTION: Microsoft will prototype this solution. It seems to answer all concerns. Will revisit when prototype is ready.
Proposed solution:

> 
> We want to discuss the options listed in the above document, but want to propose the following option which is sort of a hybrid of options 2 and 4:
> 
> 1. At least one built-in format must be written to the clipboard without delay as part of the write operation so there will be some data on the clipboard (could be a low fidelity `text/plain` format) if the browser/tab closes and the site doesn't get a chance to generate the data for the delay rendered formats within the timeout window. If the site only writes one format to the clipboard, then it can't be delay rendered.
> 2. If a delay rendered callback is already running before the page unloads, cancel the callback after a timeout period if the callback hasn't completed yet. When the callback is cancelled, set empty data to the clipboard for that delay rendered format.

@evanstade @inexorabletash agreed that this solution is better than what was proposed in the document, so we are going to resolve this issue with this resolution and will revisit if we find any issues in the future.
@sanketj FYI..




-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/424#issuecomment-1719922235
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/424/1719922235@github.com>