Open Bug 1597772 Opened 5 years ago Updated 2 years ago

Wrong clipboard content type (targets) for plain text pages

Categories

(Core :: DOM: Serializers, defect, P3)

70 Branch
Unspecified
Linux
defect

Tracking

()

Tracking Status
firefox72 --- affected

People

(Reporter: kirelagin, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Actual results:

TIMESTAMP
TARGETS
MULTIPLE
text/html
text/_moz_htmlcontext
text/_moz_htmlinfo
UTF8_STRING
COMPOUND_TEXT
TEXT
STRING
text/plain;charset=utf-8
text/plain
text/x-moz-url-priv

Expected results:

No text/html in the list.

This is a problem because some tools (example: notion.so) may choose to parse Markdown form the clipboard if the content is not already HTML.

See Also: → 1543441

Just to clarify: this bug is about Linux, even though my User Agent is macOS.

(It does not work correctly on macOS either, but I have yet to figure out how to inspect the content type of clipboard here to make a meaningful report.)

OS: Unspecified → Linux

I am attempting to confirm your issue, but I don't understand the steps provided. Can you please explain the 3rd step? Basically, you need to open the provided link, then copy the whole page content using CTRL+A and CRTL+C, and then do what with it? What are the actual and expected results?

Thank you for your contribution!

Flags: needinfo?(kirelagin)

Firefox puts the content of the page into the clipboard, and then you inspect the mime type of the data in the clipboard using the command I provided. The expected result is that it shows up as plaintext, the actual result is that it says it is HTML (that is, Firefox, when putting the data, claims that it is HTML). Does this explanation help?

Flags: needinfo?(kirelagin)

Yes, the last comment was very helpful. I confirm that the text/HTML is present in the list of the list after copying the entire content of the test page and then running the "xclip -o -t TARGETS" command.
The component (Core) DOM: Serializers seems to fit. Please set a more appropriate one if incorrect. Thank you!

Component: Untriaged → DOM: Serializers
Product: Firefox → Core

Why there shouldn't be text/html?

Priority: -- → P3

Because it's plaintext, not html.

The problem is that a text/plain document produces an HTML document. And in Firefox currently that could even be styled using the Link header. And that can happen in other browsers too if it's an embedded document.

I suppose we could add some kind of special case...

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.