Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #146074 > unrolled thread

PSA: Clipboard differences between Chromium & Firefox across platforms

Back to article view | Back to comp.sys.mac.system

Contents

  PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-12 15:26 -0500
    Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 12:02 +0100
      Re: PSA: Clipboard differences between Chromium & Firefox across platforms R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> - 2026-02-13 12:19 +0100
        Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 12:32 +0100
          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Paul <nospam@needed.invalid> - 2026-02-13 08:42 -0500
            Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 13:37 -0500
              Re: PSA: Clipboard differences between Chromium & Firefox across platforms Paul <nospam@needed.invalid> - 2026-02-13 14:36 -0500
              Re: PSA: Clipboard differences between Chromium & Firefox across platforms onion@anon.invalid (Mr Ön!on) - 2026-02-13 19:37 +0000
                Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 15:17 -0500
                  Re: PSA: Clipboard differences between Chromium & Firefox across platforms onion@anon.invalid (Mr Ön!on) - 2026-02-13 21:21 +0000
                    Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 23:32 +0100
                      Re: PSA: Clipboard differences between Chromium & Firefox across platforms onion@anon.invalid (Mr Ön!on) - 2026-02-13 22:57 +0000
                      Ratcatcher/2.0.0.25 (was: Re: PSA: Clipboard differences between Chromium & Firefox across platforms) onion@anon.invalid (Mr Ön!on) - 2026-02-14 01:05 +0000
                      Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 00:26 -0500
              Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 21:07 +0100
                Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 15:29 -0500
                  Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 22:24 +0100
                    Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 01:52 -0500
                      Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-15 13:13 +0100
                        Re: PSA: Clipboard differences between Chromium & Firefox across platforms Paul <nospam@needed.invalid> - 2026-02-15 07:54 -0500
                          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-15 15:06 +0000
                          Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-15 19:43 +0100
                            Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 14:49 -0500
                              Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-15 22:04 +0100
                                Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 22:30 -0500
                          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 14:59 -0500
                          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-15 20:11 +0000
                            Re: PSA: Clipboard differences between Chromium & Firefox across platforms Paul <nospam@needed.invalid> - 2026-02-15 17:13 -0500
                              Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-15 23:33 +0000
                                Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 21:58 -0500
                                  Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-16 03:11 +0000
                                    Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 22:44 -0500
                            Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 20:43 -0500
                              Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 21:01 -0500
                                Re: PSA: Clipboard differences between Chromium & Firefox across platforms vallor <vallor@vallor.earth> - 2026-02-16 03:15 +0000
                        Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 14:37 -0500
                          Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-15 22:08 +0100
                            Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 22:53 -0500
              Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-14 00:39 +0000
                Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 02:16 -0500
            Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 22:07 +0100
              Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 17:19 -0500
        Re: PSA: Clipboard differences between Chromium & Firefox across platforms Jim Jackson <jj@franjam.org.uk> - 2026-02-13 17:17 +0000
          Re: PSA: Clipboard differences between Chromium & Firefox across platforms R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> - 2026-02-13 18:35 +0100
            Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 13:14 -0500
          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-14 00:34 +0000
          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Paul <nospam@needed.invalid> - 2026-02-14 09:22 -0500
      Re: PSA: Clipboard differences between Chromium & Firefox across platforms Frank Miller <miller@posteo.ee> - 2026-02-13 15:59 +0100
        Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 13:25 -0500
      Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 13:12 -0500
        Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 21:13 +0100
          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 16:01 -0500
            Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 22:31 +0100
            Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-14 00:33 +0000
              Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 00:41 -0500
          Re: PSA: Clipboard differences between Chromium & Firefox across platforms Your Name <YourName@YourISP.com> - 2026-02-14 10:31 +1300
            Re: PSA: Clipboard differences between Chromium & Firefox across platforms "Carlos E. R." <robin_listas@es.invalid> - 2026-02-13 22:57 +0100
      Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-13 13:12 -0500
    Re: PSA: Clipboard differences between Chromium & Firefox across platforms Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-13 23:17 +0000
      Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 01:14 -0500
        Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-15 21:29 -0500
    Re: PSA: Clipboard differences between Chromium & Firefox across platforms Maria Sophia <mariasophia@comprehension.com> - 2026-02-16 03:15 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#146095

