XPost: alt.comp.software.firefox, comp.sys.mac.system   
   From: mariasophia@comprehension.com   
      
   Carlos E. R. wrote:   
   > On 2026-02-13 19:12, Maria Sophia wrote:   
   >> Carlos E. R. wrote:   
   >>>> 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.   
   >>>   
   >>> How do you propose we test this in Linux? There is no notepad++.   
   >>   
   >> Hi Carlos,   
   >>   
   >> Thanks for asking, where I'll propose a test for Linux later, but first I   
   >> need you to understand that the problem exists across all platforms   
   >> (AFAIK).   
   >>   
   >> Reacting to a perceived incredularity on your part, I simply ask (a bit   
   >> snarkily in jest so as to bring the conversation back to where it belongs),   
   >> are we really prepared to claim that Linux users, who are those same people   
   >> who have approximately seventeen text editors installed before breakfast,   
   >> have never once copied any text from Firefox or Chromium and pasted it into   
   >> vi, vim, GVim, Kate, gedit, or any of the other editors that have existed   
   >> since the Pleistocene?   
   >   
   > I copy paste rich text from Firefox into editors without problems. I do   
   > not use Chrome, but I have it installed.   
   >   
   >>   
   >> Because the absence of native Notepad++ on Linux doesn't magically prevent   
   >> clipboard testing. The clipboard exists. Chromium exists. Firefox exists.   
   >> Editors exist.   
   >> The only missing ingredient would be the willingness to actually try it.   
   >>   
   >> If the question is whether the Chromium HTML-Fragment/StartHTML clipboard   
   >> quirk shows up on Linux, the answer depends entirely on whether the editor   
   >> in question reacts to the presence of HTML on the clipboard.   
   >> Some may. Some may not. That's the whole point of the PSA!   
   >>   
   >> To warn others that the behavior comes from the browser's clipboard   
   >> serialization, not from Windows, Notepad++, or any single platform.   
   >>   
   >> So yes, of course this can be tested on Linux. It always could.   
   >> The prerequisite is acknowledging that "Notepad++ doesn't run on Linux" is   
   >> not the airtight argument all the follow on posters seem to believe.   
   >   
   > I pasted an entire web page from Chrome into Kate and LO Write, with no   
   > perceived problems.   
      
      
   Hi Carlos,   
      
   Thanks for testing this on your side. Your results in Kate and LO Write   
   are useful because they show that not every Linux editor reacts the same   
   way to the clipboard formats that Chromium provides. That is exactly the   
   pattern I was trying to highlight in the PSA but I did a bad job of it.   
      
   I apologize for not being clear in the original post that this issue is due   
   to the way the browser interacts wth the clipboard with the editor only   
   being the last item in the chain, so results vary depending on $EDITOR.   
      
   The point of this PSA is about browsers, and the clipboard, and, eventually   
   the $EDITOR but it's not that every $EDITOR will show the fragment problem.   
      
   Given this is a set of operating system and Firefox newsgroups, the point   
   is that Chromium always places HTML on the clipboard along with plain text,   
   while Firefox often provides only plain text on all consumer platforms.   
      
   Some $EDITORS ignore the HTML, some prefer it, and some change behavior   
   when both formats are present. I don't know the list of who does what.   
      
   I was just warning people that the problem exists (on all platforms).   
      
   It bit me. Bad. I couldn't for the life of me figure out at first why only   
   Chromium pastes killed the "Control+A" selection while FF pastes did not.   
      
   Especially since the editor's hex mode shows absolutely nothing about it.   
      
   Your tests confirm that Kate and LO Write handle the Chromium clipboard   
   in a way that avoids the issue. That is good information for the group.   
   It also helps narrow down which editors might react differently.   
      
   Since you run Linux every day, your input is valuable here. You can help   
   the team by checking one small thing that keeps the test simple.   
      
   Here is a short test that keeps things simple.   
   1. Copy a short plain-looking paragraph in Firefox.   
   2. Paste it into any editor you prefer.   
   3. Press Control+A and confirm that full selection works.   
   4. Repeat the same steps using Chromium.   
   5. Compare only the behavior of the editor, not the formatting.   
      
   This keeps the test short and avoids long procedures, and it lets us see   
   whether the difference between Firefox and Chromium shows up in your own   
   Linux setup.   
      
   If both behave the same, that tells us the editor is choosing plain text.   
   If they differ, that suggests the editor is reacting to the HTML fragment   
   that Chromium always provides. This is the PSA that I'm warning folks of.   
      
   Note that Control+A is not a Windows feature.   
   It is an editor feature.   
   On Linux:   
    a. Kate supports Control+A   
    b. LO Write supports Control+A   
    c. GVim supports Control+A   
   But many terminal editors do not.   
      
   So the key point is that while Control+A works on Linux, the behavior after   
   a Chromium paste can differ depending on how the editor interprets the   
   clipboard formats.   
      
   Thanks again for checking this.   
   Your Linux results help complete the picture for everyone.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)