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

Hank Rogers wrote:
> I believe he is psychotic.

Privacy is always most deprecated by those who least understand it, but I
will continue to ignore the insults which took them 3 seconds to compose.
However, I would like to ask those who continue to post off topic trolls to
please summarize what the problem set is about in this thread topic so that
we can all be edified as to what they think of the proposed solution set.

Since I strive to add value in every post, even when responding to the
trolls, I wrote this to edify the Firefox group on all the major platforms,
while Hank and Carlos were spending about 3 seconds of their valuable time
composing off-topic trolls that have nothing to do with the topic.

I simply ask the trolls to respond to this post in an on-topic way 
that adds value (which means they need to invest their intelligence).

Newsgroups: alt.comp.software.firefox,comp.sys.mac.system,alt.os.linux
Subject: PSA: Clipboard differences between Chromium & Firefox across
platforms
Date: Thu, 12 Feb 2026 15:26:32 -0500
Organization: BWH Usenet Archive (https://usenet.blueworldhosting.com)
Message-ID: <[email protected]>

PSA: Clipboard differences between Chromium & Firefox across platforms

I do a lot of research as I generally invest at least an hour or two into
many of my Usenet opening posts, where I currently employ a thousand-line
Windows Notepad++ macro that beautifully cleans up non-ASCII garbage copied
from both Firefox and Chromium web output, where, only with Chromium pastes
into Notepad++ was the selection mechanism (i.e., Ctrl+A) inoperative.
 Newsgroups: alt.comp.os.windows-10,alt.comp.os.windows-11,alt.comp.microsoft.windows
 Subject: PSA: HTML fragment mode interaction between Chromium, Clipboard & Notepad++
 Date: Tue, 10 Feb 2026 07:17:37 -0500
 Message-ID: <[email protected]>

After much effort, I was able to resolve the problem in one programmed
stroke (as all my solutions are one-tap solutions) but what I wanted to
remind those on the Firefox newsgroup is WHY only Chromium. Not Firefox.

It goes under a bunch of names when I researched it, but they're the same.
1. The HTML Fragment Clipboard Format issue
2. The StartHTML offset bug
3. The Windows HTML Clipboard Format quirk
4. The Chromium HTML clipboard serialization problem
5. The multi-format clipboard mismatch issue
etc.

The HTML Fragment issue showed up for me on Windows when pasting into
Notepad++ from Chromium, but the underlying cause applies to all platforms
because it apparently comes from how Chromium generates clipboard data,,
which is DIFFERENT from how Firefox does the same copy/paste tasks.

Even as Firefox uses a different and more conservative clipboard path, the
problem seemed almost random because the editor is intimately involved.

The important point is that not all editors behave the same way when they
receive multiple clipboard formats. Some editors request only plain text
from clipboard pastes, while some request HTML Format, and some request
both and then choose one based on the editor's own internal rules. 

On Windows, Notepad++ requests the plain text stream, but the presence of
the HTML Fragment block can influence how the plain text stream is
generated or parsed.

Other editors on other platforms may ignore the HTML Fragment block or
may sanitize the plain text stream differently. This means the issue is
not tied to one editor. It depends on how each editor interacts with the
clipboard and how it handles the plain text stream when HTML Format is
also present. 

Unfortunately for me, Chromium always emits HTML Format, so any editor on
any platform that does not expect it or that parses the plain text stream
in a strict way can show the odd behavior which tripped up my one-tap
Unicode-to-ASCII conversion solutions. Copying from Firefox avoids this
because FF apparently emits HTML Format only when needed, so the plain text
stream is simpler and more predictable across editors and platforms.

That's why I didn't see this problem when I used Firefox for my researched
copy/pasting. Only a paste from Chromium browsers broke the Control+A key
press (which also broke the left-mouse-sweep selection workaround).

Specifically, since I edit in GVim but I convert Unicode-to-ASCII in
Notepad, this HTML Fragment issue showed up for me on Windows when pasting
into Notepad++, where NOTHING VISIBLE could be found for a land mine.

The land mine being invisible is important to note because I originally
went down character set and invisible character rat holes, but Notepad++'s
hex editor showed absolutely nothing there causing the problem.

It's an invisible land mine.

I'm writing this PSA to help others because the underlying cause applies to
all platforms (and some editors) because it comes from the design of the
Chromium clipboard pipeline, not only from Notepad++ or Windows alone.

To delve a bit deeper into the cause of this invisible land mine,
apparently Chromium always places multiple formats on the clipboard when we
copy from a web page. This includes plain text, HTML Format, and several
internal formats. The HTML Format block follows a Microsoft specification
that uses StartHTML, EndHTML, StartFragment, and EndFragment offsets to
mark the visible part of the selection. 

While I have not tested the other platforms, apparently Chromium does this
on all platforms because its selection code comes from the WebKit and Blink
model, which treats every selection as a range of DOM nodes that can be
serialized into both plain text and HTML.

Firefox takes a different approach. 

Mozilla's clipboard pipeline was apparently built around the Gecko editor
and it only emits HTML Format when the selection contains markup that
Firefox considers meaningful. In many cases Firefox emits only plain text. 
Perhaps this is why pasting from Firefox did not trigger the same behavior
that I saw when pasting from Chromium based browsers. 

The practical effect for users on all common consumer operating systems is
that Chromium produces HTML fragments far more often than Firefox does,
even when the user sees no visible formatting.

On Windows this can expose quirks in applications that do not expect
HTML Format or that handle the plain text stream differently when HTML
is also present. On Linux and macOS the details differ, but the general
pattern is the same because the behavior comes from Chromium, not from
the operating system.

This PSA is only a heads up. Firefox is not at fault here. It simply
uses a more conservative clipboard serializer. Chromium uses a richer
one. If you ever see odd paste behavior in a text editor, the difference
in clipboard formats may be the reason, which is why I wrote this up.

Had I known about this months ago, I wouldn't have had this problem that I
had to add an extra step of adding a blank line in every Chromium paste,
but I didn't have to add that blank line in every Firefox paste.

Adding a blank line, to me, is anathema, because it's an extra step.
I hate extra steps. I grew up in DEC/VAX/PDP11 days and I learned early on
when burning the 2Kbit EEPROMs for Motorola MC68701 micro controllers by
hex (not assembly, but hex) that everything can be halved in steps.

Unlike quantum physics though, I stop when I get it to be one step.

In short, the invisible land mine I hit came from the way Chromium
generates clipboard data differently than Firefox does. 

Chromium places multiple formats on the clipboard on all platforms, not
only on Windows. 

This behavior is part of the Chromium clipboard design itself. 

The exact formats differ by operating system because each OS has
its own clipboard API, but the pattern is the same. 

Chromium always serializes the selection into plain text, HTML Format, and
several internal formats. On Windows this shows up as CF_UNICODETEXT and
HTML Format with StartHTML and StartFragment offsets. On macOS it shows up
as NSPasteboard types for plain text and HTML. On Linux it shows up as
multiple MIME types on the X11 or Wayland clipboard. 

The important point is that Chromium always provides HTML along with plain
text, while Firefox provides HTML only when needed. This is why the issue
can appear on any platform that uses Chromium and any editor that reacts to
the presence of HTML on the clipboard.

The invisible land mine issue I had to solve yesterday comes from the
design of the Chromium clipboard pipeline, and any editor that handles the
plain text stream in a strict way can be tripped up by the extra HTML
Fragment data that Chromium always provides.

I hope this PSA saves you looking in all the wrong places when the solution
was as simple as automatically adding & deleting a space at the very
beginning of my thousand-line Notepad++ macro to normalize pasted text.

If this edifies you, then the time invested in writing it was worthwhile.
-- 
Had I known how it works, I would have written up a tutorial instead since
I'm a rare breed of person who delights in edifying everyone around me.