Re: PSA: HTML fragment mode interaction between Chromium, Clipboard & Notepad++

The knowledgeable folks on the Linux newsgroup ran tests confirming this
PSA exactly (see Lawrence D'Oliveiro's tests I forwarded moments ago).

Since those on these Windows newsgroups might not be familiar with Linux, 
here is just my take on the confirmation that Lawrence kindly provided.

Lawrence D¢Oliveiro wrote:
> Do you have a tool for inspecting the clipboard contents? In
> particular, listing the different formats in which the clipboard
> contents are being offered? That might shed more light on what exactly
> is going on.
> 
> Here are some examples from my Linux system.
> 
> * Copying some text from Emacs:
> 
>     ldo@theon:~> wl-paste -l
>     GTK_TEXT_BUFFER_CONTENTS
>     application/x-gtk-text-buffer-rich-text
>     text/plain;charset=utf-8
>     UTF8_STRING
>     COMPOUND_TEXT
>     TEXT
>     text/plain
>     STRING
>     text/plain;charset=utf-8
>     text/plain
>     SAVE_TARGETS
> 
> * Copying some text from a web page in Firefox:
> 
>     ldo@theon:~> wl-paste -l
>     text/html
>     text/_moz_htmlcontext
>     text/_moz_htmlinfo
>     text/plain;charset=utf-8
>     UTF8_STRING
>     COMPOUND_TEXT
>     TEXT
>     text/plain
>     STRING
>     text/plain;charset=utf-8
>     text/plain
>     text/x-moz-url-priv
>     SAVE_TARGETS
> 
> * Copying the same text from the same web page in Chromium:
> 
>     ldo@theon:~> wl-paste -l
>     chromium/x-source-url
>     text/html
>     STRING
>     TEXT
>     UTF8_STRING
>     text/plain
>     text/plain;charset=utf-8
>     chromium/x-internal-source-rfh-token
>     text/plain;charset=utf-8
> 
> * Copying the above text from KDE Konsole:
> 
>     ldo@theon:~> wl-paste -l
>     text/plain
>     text/html
>     text/plain;charset=utf-8

Hi Lawrence,

Wow. That was excellent detective work you just did for the team!
Thanks for taking the time to run all those Linux-based wl-paste tests.

Of all who posted, only you, Carlos, and I have been testing this and
reporting back what we've found, all of which confirms the basic premise.

Each section of your output helps confirm the pattern I was trying to
describe in the PSA and your suggestion for me to do the same resonated.

Your Emacs example shows a plain-text-oriented application offering a
large set of classic X11 and GTK text targets. That is the baseline
case, nothing surprising there.

Your Firefox example shows exactly what we had expected. Firefox adds the
_moz_htmlcontext and _moz_htmlinfo formats only when it believes the
selection contains meaningful structure. That matches what I intuitively
see on Windows, where Firefox emits HTML Format only when needed.

But I didn't have a clipboard inspector until I looked one up just now.
  <https://www.nirsoft.net/utils/inside_clipboard.html>
  <https://www.nirsoft.net/utils/insideclipboard.zip>
  Name: insideclipboard.zip
  Size: 42653 bytes (41 KiB)
  SHA256: 13E71984F63C0C50E7710B92505D0B5BF422CA5214B61EAF51E02CB8A4B63B7E
 
  Name: InsideClipboard.exe
  Size: 37376 bytes (36 KiB)
  SHA256: 89C7BF5136E5BC1572325197C97FEA33FBC9F106B04AA924BEB58B5A687D2DF7

  InsideClipboard v1.30 
  This utility works on any version of Windows, from Win XP to Win 11.
  "Each time that you copy something into the clipboard for pasting
  it into another application, the copied data is saved into multiple 
  formats. The main clipboard application of Windows only display the
  basic clipboard formats, like text and bitmaps, but doesn't display
  the list of all formats that are stored in the clipboard.
  InsideClipboard is a small utility that displays the binary content
  of all formats that are currently stored in the clipboard, and allow 
  you to save the content of specific format into a binary file."

The pot of gold on the other end of the rainbow though was your Chromium
example results where Chromium always emits text/html plus its own internal
chromium/x-* formats, even when the selection looks like plain text. 

That is the same behavior I ran into on Windows, where the HTML Fragment
block is always present and can influence how the plain text stream is
parsed by editors that do not expect it.

Your Konsole example shows a terminal that offers plain text first but
still includes text/html. That reinforces the assumption on my part that
the editor or application decides which format to request, and that the
presence of HTML can change how the paste is interpreted.

All of your Linux results line up with what I saw on Windows. The
difference is not the platform, it is the clipboard formats that
Chromium places on the clipboard (which differ from what FF places).

I will try the NirSoft InsideClipboard tool tomorrow so I can see the
Windows formats directly, the same way your wl-paste -l output shows
them on Linux. If you have a simple test procedure you want me to run
with InsideClipboard, let me know and I will follow it exactly.

Otherwise, off the cuff, what I think I may try is this procedure
which keeps the variables controlled so we can compare results.

1. Open a plain-looking web page in Firefox.
2. Select a short block of visible text, no images.
3. Press Ctrl+C.
4. Open InsideClipboard and note every format listed.
5. Save the list or take a screenshot for reference.

6. Repeat the same steps in Chromium:
   A. Same page.
   B. Same text selection.
   C. Press Ctrl+C.
   D. Open NirSoft InsideClipboard and note the formats.

7. Compare the two lists. The key question is whether Chromium
   always includes HTML Format and related offsets even when the
   selection looks like plain text, and whether Firefox omits
   HTML Format when it decides the selection has no structure.

8. If I want a third comparison, I can paste the same selection into
   Notepad++ and then check InsideClipboard again. I think the formats
   will disappear after the paste, which would confirm that the metadata
   never enters the file buffer (which is why Notepad++ hex editor never 
   saw anything).

If I follow these steps tomorrow, maybe can line up the Windows results
with the wl-paste output you showed on Linux.

Thanks again for running the detailed tests which prove what we've
experienced the hard way, and for suggesting I see a clipboard inspector.

Do you think this test will suffice to sync up with your efforts?
-- 
There are two kinds of people on Usenet, one of which can add value.