XPost: alt.comp.software.firefox, comp.sys.mac.system
From: mariasophia@comprehension.com
Lawrence D'Oliveiro wrote:
> On Fri, 13 Feb 2026 13:37:15 -0500, Maria Sophia wrote:
>
>> 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.
>
> ldo@theon:~> cat test.txt
> Hi there.
> ldo@theon:~> firefox test.txt
> [in Firefox, do Select All and Copy.]
>
> [back in a terminal session:]
> 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
>
> ldo@theon:~> wl-paste -t text/html
> Hi there.
>
>
> So ... nope.
Hi Lawrence,
OMG! That's beautiful!
That changes one of my assumptions!
My brain is wired for Occam's Razor, but to be always 100% logically
correct, I needed to know what you just proved - which I had not known.
Until now!
Thank you for confirming that Chromium and Firefox both put text/html on
the clipboard (even as Chromium¢s HTML flavor is apparently structured in a
way that confuses Notepad++, while Firefox¢s is not).
Thanks!
That's a really helpful unexpected demonstration of what's going on with
respect to the PSA's claims I made earlier.
I stand corrected. Both put text/html on the clipboard!
But differently so!
Thank you for confirming what is really happening with Firefox.
Your test above makes it abundantly clear that Firefox apparently *always*
advertises a 'text/html' flavor on the clipboard, even when the selected
content contains no markup at all.
In the plain-text case, Firefox just wraps the text in a minimal HTML
structure (a '' block plus a meta tag), so the presence of 'text/html'
doesn't imply that the original selection had any real HTML in it.
Also useful in your output was to see the extra Mozilla-specific types
('text/_moz_htmlcontext', 'text/_moz_htmlinfo') showing up unexpectedly.
Given this PSA is discussing an oft-obscured gotcha, I appreciate you
running the experiment and sharing the results along with your other tests,
which I have summarized below in the hopes you can check out my analysis.
It seems you first kindly & very helpfully outlined this basic test:
---------------------------------
* 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
---------------------------------
For those not familiar with Linux (where I'm rusty myself),
1. Emacs is a text editor.
2. wl-paste -l means list all clipboard formats.
3. The long list of names are the formats Emacs puts on the clipboard.
4. They are all plain-text-related formats.
5. Nothing HTML related appears here.
This is your baseline case, showing what a plain text editor exports.
Then you kindly posted your next block.
---------------------------------
* 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
---------------------------------
For those not familiar with Firefox browsers,
1. You copied text from Firefox.
2. Firefox apparently always offers text/html,
which is the HTML version of the selection
that you reproduced which I hadn't thought was there!
3. Firefox also unexpectedly adds two internal formats:
_moz_htmlcontext and _moz_htmlinfo.
4. Apparently these are Firefox specific metadata formats.
5. Firefox still includes plain text formats.
This test clarifies one errant assumption in the PSA
since both Firefox & Chromium are adding the text/html,
only differently so.
The next block showed how Chromium did things in the same setup.
---------------------------------
* 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
---------------------------------
For those not familiar with Chromium browsers,
1. You copied the same page & same text, but copied in Chromium.
2. Chromium always emits text/html, even if the selection looks plain.
3. Chromium also emits chromium/x-* internal formats.
These are Chromium specific metadata formats.
4. Chromium includes plain text formats too.
5. This is the behavior that caused my Windows issue as
Chromium often includes HTML that screws up Notepad++ selection.
Then you kindly added a KDE Konsole sanity check.
---------------------------------
* Copying the above text from KDE Konsole:
ldo@theon:~> wl-paste -l
text/plain
text/html
text/plain;charset=utf-8
---------------------------------
For those not familiar with Linux consoles,
1. KDE Konsole is a terminal emulator.
2. It offers plain text first.
3. It still includes text/html.
Again, the editor decides which format to request.
Your generously run tests seem to show that even terminals
may include HTML depending on the environment.
A. Emacs offers only plain text formats.
B. Firefox offers HTML only when it thinks the selection has structure.
C. Chromium always offers HTML plus internal formats.
Different applications expose different sets of formats.
Is it true the editor decides which format to use when pasting?
I'll try to run tests on my Windows box using Nirsoft InsideClipboard.
--
On Usenet, good people help others out of their kindness & generosity.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