On 2026-02-13 14:42, 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++.
>>>>
>>>> ...
>>>>
>>>
>>> Wine?
>>
>> Not going to happen. I have many nice editors native to Linux, no reason to use a foreign editor.
>>
>> If Arlen says that this may be an issue outside of Windows, he must have in mind that we test with some native editor. Name which, name what webpage to test with and paste from.
>>
> 
> 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.
> 
> Key Methods to Use Notepad++ on Linux:
> 
>      Snap Package (Recommended): This is the easiest, most stable method that
>      bundles Wine to run the Windows app seamlessly.

I understand this is a sort of package that bundles both wine and 
Notepad++? Thus the size will be huge, on disk and on RAM.

> 
>      Command: . <=== AI flubs it     snap search  notepad-plus-plus
>                                      snap install notepad-plus-plus (uses wine-platform-runtime-core22)
>      Wine: For advanced users, you can manually install Wine and use it to run the  installer.
> 
> Popular Native Linux Alternatives:
> 
>      If a native application is preferred over a Wine-based one, consider these alternatives:
> 
>      Notepad Next: A re-implementation of Notepad++ designed for Linux.
>      Notepadqq: A close, native clone of Notepad++.
>      Kate or Geany: Highly polished native editors.
>      Sublime Text: A powerful, fast, cross-platform alternative.
> 

Cross platforms alternatives are something to consider, if one is to 
learn a new editor.

> Using the Snap package is generally recommended because it provides a pre-configured Wine environment.
> 
> *******
> 
>     [Picture]  Use "Download Original" to exit the advertising-heavy page
> 
>      https://i.postimg.cc/mkZJG76Q/notepad-plus-plus.png
> 
> That's it running. Can't do anything there, until "the updates are finished".
> 
>      Paul


-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#146101

Carlos E. R. wrote:
> Cross platforms alternatives are something to consider, if one is to 
> learn a new editor.

That's the beauty of vi since we learned it decades ago and our fingers
know it better than our mind does at this point, and it works on all
platforms (yes, even on Android although the "escape" part is a PITA).

For me, I only use Notepad++ to normalize web page copies from various
sources so that the punctuation is consistent, as I don't edit with it.

If I was a kid starting out today though, I probably wouldn't pick vi.
But, I'll go to my grave using vi since it's what I learned decades ago.

Note: I've tested every free Android text editor ever suggested on the
Android newsgroup and decided early on that vi was not a keeper at all. :)

[toc] | [prev] | [next] | [standalone]

#146081

On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> 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++.
>> 
>> ...
>> 
>
> Wine?

Youy mean it can be done if we get drunk?

[toc] | [prev] | [next] | [standalone]

#146082

Jim Jackson wrote:
> On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> 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++.
>>>
>>> ...
>>>
>>
>> Wine?
> 
> Youy mean it can be done if we get drunk?
> 

https://www.winehq.org/

[toc] | [prev] | [next] | [standalone]

#146085

R Daneel Olivaw wrote:
> Jim Jackson wrote:
>> On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> 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++.
>>>>
>>>> ...
>>>>
>>>
>>> Wine?
>> 
>> Youy mean it can be done if we get drunk?
>> 
> 
> https://www.winehq.org/

Wine and Notepad++ are red herrings for the Linux newsgroup, but the
problem is the same so I apologize if I didn't make the main point clear.

Linux itself does not define how the clipboard works. The clipboard
behavior depends on the display system in use, which is either X11 or
Wayland on most desktops.

Chromium and Firefox both sit on top of that display system. They each
have their own clipboard pipeline, which decides what formats to put on
the clipboard when we copy from a web page.

The key point is that Chromium always puts multiple formats on the
clipboard, including HTML, while Firefox is more conservative and often
puts only plain text. That design difference exists on all platforms,
including Linux.

