XPost: alt.comp.software.firefox, comp.sys.mac.system   
   From: mariasophia@comprehension.com   
      
   Paul wrote:   
   > On Fri, 2/13/2026 6:32 AM, Carlos E. R. wrote:   
   >> On 2026-02-13 12:19, R Daneel Olivaw wrote:   
   >>> Carlos E. R. wrote:   
   >>>> On 2026-02-12 21:26, Maria Sophia wrote:   
   >>>>> 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.   
   >>>>   
   >>>> How do you propose we test this in Linux? There is no notepad++.   
   > Now, most of the time, Google doesn't give me these,   
   > so this was unexpected :-) All I had done is asked   
   > for "notepad++ for linux" and it trotted this out.   
   >   
   > AI Overview   
   > Notepad++ is not natively available for Linux, but it can be run efficiently   
   > using the Snap package manager (via Wine) or through alternatives that mimic   
   its functionality.   
   > The most direct method is installing the Snap package , which provides a   
   functional version   
   > of the application.   
      
   Hi Paul,   
      
   Thanks for always being helpful and kind, as I strive to emulate you.   
   The problem, as far as I am aware, is not tied to Windows or Notepad++.   
      
   I apologize if I wasn't clear in the original post of this PSA that I   
   believe the problem lies in the underlying design which prevails in all   
   operating systems, particularly when contrasting Firefox with Chromium.   
      
   It comes from how Chromium and Firefox generate clipboard data, and that   
   behavior is the same on Linux, macOS and Windows as far as I'm aware.   
      
   Hence, the editor only exposes the issue.   
   The editor does not create it.   
      
   On Linux, the clipboard is handled by the display protocol. That means   
   X11 or Wayland. Chromium, Firefox and every other graphical program talk   
   to the clipboard through whichever protocol the desktop is using.   
      
   1. On X11, the clipboard is based on selection ownership.   
      The program that owns the selection must stay alive, and the   
      clipboard contents are provided on demand when another program   
      requests a specific MIME type.   
      
   2. On Wayland, the clipboard is more structured. Programs advertise the   
      MIME types they can provide, and the compositor mediates access.   
      
   In both cases, Chromium always advertises multiple MIME types, including   
   text/plain and text/html. The contrast I'm trying to help explain to this   
   newsgroup is that Firefox often advertises only text/plain unless   
   the selection contains real markup.   
      
   That difference is the root cause of the odd behavior I saw on Windows.   
      
   Some Linux editors prefer text/html when it is available. Others ignore   
   it and take only text/plain. When an editor chooses the HTML version,   
   even if the visible text looks identical, the internal buffer can contain   
   fragment markers or offsets that affect selection, cursor movement or   
   macro behavior.   
      
   That is the same class of invisible land mine that showed up in Notepad++   
   on Windows.   
      
   Below is a simple Linux testing sequence that might reproduce the issue.   
      
   1. Install xclip if needed.   
      sudo apt-get install xclip   
      
   2. In Chromium, copy a paragraph of plain looking text from any web page.   
      
   3. Inspect the clipboard targets.   
      xclip -selection clipboard -t TARGETS -o   
      
      We should see text/html and text/plain among the entries.   
      
   4. Inspect the HTML version.   
      xclip -selection clipboard -t text/html -o   
      
      We should see HTML markup even if the selection looked plain.   
      
   5. Inspect the plain text version.   
      xclip -selection clipboard -t text/plain -o   
      
   6. Repeat steps 2 through 5 using Firefox instead of Chromium.   
      Note that Firefox often omits text/html for simple selections.   
      
   7. Paste the Chromium sourced text into several editors:   
      A. gedit   
      B. Kate   
      C. GVim   
      D. Geany   
      
      Then test:   
      a. Ctrl+A   
      b. Mouse sweep selection   
      c. Any macro or command that assumes a clean plain text buffer   
      
      If an editor behaves oddly only when the source is Chromium, that   
      confirms the HTML fragment is influencing the paste.   
      
   8. Paste the Firefox sourced text into the same editors and repeat the   
      same tests. If the odd behavior disappears, that isolates the cause.   
      
   This sequence is intended to show that the issue is not about Notepad++ or   
   Windows. It is about Chromium always providing HTML fragments that Firefox   
   does not produce, and about editors that change behavior when HTML is   
   present on the clipboard even when the user sees only plain text.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)