XPost: alt.comp.software.firefox, comp.sys.mac.system   
   From: mariasophia@comprehension.com   
      
   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.c   
   mp.microsoft.windows   
    Subject: PSA: HTML fragment mode interaction between Chromium, Clipboard &   
   Notepad++   
    Date: Tue, 10 Feb 2026 07:17:37 -0500   
    Message-ID: <10mf7l0$dbf$1@nnrp.usenet.blueworldhosting.com>   
      
   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.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)