When we copy from Chromium, on any platform, it typically offers several
formats at once, such as
1. text/plain
2. text/html
3. text/html fragment or internal HTML types
4. sometimes image types
5. sometimes internal or custom MIME types

This pattern is the same idea on Windows, macOS, Linux on X11, and Linux
on Wayland. The exact API calls differ, but the design is the same.

Chromium always serializes the selection as plain text and as HTML, even
when the user does not see obvious formatting.

That is the source of the invisible land mine the PSA describes in the OP.

The HTML fragment is present even when we think we are copying only simple
text.

Since this is a Mozilla group, let's contrast with how Firefox behaves.

Firefox uses a more conservative clipboard pipeline than Chromium.
Thank God.

Firefox tends to emit plain text only, unless the selection actually
contains markup that Firefox considers meaningful.

So I agree with you that in many cases, copying from Firefox produces only
a plain text clipboard entry. That makes the plain text stream simpler and
more predictable for editors on all platforms, not just Windows. 

This is why I did not see the same problem when copying from Firefox. 
The HTML fragment was simply not there most of the time.

On X11, the clipboard is implemented using the X11 selection model.

1. The application that owns the selection keeps the data.
2. When another application pastes, it asks the owner for data in a
   specific format.
3. The owner responds with data in that format, if it supports it.

Chromium on X11 advertises multiple MIME types, such as text plain and
text html. Different Linux/Windows/macOS editors make different choices
about which format to request.

Some editors request only text plain. Some request text html first. 
Some request both, then apply their own rules to decide which one to use.

Because Chromium always offers HTML as well as plain text, an editor on
X11 can end up using the HTML based representation, or can parse the
plain text differently because HTML is also present. That can trigger
odd behavior, even though nothing visible appears in the pasted text.

So on X11, the same Chromium design can cause different symptoms in
different editors, depending on how they negotiate clipboard formats.

By way of conrast, Wayland uses a more structured clipboard protocol.

1. Applications explicitly declare which MIME types they offer.
2. The compositor mediates clipboard access.
3. Only the active paste target can request clipboard data.

Chromium on Wayland still offers multiple formats, including text plain
and text html. Editors on Wayland still choose which format to request.

The stricter protocol can avoid some of the older X11 quirks, but it
does not change the basic fact that Chromium always provides HTML along
with plain text. 

Any editor that prefers HTML on any platform, or that treats plain text
differently when HTML is present, can still show this surprising behavior.

So the same invisible land mine can exist on Wayland, although the exact
symptoms may differ from X11.

The point of the OP is that this issue is not a Windows-only problem

Certainly I have observed the issue on Windows with Notepad++, where
Control+A stopped working after pasting from Chromium. The root
cause, however, is not specific to Windows nor to Notepad++.

The root cause is that Chromium always places multiple formats on the
clipboard, including HTML fragments, while Firefox often does not. 

That's the whole point of this PSA.

Any editor on any platform that reacts badly to the presence of HTML, or
that parses the plain text stream in a strict way when HTML is also
present, can be tripped up.

On Linux, we do not need Notepad++ to see this. 

We can see similar effects in other editors, for example GVim, Kate, or
various GTK or Qt based editors, depending on how they choose clipboard
formats and how they parse the plain text stream when HTML is also present.

So to answer your question keeping on topic for this PSA warning... 

1. Chromium always offers HTML plus plain text on all platforms.
2. Firefox often offers only plain text, unless HTML is clearly needed.
3. X11 uses an older, flexible selection model, so editor behavior can
   vary widely.
4. Wayland uses a newer, stricter protocol, but editors still choose
   which MIME type to request.

The design difference between Chromium and Firefox is the main reason
for the invisible land mine. X11 and Wayland mainly change how that
difference shows up in practice, not whether it exists.

