| 15 | | * size limit: clipboard transfers are not rate-limited, so maybe we can re-use the file-transfer code for chunking them? or downsize the image if we find that the data is too big? |
| 16 | | * we don't test for the "png" clipboard feature in the browser, only for the new API availability - though in practice the end result is probably the same: trying to copy an image will fail but transferring an image as plain text is unlikely to be useful anyway |
| | 15 | * the copy is asynchronous and if you alt-tab away from the browser window quickly after copying the image, chrome will fail and complain that the document is not active (as a log message only..) |
| | 16 | * size limit: clipboard transfers are not rate-limited, so maybe we should re-use the file-transfer code for chunking them? or downsize the image if we find that the data is too big? (16MB is now the limit - which is pretty big for one packet!) |
| | 17 | * we don't test for the "png" clipboard feature in the browser, only for the new API availability - though in practice the end result is almost the same: if copying images is not supported then it will fail but transferring an image as plain text is unlikely to be useful anyway (ie: with eog, you get the file path as text, which is not useful) |
| | 18 | * some clipboard attributes should be refactored: #2370 |
| | 19 | * when sharing the same session with multiple clients, the type of data transferred for clipboard copying will change depending on what the client is capable of handling (should work - not tested) |
| | 20 | * could add "jpeg" support, looks like chrome has this already |
copyleft 2010 - 2021
