I don't know if its cause is the same as of #132770 report, so I'm reporting it separately, feel free to make as dup if that's the case. # Steps to reproduce 1. Create a test.html file with the following content <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang=""> <head> <meta charset="utf-8" /> <meta name="generator" content="pandoc" /> <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" /> <title>test2</title> <style> code{white-space: pre-wrap;} span.smallcaps{font-variant: small-caps;} span.underline{text-decoration: underline;} div.column{display: inline-block; vertical-align: top; width: 50%;} div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;} ul.task-list{list-style: none;} </style> <!--[if lt IE 9]> <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script> <![endif]--> </head> <body> <ins> Test </ins> </body> </html> 2. Open it in a browser (tested with Qutebrowser, Chromium, Firefox) 3. Copy the underlined word "Test" from a browser 4. Paste in a LO Writer document ## Expected Word "Test" that appears in lowriter is underlined (same as what you see in a browser) ## Actual "Test" is not underlined
It is worth noting that copying underlined text from google docs works fine. I compared lists of formats provided by google docs and by plain html document, and here's the list: From Google-docs | From plain html -------------------------------------------- chromium/x-web-custom-data | text/html | text/html MULTIPLE | MULTIPLE SAVE_TARGETS | SAVE_TARGETS STRING | STRING TARGETS | TARGETS TEXT | TEXT text/plain | text/plain TIMESTAMP | TIMESTAMP UTF8_STRING | UTF8_STRING As you can see the only difference in formats is `x-web-custom-data`. I'm not sure though LO Writer uses that, so it's intersting to see why such difference
I suspect LO uses text/html format of clipboard, so I managed to get contents of that format for Google Docs (copying from works) and plain html (it doesn't) Google docs: b'<meta charset="utf-8"><b style="font-weight:normal;" id="docs-internal-guid-cfdd430f-7fff-9177-bba3-5001b84d8ed7"><span style="font-size:10pt;font-family:Arial;color:#000000;background-color:#ffffff;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;-webkit-text-decoration-skip:none;text-decoration-skip-ink:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">Test</span></b>' Plain html: b'<span style="color: rgb(0, 0, 0); font-family: "Bitstream Vera Serif"; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: underline; display: inline !important; float: none;">Test</span>' What is interesting is that both cases has `text-decoration:underline`. It's just LO Writer ignores that in one of cases. So bug is probably different from #132770
Not clear this is a LibreOffice import filter issue. Looking at a clipboard content viewer (Nirsoft's InsideClipboard) seems more that the copy to clipboard function for the browser impacts usefulness of the inline CSS applied to the copied content. Checking results of clipboard paste when opening the sample HTML in each of Chrome, Edge, and Firefox are quite different. Paste Special content from MS Edge browser receives the Underline decoration. Clipboard contents for Chrome's (81.0.4044.129) HTML Format 49414 include the CSS for the span. 00000240 30 70 78 3B 20 74 65 78 74 2D 64 65 63 6F 72 61 0px; text-decora 00000250 74 69 6F 6E 3A 20 75 6E 64 65 72 6C 69 6E 65 3B tion: underline; but the text does not receive the underline decoration. Contrasted with MS Edge (44.18362.449.0) HTML Format 49414 also includes CSS for the span; and does style the text with underline. 00000180 20 6C 65 66 74 3B 20 74 65 78 74 2D 64 65 63 6F left; text-deco 00000190 72 61 74 69 6F 6E 3A 20 75 6E 64 65 72 6C 69 6E ration: underlin 000001A0 65 3B 20 74 65 78 74 2D 69 6E 64 65 6E 74 3A 20 e; text-indent: While the Firefox (75.0) HTML Format 49414 does not include the CSS for the span. And has no decoration as I'd expect. Also, the index (acting as prioroty for import) is sequenced differently for each of the browsers clipboard export.
FTR if anybody is interested, I made a python script that prints clipboard content https://github.com/Hi-Angel/scripts/blob/master/print_clipboard_content.py
Playing with InsideClipboard and its Clp file, I was able to make it work with Chrome by replacing in this clipboard HTML: > <html> > <body> > <!--StartFragment--><span style="color: rgb(0, 0, 0); font-family: "Times New Roman"; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: underline; display: inline !important; float: none;">Test</span><!--EndFragment--> > </body> > </html> the string "-webkit-text-stroke-width" with " webkit-text-stroke-width", i.e. removing the leading hyphen.
(In reply to Mike Kaganski from comment #5) > Playing with InsideClipboard and its Clp file, I was able to make it work > with Chrome by replacing in this clipboard HTML: > > > <html> > > <body> > > <!--StartFragment--><span style="color: rgb(0, 0, 0); font-family: "Times New Roman"; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: underline; display: inline !important; float: none;">Test</span><!--EndFragment--> > > </body> > > </html> > > the string "-webkit-text-stroke-width" with " webkit-text-stroke-width", > i.e. removing the leading hyphen. Thank you for extensive analysis! Worth noting, leading hyphen and underscores are allowed in the CSS selector name, and are usually used for browser-specific extensions. So LO CSS parser should not bail out upon seeing such syntax.
(In reply to Konstantin Kharlamov from comment #6) > (In reply to Mike Kaganski from comment #5) > > Playing with InsideClipboard and its Clp file, I was able to make it work > > with Chrome by replacing in this clipboard HTML: > > > > > <html> > > > <body> > > > <!--StartFragment--><span style="color: rgb(0, 0, 0); font-family: "Times New Roman"; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: underline; display: inline !important; float: none;">Test</span><!--EndFragment--> > > > </body> > > > </html> > > > > the string "-webkit-text-stroke-width" with " webkit-text-stroke-width", > > i.e. removing the leading hyphen. > > Thank you for extensive analysis! > > Worth noting, leading hyphen and underscores are allowed in the CSS selector > name, and are usually used for browser-specific extensions. So LO CSS parser > should not bail out upon seeing such syntax. @Julien, I thought you might be interested in this issue
Reading tdf#132770 it seems any change in this kind of place may bring some regression because of css. So I can't help here and uncc myself.
(In reply to Julien Nabet from comment #8) > Reading tdf#132770 it seems any change in this kind of place may bring some > regression because of css. > > So I can't help here and uncc myself. While both issues mention CSS, but I see no relation beyond that. The current issue is about parser of CSS selectors being overly strict. I don't see how relaxing it to allow selectors to start with a hyphen or underscore may lead to a regression. The issue you referred to is ultimately about <ins> tag being parsed differently from <u> tag. Changing it to be parsed similarly to <u> tag indeed would lead to a regression, due to a bug reported at tdf#132914. So, the issue you referred to is not about CSS. The issue at tdf#132914 it seems is about html parser not applying CSS rules to some tags (the CSS parsing per se works fine, it's just that HTML parser does not apply its result to some tags). I.e. this issue is not about CSS parser either.
Dear Konstantin Kharlamov, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still repro in 7.4.3 Version: 7.4.3.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US 7.4.3-3 Calc: threaded