This is a follow up on bug 100038, https://bugs.documentfoundation.org/show_bug.cgi?id=100038#c2 in particular. Sample cell entry from original bug report: "40V, 200mA, h=100@1V,10mA". A couple of closely related issues with URL recognition in Calc: 1. If the text is typed(!) in a cell with a space after the comma after the "link" (so, as "40V, 200mA, h=100@1V, 10mA"), weirdly, right-clicking the text in the Input line above the sheet permanently removes the URL (sometimes this can be reproduced if there's no space there, but it's not that consistent). 2. Sometimes the link is displayed as a link in the Input line (if it's typed in there, for example), but if you move between cells and come back, it will show as normal text (still in Input line). Particularly if you move with cursors, it'll stay as a link, if you select the cell with mouse, it'll be normal text. 3. When it's not displayed as a link in the Input line, and part of the text/link is selected, the selection shown in the cell won't be the same. 4. Using autocomplete to finish the entry based on a previous one does not create links. Originally tested with 5.1.3.2, still reproduced with 5.3.0.0.alpha1 / Windows 7.
Setting to new based on original bug report.
Thank you, Aron.
So seems the issue is with the logic of the autocorrect recognition of "what" sequence represents a URL -- presumably sequences with punctuation in proximity to the U+0040 (COMMERCIAL AT) glyph. I have not looked for where those rules are, but would expect they are global right now, and would do similar things in all modules. Yep, just verified 1 & 2 affect input in Writer, so a global autocorrect recognition of URL. Probably should not recognize the U+002c (COMMA) followed by the space as a trigger for URL recognition. And for 3 & 4, simply moving cursor focus away does not trigger the auto-correct to change/corrupt the content. So actually find that behavior consistent and somewhat expected. None the less, ability to toggle a separate set of autocorrect rules/behavior for Calc as in bug 98154 would be useful.
Let me adjust the title. Here the issue is not with the autocorrect (URL recognition) itself, but with the handling of URLs that are already there. Like, in relation to issue 1. we can debate whether URL recognition should stop at the comma or not, but the behavior described there should not occur (eg. removing the URL-ification by clicking inside the Input line), and should not depend on whether there's a space after the comma or not.
Please at least attach a simple test document to this bug report so we don't have to go digging into a second bug report to find what we need. Thanks
Created attachment 128231 [details] Sample spreadsheet with a URL, see comment 6 on how to use it to reproduce some of the issues All the details that are needed are in this bug report, though it might not be clear without knowing that the original bug report was about URL recognition. The mentioned sample text ("40V, 200mA, h=100@1V,10mA") contains a "@", which causes "100@1V" to be recognized as a URL when it's entered. This report is not about the URL recognition itself, but about some issues when it comes to working with cells containing URLs. For the 1st issue you have to type the text in, or copy/paste and trigger autocorrect with a space in the appropriate position. For issues 2-4 you can use the text with the recognized URL, but to make it easier, I'm attaching it in a file as well. Based on the attachment: 2. Switch to A2, then back to A1 using the keyboard. Note how the Input line shows the URL as a URL (like the cell). Now do the same using the mouse (select A2, then A1). Note how the Input line shows the URL as plain text. 3. When it shows the URL as plain text in the Input line, select part of the URL there, for example "00@1V". The cell shows the selection incorrectly ("0mA" for me in this case). 4. Interestingly, right now I can't reproduce this (eg. using autocomplete to enter the same entry in another cell does produce the link inside). I doubt it's fixed, but I don't want to spend too much time on this.
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Aron Budea, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The 1st is fine now, but bugs 2-4 are still reproducible in LO 7.2.0.0.alpha0+ (7673b027daed248d1be4dd1a773bfc0334a00c53) / Ubuntu.
Dear Aron Budea, 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
I still reproduce in a recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b83f069101f1e6d8aaac09a805f02bbc4c619e7a CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Has been observed in 3.5 as well, as shown in bug 114022. See the description of the "cycling" nature of the issue, described by Mike in duplicate bug 146020: (Mike Kaganski from bug 146020 comment #0) > Created attachment 176665 [details] > Screen cast > > When a Calc cell contains a URL field, entering the formula bar first time > does not highlight the field, *and navigates the URL content as if it is > normal text*. Clicking to the same cell to leave formula bar, then entering > the formula bar again, (but *not* leaving this cell!) highlights the field, > and starts to "jump" over the field, and usual. Leaving the cell, and > entering it again, starts the sequence anew.
*** Bug 114022 has been marked as a duplicate of this bug. ***
*** Bug 146020 has been marked as a duplicate of this bug. ***
*** Bug 145073 has been marked as a duplicate of this bug. ***
*** Bug 154413 has been marked as a duplicate of this bug. ***
FWIW (url/hyperlink/email address)... From: https://ask.libreoffice.org/t/cant-edit-a-url-in-a-calc-cell/98712/9 With minor rewording: 1. Focus on the cell containing the URL you want to edit. 2. Click the "=" icon in the formula bar. 3. Edit the URL text in the formula bar. Step 2 is key.