FYI, experimenting I see two common scenarios.

The first case which I hit 90% of the time is that the text I'm pasting simply has no HTML elements present, eg because I've just selected some text from the middle of a paragraph

In this case quaternion prints this on the stderr:

"Invalid XHTML: Diff selection: mark the radio boxes of the versions to compare and hit enter or the button at the bottom.
Error at char 1: "Start tag expected."
Buffer at error: iff selection: mark the radio boxes of the versions to compare and hit enter or the button at the bottom.
HTML insertion failed at pos 1 with error "Start tag expected."

So the HTML parser is not seeing any start tag and thus considers it invalid HTML.

IMHO this is simply and plainly broken. Any bare text should be considered valid HTML.

The less common case is where the text I've selected in the browser is not well formed because it lacks correct opening/closing tag pairs. I've see the browser emit such code when selecting text that crosses sections of the page - some opening or closing tags may get omitted depending on where I've started or ended the text selection..

From the POV of parsing the pasted text, it is understandable that the HTML parser be unhappy with this, and it is somewhat tricky to reconcile. None the less, as a user I feel like we should still be able to paste the selected text into a message. Almost any other app successfully pastes the text in this scenario, because they simply ask the original paste selection owner for the text/plain version rather than the text/html version,and the browser is happy to supply the plain text with the mis-matched tags omitted. I feel like if HTML parsing fails, it would be better to request the selection as plain text and paste that, rather than rejecting it

Pasting pretty much anything from web pages does not work #849

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions