Description: Sometimes links that should be underlined are not. See steps to reproduce. Steps to Reproduce: Open the attached document and scroll to page 10 of 29, look at the underlined paragraph, where there are four links, "Section 1", "Section 2", "Section 3" and "Section 4". Actual Results: Some of the links are underlined and some are not. The ones that are underlined vary when you repeat the test! Expected Results: All the links should be underlined every time you repeat the test. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 152723 [details] Demonstration document
Matthew, thank you for reporting the bug. It seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version. Change to RESOLVED WORKSFORME, if the problem went away.
I have also reproduced the bug in this build: Version: 6.2.6.0.0+ (x64) Build ID: 1c6bac6e003e9f280a29cc83974bdfb3d06b24a9 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:libreoffice-6-2, Time: 2019-06-25_07:58:45 Locale: en-GB (en_GB); UI-Language: en-US Calc: CL
I have also reproduced the bug in this build: LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
I have also reproduced the bug in this build: Version: 6.4.0.0.alpha0+ (x64) Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-10_02:13:57 Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded
Thank you for reporting the bug. I can confirm the bug in Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded and LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Please retest this bug. In my case, every time is underlined. Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Waiting for your test. Please feel free to mark as New intead of Needinfo if you can test this bug with 7.5 or 7.6 and you STILL reproduce the bug.
Dear Matthew Kogan, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
For me it's never underlined. Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: CL threaded
(In reply to BogdanB from comment #7) > Please retest this bug. > In my case, every time is underlined. Bogdan: do you mean that you tested with attachment 152723 [details] and saw the section links on page 10 as underlined? I don't see them as underlined with kf5 or gtk3. Matthew: can you reproduce the same result with a new document? Ie. what would be the steps to arrive at this problematic situation? Arch Linux 64-bit, X11 Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 86c682273d907c77404637c89e584047de1c1099 CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 27 November 2023
No, I can't reproduce it in a new document.
Ok, I looked into the document some more. As the document has many styles with WW8 in their names, it seems the document came originally from a .DOC file. I extracted the document (ODT docs are ZIP files) and looked at the content.xml file. I searched for section 1 in the file to arrive at the interesting location. I noticed the text span used this nonexistent style: text:style-name="njlskdfg xref before and after text" After I changed the style name to T10 and rezipped the files, the corrected document showed the normal blue underline for the link. The document is broken and we don't know any reproducible steps, so I would be inclined to close this, but I will confirm with developers first.
Consensus in the chat was that closing is the right thing to do. We can revisit, if there are steps to arrive at the problematic situation, preferably starting from a .doc file that has not been edited in LibreOffice.
Fine, although I would like to point out that the style does exist - it's defined in content.xml in office:automatic-styles. <style:style style:name="njlskdfg xref before and after text" style:family="text"> <style:text-properties style:use-window-font-color="true" style:text-underline-style="none"/> </style:style>
(In reply to Matthew Kogan from comment #15) > Fine, although I would like to point out that the style does exist - it's > defined in content.xml in office:automatic-styles. > > <style:style style:name="njlskdfg xref before and after text" > style:family="text"> > <style:text-properties style:use-window-font-color="true" > style:text-underline-style="none"/> > </style:style> Ok, good catch - it was just not visible in the UI. But now you solved the mystery as you found: style:text-underline-style="none"
OK, but that doesn't explain why the underlining was inconsistent - that was definitely a bug.
(In reply to Matthew Kogan from comment #17) > OK, but that doesn't explain why the underlining was inconsistent - that was > definitely a bug. At least it is consistent now.