This was not intended to be a Linux-only PSA but a practical takeaway for
Linux users is if we see strange paste behavior in a Linux editor,
especially when copying from Chromium based browsers, it is reasonable to
suspect that the editor may be reacting to multiple clipboard formats, not
just to plain text. 

Just knowing this can be a possibility is like a TSB for a mechanic.

This newsgroup is involved because copying the same content from Firefox
can be a useful comparison test, because Firefox often omits HTML when it
is not needed. 

If the problem disappears when copying from Firefox, that supports the idea
that the extra HTML fragment from Chromium is involved. 

In summary, the answer to your question is the same pattern I saw on
Windows & the same underlying design applies on Linux, both on X11 and on
Waylan (as far as I am aware).
-- 
Had I known how it works, I would have written up a tutorial instead since
I'm a rare breed of person who delights in edifying everyone around me.

[toc] | [prev] | [next] | [standalone]

#146106

On Fri, 13 Feb 2026 17:17:53 -0000 (UTC), Jim Jackson wrote:

> On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> wrote:
>>
>> Wine?
> 
> Youy mean it can be done if we get drunk?

“What’s wrong with being drunk?”

“Ask a glass of water.”

[toc] | [prev] | [next] | [standalone]

#146109

On Fri, 2/13/2026 12:17 PM, Jim Jackson wrote:
> On 2026-02-13, R Daneel Olivaw <Danni@hyperspace.vogon.gov.invalid> 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++.
>>>
>>> ...
>>>
>>
>> Wine?
> 
> Youy mean it can be done if we get drunk?
> 

I don't think mixing WINE with Wine is a good
idea, as WINE constitutes "heavy machinery". But
in this particular case, all the ("SNAP") preparation was
done by someone sober. It's actually two wrongs
to make a thing, SNAP+WINE=Notepad++

   Paul

[toc] | [prev] | [next] | [standalone]

#146080

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++.

Not at all. Just forget it. ;-)

[toc] | [prev] | [next] | [standalone]

#146086

Frank Miller 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++.
> 
> Not at all. Just forget it. ;-)

I had thought the data in the PSA was clear, but apparently it was not.

That's my mistake for not explaining why all operating systems are affected
(AFAICT) since we do not need Notepad++ at all to reproduce underlying
browser design on Linux as the browser-to-clipboard-to-editor behavior
being described is not Windows-specific. All platforms deal with it.

The problem is a mix of operating system quirks (clipboard specific), and
the differences between how browsers and editors work with copy & paste.

As far as I'm aware, but I could be wrong, Chromium's multi-format
clipboard serialization (plain text + HTML + internal formats) happens on
all platforms, including Linux under both X11 and Wayland.

Hence the Chromium vs. Firefox clipboard behavior I saw on Windows, AFAIK,
does carry over to Linux, but X11 and Wayland handle clipboards very
differently, so the effects of Chromium's multi-format clipboard can vary
depending on which display system the user is running and which editor.

Let me work on a test protocol for Linux since I no longer dual boot even
as I see a grub screen every day when I boot my Windows-only old desktop.
-- 
My PC used to be Windows:Redhat, then Windows:Centos, then Windows:Ubuntu
but now it's just Windows because I've long ago ported over my Linux tools.

[toc] | [prev] | [next] | [standalone]

#146083

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?

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.
-- 
When people throw obstacles into the path of testing, it means that they 
never understood the premise in the first place, as it can be tested.

[toc] | [prev] | [next] | [standalone]

#146091

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.

-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#146094

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.

[toc] | [prev] | [next] | [standalone]

#146098

On 2026-02-13 22:01, Maria Sophia wrote:
> Carlos E. R. wrote:
>> On 2026-02-13 19:12, Maria Sophia wrote:
>>> Carlos E. R. wrote:

...

> 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.

Yes, I pasted into Kate, from both browsers, and ctrl-A works fine.


> 
> 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.
> 

Kate is a plain text editor, so it chooses the plain text part. LO lets 
me choose (with shift-^V)



> 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.


-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#146105

On Fri, 13 Feb 2026 16:01:16 -0500, Maria Sophia wrote:

