-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pasting pretty much anything from web pages does not work #849
Comments
I'm seeing the same problem with pasting pretty much any text from firefox. For context, I'm using quaternion-0.0.95.1-3.fc37.x86_64 on Fedora 37 login session with GNOME Desktop plus Wayland. My workaround is to paste the text from firefox into a terminal or editor, then copy it again and paste into quaternion. |
Many people like pasting plain text as there is less trouble with it and does the job. Even Element pastes plain text by default despite of being a rich client. This is why this patch switches to plain text pasting by default while makes it configurable. Other version can be pasted by `Ctrl+Shift+V`. Cc quotient-im#849
Many people like pasting plain text as there is less trouble with it and does the job. Even Element pastes plain text by default despite being a rich client. This is why this patch switches to plain text pasting by default while makes it configurable. Other version can be pasted by `Ctrl+Shift+V`. Cc quotient-im#849
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:
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 |
Mismatched tags are also valid in many cases in html, just not in xhtml. The parser basically'd need to parse html and not xhtml :) |
@berrange thanks for the investigation. The first case was indeed caused by a blunder and will be fixed shortly. And I agree that reverting to the plain text version with feedback about it in the status bar is a good approach for the second case. @nephele-gh XHTML is what Quaternion converts HTML to, internally. If you know a good lightweight Qt-based HTML parser, let me know. |
It almost always leads to "invalid or unsupported" error message.
In the worst case the plain text version should be inserted.
The text was updated successfully, but these errors were encountered: