Ancestors

Written by abadidea on 2025-01-28 at 11:08

Turns out that if you copy text from OneNote and paste it into something that can accept either text or images, it decides you must want a bitmap rendering of your text. I pasted the text into this posting box and got the image, then pasted it again into the image's alt text and got text. Incredible. 0/10 ux, principle of least astonishment maximally violated

=> View attached media

=> More informations about this toot | More toots from 0xabad1dea@infosec.exchange

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-28 at 12:28

@0xabad1dea The annoying thing is, I can see how this happens:

When you copy, an app chooses a set of things that it can provide and sends a copy of the data to the clipboard in each of these formats. When you paste, the target app just sees a list of available types and has to choose one. It can't differentiate between these two cases:

Normally, an app will provide plain text and rich text, so that you can paste and lose style into things that can't handle rich text (note: the lack of a decent standard rich text view on Windows is part of the reason this tends to be terrible on Windows: macOS's NSTextView can serialise things in such a way that anything else that uses them can deserialise and most things on macOS use this because it's secretly a rich DTP system masquerading as a text field).

If OneNote provides text and image, because it uses some internal weird hybrid HTMLish format for rich text that it can't usefully export, then you'd see image and text as the types and most things would choose image.

Interestingly, on macOS it appears that OneNote copies only plain text, not rich text or an image.

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Written by abadidea on 2025-01-28 at 12:30

@david_chisnall for the record I am on osx, but pasting into web apps in Chrome, which may be relevant.

=> More informations about this toot | More toots from 0xabad1dea@infosec.exchange

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-28 at 12:45

@0xabad1dea Huh.

This made me curious so I dug out some sample code I wrote ages ago for a Cocoa book to see what types are actually present. It looks like it provides a lot:

com.microsoft.OneNote-2016-Internal

public.html

Apple HTML pasteboard type

public.png

Apple PNG pasteboard type

public.utf16-plain-text

CorePasteboardFlavorType 0x75747874

public.utf8-plain-text

NSStringPboardType

com.apple.webarchive

Apple Web Archive pasteboard type

public.rtf

NeXT Rich Text Format v1.0 pasteboard type

public.utf16-external-plain-text

CorePasteboardFlavorType 0x75743136

com.microsoft.ole.source.34152.0x6000012d30c0

com.microsoft.DataObject

com.microsoft.appbundleid

public.tiff

NeXT TIFF v4.0 pasteboard type

I think the sender provides them in order of preference, so the top one is for pasting from OneNote to OneNote (which is always OneNose in my head) and probably just contains the location in memory of the thing. But then the next two are HTML, then PNG. My guess is that the web apps, for some reason, don't support pasting HTML? The PNG is the next in order, with UTF-16 and UTF-8 text after that.

This order does seem kind-of sensible. If it's mostly HTML internally (it is an Electron app, I believe, or at least some kind of embedded WebView app), that's the highest priority, then the PNG will have higher visual fidelity than plain text and then plain text as the fallback.

But I don't know why a Chrome thing wouldn't choose to paste HTML, given the choice.

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Written by John Philip Bell on 2025-01-28 at 13:50

@david_chisnall @0xabad1dea

Yeah, I was going to point out the selected 'type' of the data (of the source app's 1..n offered flavors) is up to the receiving application, I've been a Windows developer since the 3.1 days... Unless something changed or I've forgotten, I don't even think the source application knows what applications are consuming clipboard data. 🤔 (I think DDE did, but... the mind plays tricks after all these years)

(nice explanation/write-up @david_chisnall)

=> More informations about this toot | More toots from john_philip_bell@defcon.social

Toot

Written by David Chisnall (Now with 50% more sarcasm!) on 2025-01-28 at 13:59

@john_philip_bell @0xabad1dea This is one of the mistakes the Wayland folks made (I think it might be fixed in later versions?): they made drag and drop behave like copy and paste. With the latter, there's a potentially long time between the copy and the paste and the source can go away in the middle. This removes the opportunity for content negotiation and means copy can be a fairly high-latency operation because you need to provide all possible useful encodings.

With drag and drop, you want the drag to start immediately, but then at drop time you have a live channel between sender and receiver, so can do content negotiation and encode only the desired format. Latency at drop time is much more acceptable to users than latency at drag time.

DDE was more exciting because it created a live channel between sender and receiver and so both were able to edit the same underlying object. Few things used it well.

=> More informations about this toot | More toots from david_chisnall@infosec.exchange

Descendants