> 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.

I wonder what you mean by “consumer platforms” ... ?

[toc] | [prev] | [next] | [standalone]

#146111

Lawrence D'Oliveiro wrote:
>> 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.
> 
> I wonder what you mean by "consumer platforms" ... ?

Hi Lawrence, 

That's a fair-enough question for us to ponder... where I mostly had meant
the most common ecosystems owned by people like us that run FF & Chrome.

Such as Linux, Windows, macOS, Android, iOS/iPadOS.

Although, technically, neither Firefox nor Chromium actually run on iOS or
iPadOS due to Apple's WebKit requirement, so they're really just paint-like
meaningless skins over Safari's engine rather than true Gecko or Blink.

That's why iOS/iPadOS can never have the privacy of the real Tor browser.

To your point, though, since, for example, ChromeOS runs both Firefox &
Chromium natively (Firefox through the Linux subsystem, Chromium as the
system browser), it probably should also qualify as a consumer platform as
well. 

And if we broaden the definition even slightly, we can add the various BSDs
and even Illumos/Solaris derivatives, all of which have working ports of
Firefox and Chromium despite not being Linux at all.
-- 
If we think we understand something, we don't. But if we think we don't 
quite yet understand something, then we're just beginning to understand it.

[toc] | [prev] | [next] | [standalone]

#146099

On 2026-02-13 20:13:22 +0000, Carlos E. R. said:
> 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.

I have noticed a couple of small differences when using MacOS 10.13 / 
High Sierra versions of old Safari and current Firefox:

1.  Copying a link from a webpage.
    In Safari and then pasting it into any text-based app (TextEdit,
    Usenet messages, etc.), all you get is the on-page text of the
    link, not the actual http web link itself. Using Firefox pastes
    the http web link.

2.  When copying text from a webpage with an embedded YouTube video.
    In Safari, pasting the text into a text-based app give the HTML
    code for the video with the video's web address. Using Firefox
    just results in some error text about JavaScript where the video
    should be.

I only ever use Chrome for the very very occasional websites that won't 
work in Safari or Firefox - usually awful Government-based ones where 
they still think everybody uses Windoze - so never bothered to see what 
that does in these two cases.



>> 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.

[toc] | [prev] | [next] | [standalone]

#146100

On 2026-02-13 22:31, Your Name wrote:
> On 2026-02-13 20:13:22 +0000, Carlos E. R. said:
>> On 2026-02-13 19:12, Maria Sophia wrote:
>>> Carlos E. R. wrote:

...

>> I copy paste rich text from Firefox into editors without problems. I 
>> do not use Chrome, but I have it installed.
> 
> I have noticed a couple of small differences when using MacOS 10.13 / 
> High Sierra versions of old Safari and current Firefox:
> 
> 1.  Copying a link from a webpage.
>     In Safari and then pasting it into any text-based app (TextEdit,
>     Usenet messages, etc.), all you get is the on-page text of the
>     link, not the actual http web link itself. Using Firefox pastes
>     the http web link.

Which means that the conversion to plain text is done by the web 
browser, and both do differently.

When I paste a text including a link into Thunderbird mail editor in 
html mode, I get a working link if read in a complying html mail client. 
However, the sent mail contains two parts, one in html rich text, and 
one plain text. The text part contains both the name of the link and the 
URL inside parenthesis.


> 2.  When copying text from a webpage with an embedded YouTube video.
>     In Safari, pasting the text into a text-based app give the HTML
>     code for the video with the video's web address. Using Firefox
>     just results in some error text about JavaScript where the video
>     should be.
> 
> I only ever use Chrome for the very very occasional websites that won't 
> work in Safari or Firefox - usually awful Government-based ones where 
> they still think everybody uses Windoze - so never bothered to see what 
> that does in these two cases.

Heh, here most government sites try to be "accessible", so they work in 
FF. Specially tax sites: they make easy to pay. ;-)

