XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows   
   From: mariasophia@comprehension.com   
      
   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: <10mld1o$1910$1@nnrp.usenet.blueworldhosting.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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)