Created attachment 180626 [details] New Sample Document created with LibO 7.4 +++ This bug was initially created as a clone of Bug #113878 +++ Steps how to reproduce with Server Installation of Version: 7.4.0.0.alpha0+ (x64) Build ID b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US | Calc: CL | Auto Colibre Theme | Special devUserProfile based on my normal User Profile 1. Open sample document attachment 137808 [details] from Bug 113878 2. Double click cell A1 3. select string "hyperlink" (from left to right, using only mouse) 4. rightclick selection → copy 5. Doubleclick cell A3 → past Expected: string with link pasted Actual: String appears 2 times 😥 Additional info: a) Seems that Fix for "Bug 113878 - Copy/Paste of partial cell contents string with hyperlink - nothing happens or, in recent versions, string with link appears _twice_" onlysolved problem (a) from that bug b) Same with newly created document (see attachment) c) I did not test with LibO 5.3, but am pretty sure that this problem is remaining from Bug #113878 and not a new probem
Repro Arch Linux 64-bit Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: ff2b4bff61d2e1679bb525d754c960c48b81c495 CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 25 May 2022
Repro with Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: 118bafcfd1ce4a26ec9df912197ebd466d1bd497 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL Also repro in gen and gtk3
*** Bug 152602 has been marked as a duplicate of this bug. ***
*** Bug 142143 has been marked as a duplicate of this bug. ***
Debug suggests that the ODS FLAT TEXT created has two a href= entries? sax/source/fastparser/fastparser.cxx:332: ::callbackStartElement[body] ax/source/fastparser/fastparser.cxx:332: ::callbackStartElement[p] sax/source/fastparser/fastparser.cxx:332: ::callbackStartElement[a] xmloff/source/text/txtfldi.cxx:2885: XMLUrlFieldImportContext::ProcessAttribute[https://bugs.documentfoundation.org/show_bug.cgi?id=115317] Token[459717][href] xmloff/source/text/txtfldi.cxx:2885: XMLUrlFieldImportContext::ProcessAttribute[simple] Token[460728][type]\xmloff/source/text/txtfldi.cxx:2898: unknown attribute http://www.w3.org/1999/xlink xlink:type=simple sax/source/fastparser/fastparser.cxx:332: ::callbackStartElement[a] xmloff/source/text/txtfldi.cxx:2885: XMLUrlFieldImportContext::ProcessAttribute[https://bugs.documentfoundation.org/show_bug.cgi?id=115317] Token[459717][href] xmloff/source/text/txtfldi.cxx:2885: XMLUrlFieldImportContext::ProcessAttribute[simple] Token[460728][type] xmloff/source/text/txtfldi.cxx:2898: unknown attribute http://www.w3.org/1999/xlink xlink:type=simple sc/source/ui/view/viewfunc.cxx:765: ::aEngine.GetText returned[isis] It looks like this is going to get rather hairy. On the "export to clipboard" XMLTextParagraphExport::exportParagraph creates an enumeration that has TWO TextFields (if the selection ends on a textfield). So I expect the problem to be in xTextEnum = xEA->createEnumeration(); Yup - there are three "portions" here. "This ", "is", " a link". So the enumeration (based on the selection) creates portions 5 "" 5 (Text) 5 "\x001" 6 (TextField) 6 "" 6 (TextField) If the selection had gone to 7, then the last portion would be 6 " " 7 and be considered a Text portion. So why would 6, 6 be considered a TextField? Well this is all UNO garbage, so it is a mystery as to what properties becomes what. And we immediately lose all knowledge of start/end/selection etc. Boy I HATE UNO. make sd.check says that it isn't enough to say SvxUnoTextRangeEnumeration::SvxUnoTextRangeEnumeration - if( nEndPos < rSel.nStartPos ) + if( nEndPos <= rSel.nStartPos ) continue; So, it looks like some hacky solution may be needed for XMLTextParagraphExport::exportTextRangeEnumeration.
We don't have much to work with in exportTextRangeEnumeration -just some range properties with TextPortionType == TextField -an XTextRange that can getString. In the 6 "" 6 case the length is zero, but in the 5 "\x001" 6 case it is two, or "is". So what happens if the URL is empty? Probably a hacky solution would be to avoid exporting hyperlinks that are have an empty XTextRange. But I think I'll just leave this bug for a UNO expert, so they can fix whatever fundamental problem underlies this.