Yesterday I had to renew the certificate used in FFx to identify and do 
taxes, or identify to the health site and get a printout of my 
medicines. The site included instructions and software for Windows, 
Linux, Apple. And Android, I think.

The problems are with some commercial sites.

-- 
Cheers,
        Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#146084

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?

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.
-- 
When people throw obstacles into the path of testing, it means that they 
never understood the premise in the first place, as it can be tested.

[toc] | [prev] | [next] | [standalone]

#146104

On Thu, 12 Feb 2026 15:26:32 -0500, Maria Sophia wrote:

> 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.

Do you have a tool for inspecting the clipboard contents? In
particular, listing the different formats in which the clipboard
contents are being offered? That might shed more light on what exactly
is going on.

Here are some examples from my Linux system.

* Copying some text from Emacs:

    ldo@theon:~> wl-paste -l
    GTK_TEXT_BUFFER_CONTENTS
    application/x-gtk-text-buffer-rich-text
    text/plain;charset=utf-8
    UTF8_STRING
    COMPOUND_TEXT
    TEXT
    text/plain
    STRING
    text/plain;charset=utf-8
    text/plain
    SAVE_TARGETS

* Copying some text from a web page in Firefox:

    ldo@theon:~> wl-paste -l
    text/html
    text/_moz_htmlcontext
    text/_moz_htmlinfo
    text/plain;charset=utf-8
    UTF8_STRING
    COMPOUND_TEXT
    TEXT
    text/plain
    STRING
    text/plain;charset=utf-8
    text/plain
    text/x-moz-url-priv
    SAVE_TARGETS

* Copying the same text from the same web page in Chromium:

    ldo@theon:~> wl-paste -l
    chromium/x-source-url
    text/html
    STRING
    TEXT
    UTF8_STRING
    text/plain
    text/plain;charset=utf-8
    chromium/x-internal-source-rfh-token
    text/plain;charset=utf-8

* Copying the above text from KDE Konsole:

    ldo@theon:~> wl-paste -l
    text/plain
    text/html
    text/plain;charset=utf-8

[toc] | [prev] | [next] | [standalone]

#146112

Lawrence D�Oliveiro wrote:
> Do you have a tool for inspecting the clipboard contents? In
> particular, listing the different formats in which the clipboard
> contents are being offered? That might shed more light on what exactly
> is going on.
> 
> Here are some examples from my Linux system.
> 
> * Copying some text from Emacs:
> 
>     ldo@theon:~> wl-paste -l
>     GTK_TEXT_BUFFER_CONTENTS
>     application/x-gtk-text-buffer-rich-text
>     text/plain;charset=utf-8
>     UTF8_STRING
>     COMPOUND_TEXT
>     TEXT
>     text/plain
>     STRING
>     text/plain;charset=utf-8
>     text/plain
>     SAVE_TARGETS
> 
> * Copying some text from a web page in Firefox:
> 
>     ldo@theon:~> wl-paste -l
>     text/html
>     text/_moz_htmlcontext
>     text/_moz_htmlinfo
>     text/plain;charset=utf-8
>     UTF8_STRING
>     COMPOUND_TEXT
>     TEXT
>     text/plain
>     STRING
>     text/plain;charset=utf-8
>     text/plain
>     text/x-moz-url-priv
>     SAVE_TARGETS
> 
> * Copying the same text from the same web page in Chromium:
> 
>     ldo@theon:~> wl-paste -l
>     chromium/x-source-url
>     text/html
>     STRING
>     TEXT
>     UTF8_STRING
>     text/plain
>     text/plain;charset=utf-8
>     chromium/x-internal-source-rfh-token
>     text/plain;charset=utf-8
> 
> * Copying the above text from KDE Konsole:
> 
>     ldo@theon:~> wl-paste -l
>     text/plain
>     text/html
>     text/plain;charset=utf-8

Hi Lawrence,

Wow. That was excellent detective work you just did for the team!
Thanks for taking the time to run all those Linux-based wl-paste tests.

