XPost: alt.comp.software.firefox, comp.sys.mac.system   
   From: nospam@needed.invalid   
      
   On Fri, 2/13/2026 1:37 PM, Maria Sophia wrote:   
   > 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.   
      
   When I got Chromium installed, and I used the "clipboard" SNAP,   
   it was claiming only a text buffer was on the clipboard. As   
   near as I can determine. And my one sentence, copied OK into Notepad++   
   under WINE.   
      
   Linux has a pile of clipboard tools, and for the most part,   
   they are not forensic in nature, and you can't really be sure   
   they are showing the multiple clipboard entries that might or should   
   be there.   
      
   My only contribution here, is showing that there is "some" amount of   
   cross-platform, but not really enough for any "proof" type posts.   
   I got as far as being able to list what one tool claimed was   
   on the clipboard, and it didn't break when I pasted into a   
   WINE-supported application. That's going through a few "torturous paths"   
   as you can imagine. That's a hell of a lot more complexity than when we   
   were using clipboard managers on UNIX.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)