Of all who posted, only you, Carlos, and I have been testing this and
reporting back what we've found, all of which confirms the basic premise.

Each section of your output helps confirm the pattern I was trying to
describe in the PSA and your suggestion for me to do the same resonated.

Your Emacs example shows a plain-text-oriented application offering a
large set of classic X11 and GTK text targets. That is the baseline
case, nothing surprising there.

Your Firefox example shows exactly what we had expected. Firefox adds the
_moz_htmlcontext and _moz_htmlinfo formats only when it believes the
selection contains meaningful structure. That matches what I intuitively
see on Windows, where Firefox emits HTML Format only when needed.

But I didn't have a clipboard inspector until I looked one up just now.
  <https://www.nirsoft.net/utils/inside_clipboard.html>
  <https://www.nirsoft.net/utils/insideclipboard.zip>
  Name: insideclipboard.zip
  Size: 42653 bytes (41 KiB)
  SHA256: 13E71984F63C0C50E7710B92505D0B5BF422CA5214B61EAF51E02CB8A4B63B7E
 
  Name: InsideClipboard.exe
  Size: 37376 bytes (36 KiB)
  SHA256: 89C7BF5136E5BC1572325197C97FEA33FBC9F106B04AA924BEB58B5A687D2DF7

  InsideClipboard v1.30 
  This utility works on any version of Windows, from Win XP to Win 11.
  "Each time that you copy something into the clipboard for pasting
  it into another application, the copied data is saved into multiple 
  formats. The main clipboard application of Windows only display the
  basic clipboard formats, like text and bitmaps, but doesn't display
  the list of all formats that are stored in the clipboard.
  InsideClipboard is a small utility that displays the binary content
  of all formats that are currently stored in the clipboard, and allow 
  you to save the content of specific format into a binary file."

The pot of gold on the other end of the rainbow though was your Chromium
example results where Chromium always emits text/html plus its own internal
chromium/x-* formats, even when the selection looks like plain text. 

That is the same behavior I ran into on Windows, where the HTML Fragment
block is always present and can influence how the plain text stream is
parsed by editors that do not expect it.

Your Konsole example shows a terminal that offers plain text first but
still includes text/html. That reinforces the assumption on my part that
the editor or application decides which format to request, and that the
presence of HTML can change how the paste is interpreted.

All of your Linux results line up with what I saw on Windows. The
difference is not the platform, it is the clipboard formats that
Chromium places on the clipboard (which differ from what FF places).

I will try the NirSoft InsideClipboard tool tomorrow so I can see the
Windows formats directly, the same way your wl-paste -l output shows
them on Linux. If you have a simple test procedure you want me to run
with InsideClipboard, let me know and I will follow it exactly.

Otherwise, off the cuff, what I think I may try is this procedure
which keeps the variables controlled so we can compare results.

1. Open a plain-looking web page in Firefox.
2. Select a short block of visible text, no images.
3. Press Ctrl+C.
4. Open InsideClipboard and note every format listed.
5. Save the list or take a screenshot for reference.

6. Repeat the same steps in Chromium:
   A. Same page.
   B. Same text selection.
   C. Press Ctrl+C.
   D. Open NirSoft InsideClipboard and note the formats.

7. Compare the two lists. The key question is whether Chromium
   always includes HTML Format and related offsets even when the
   selection looks like plain text, and whether Firefox omits
   HTML Format when it decides the selection has no structure.

8. If I want a third comparison, I can paste the same selection into
   Notepad++ and then check InsideClipboard again. I think the formats
   will disappear after the paste, which would confirm that the metadata
   never enters the file buffer (which is why Notepad++ hex editor never 
   saw anything).

If I follow these steps tomorrow, maybe can line up the Windows results
with the wl-paste output you showed on Linux.

Thanks again for running the detailed tests which prove what we've
experienced the hard way, and for suggesting I see a clipboard inspector.

Do you think this test will suffice to sync up with your efforts?
-- 
There are two kinds of people on Usenet, one of which can add value.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web