Created attachment 140421 [details] Try to change the color of some characters of the cells A2, A3, A4 or A5 It seems that calc interprets some text cells as a formula when it comes to formatting. 1) I type in a cell a text that starts with the character '+' or '-', and that this text contains at least once a cell reference (ex: "+ foofoo A7 foofoo") 2) If I change the color of some characters (not the whole cell!), for example the 2nd foo (ex: "+ foo<foo> A7 foofoo"), it works. => Here, we already see that A7 becomes blue as if it were a formula. 3) But if you modify the cell (selection, add a space, ...), the color goes away. Yet I tried to see with TYPE or ISFORMULA functions, but these cells look like text (left alignment).
Hi Elyse, I don't reproduce with LO 6.0.2.1 Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 Threads CPU : 2; OS : Windows 6.1; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: CL Can you precise your OS, please?
Created attachment 140442 [details] The bug, step by step, with images
Hi Jacques, Thank you for your test! I tested both on linux and windows and get the same behaviour. Version: 6.0.2.1 (x64) Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU threads: 2; OS: Windows 10.0; UI render: default; Locale: en-US (en_US); Calc: group Version: 6.0.2.1 Build ID: f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: fr-FR (fr_FR.UTF-8); Calc: group But perhaps I did'nt explain it clearly (sorry for my english), so I added an attachment with images.
confirm with Version: 6.1.0.0.alpha0+ Build ID: a790ee54319583897d82d4372243df870d4452a6 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
This time, I reproduce it. However, when I isolate + by putting it between quotes, I don't reproduce this effect. Do you agree? And it seems to happen only with this key/operator.
Try this also with LO 3.5.3.2 Version ID : 235ab8a-3802056-4a8fed3-2d66ea8-e241b80 under Windows 7 with the same behavior. So probably inherited from OOo.
Hu Jacques, I tested with AOO 4.2.0rc and yes the same behavior. And putting a ' before the + then everything works fine. Gnumeric has a warning to re-edit or to accept the input. When accepting then it auto put a ' in front of the +. So it could be a nice future as well for LO. What you think about it???
Elyse, do you work on a patch for this as you are the assignee? Please only assign a bug to yourself if you work to fix it in the source code. I downloaded the attached file and tried the steps in A15. As a result, the red colored text is only changed to blue during cell editing (then LibreOffice handles 'A1' as a formula reference to cell A1). After leaving the cell, the text is red again. But if I colorize 'ffero' behind 'A1' in red, edit the cell and add a space at the end of the cell text and then go to another cell, then the red color of 'ffero' is gone. Version: 6.1.0.0.alpha0+ Build ID: cab04bc39b5164ea74216cd849c3af5f5b298f79 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: de-DE (de_DE.UTF-8); Calc: group
Dear Elyse Cordeau, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Dear Elyse Cordeau, 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 Elyse Cordeau, 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
reproduced in recent master build: Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: f4c24da1e7f11664e0d2f688d2531f068e4a3bc0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded However, as you assumed correctly, this is due the contents of the cell being understood as a formula ("=" is usually used, but "+" and "-" can also do that). It is true that it is awkward that the formatting can be kept until the "formula" is modified. It is also possible to format a formula starting with "=", but it shouldn't be visible when finished editing because it usually displays the results (or an error). Eike an UX team, kind of related to the confusion in bug 132026 and bug 129369, there's the bigger question: why doesn't a formula that starts with +/- behave more like a formula starting with "=", i.e. either giving the result of the formula or errorring if it's invalid?
Cannot confirm. Is View > Value Highlighting / Ctrl+F8 on or off? (If on all colors are gone.)
Also can't confirm. Just works. Version: 7.5.4.0.0+ (X86_64) / LibreOffice Community Build ID: b6c0738f2a1906c2b5a967793e9b065a1b43d75e Locale: en-CA (en_CA.UTF-8); UI: en-US Also works in Version: 7.6.0.0.alpha0+ (don't have a current 7.6.0.0.alpha1+ at hand). Note that in the sample document only A4 has the Text format applied, A2,A3,A5 have the General number format applied but the cell content is text. Also note that while editing A3 the content is prefixed with an ' apostrophe. This may had been different 5 years ago when this bug was created. But that wouldn't explain why Stéphane could reproduce it with 7.6.0.0.alpha1+. (In reply to Stéphane Guillou (stragu) from comment #12) > why doesn't a formula that starts with > +/- behave more like a formula starting with "=", i.e. either giving the > result of the formula or errorring if it's invalid? I don't understand the question. How do +/- and = differ?
(In reply to Heiko Tietze from comment #13) > Cannot confirm. Is View > Value Highlighting / Ctrl+F8 on or off? (If on all > colors are gone.) Value highlighting is off for me. I have noticed that using the formula bar vs editing directly in the cell does matter for reproducing the bug, and that this is not just about formulas in 7.6 anymore. Steps: 1. Open Calc 2. enter the following string in a cell, but don't press Enter: + one A1 two 3. make "one" red, press Enter -> quote prefix is not added even though the formula is not valid; formatting persists 4. select cell, and _in the formula bar_ add a space at the end of the string -> partial direct formatting is lost; prefix is again hidden when out of edit mode So it seems that editing the value in the formula bar automatically interprets it as a formula, and therefore removes the formatting, even if the end result is still an invalid formula. This is the same in OOo 3.3, but note the differences between OOo 3.3 and LO 7.6: - format lost in LO 7.6 even if there is no cell reference (using only "+ one two") - format lost in LO 7.6 even if there is no +/- (using only "one two") - format lost in OOo 3.3 even when editing directly in the cell Somewhat related: Steps: 1. Open Calc 2. enter the following string in a cell and press Enter: + one A1 two -> note the ' prefix is automatically added, because not a valid formula 3. make "one" red, press Enter -> quote prefix does not automatically hide anymore when out of edit mode 4. add a space at the end of the string -> partial direct formatting is lost; prefix is again hidden when out of edit mode (In reply to Eike Rathke from comment #14) > I don't understand the question. How do +/- and = differ? I was thinking of the difference in output between these two formulas: =2+test +2+test ...but I realise now that a single quote should always be prepended when the formula is not valid, whereas an equal sign is prepended when it is. So scrap that comment :)
(In reply to Stéphane Guillou (stragu) from comment #15) > 3. make "one" red, press Enter > -> quote prefix is not added even though the formula is not valid; confirming > 4. select cell, and _in the formula bar_ add a space at the end of the string > -> partial direct formatting is lost; prefix is again hidden when out of > edit mode not confirming Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 8; OS: Linux 6.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.5.3-2 Calc: threaded (In reply to Stéphane Guillou (stragu) from comment #12) > why doesn't a formula that starts with +/- behave more like a formula > starting with "=", i.e. either giving the result of the formula or > errorring if it's invalid? Entering -1+2 does becomes 1 (=-1+2) and -1+z the string ('-1+z). What do you think should change?
(In reply to Heiko Tietze from comment #16) > > 4. select cell, and _in the formula bar_ add a space at the end of the string > > -> partial direct formatting is lost; prefix is again hidden when out of > > edit mode > not confirming Oof, it's GTK-only. Thanks for testing. Not reproduced on kf5 or gen. > (In reply to Stéphane Guillou (stragu) from comment #12) > Entering -1+2 does becomes 1 (=-1+2) and -1+z the string ('-1+z). What do > you think should change? Acknowledged in comment 15, please ignore that question :)
(In reply to Stéphane Guillou (stragu) from comment #15) > I have noticed that using the formula bar vs editing directly in the cell > does matter for reproducing the bug, and that this is not just about > formulas in 7.6 anymore. Indeed, editing in the Input Line (what you call formula bar) discards all in-cell formatting, apparently the Input Line does not know about character attributes. (In reply to Stéphane Guillou (stragu) from comment #17) > Oof, it's GTK-only. Thanks for testing. Not reproduced on kf5 or gen. Geez, that's even more twisted.. > 2. enter the following string in a cell, but don't press Enter: + one A1 two > 3. make "one" red, press Enter > -> quote prefix is not added even though the formula is not valid; Correct observation but wrong conclusion. It's not about the formula being valid or not, it's not a formula at all because entering attributed text forces a rich text edit cell instead of a formula cell. > 4. select cell, and _in the formula bar_ add a space at the end of the string > -> partial direct formatting is lost; prefix is again hidden when out of > edit mode > > So it seems that editing the value in the formula bar automatically > interprets it as a formula, and therefore removes the formatting, even if > the end result is still an invalid formula. Yes. Just that it removes the formatting regardless whether it would be a formula or not or a valid formula or not. > Somewhat related: > > Steps: > 1. Open Calc > 2. enter the following string in a cell and press Enter: + one A1 two > -> note the ' prefix is automatically added, because not a valid formula No, because the cell content is text that with a non-Text number format because of the leading + could be interpreted as formula when editing. The cell content became text because the input didn't form a valid formula. > 3. make "one" red, press Enter > -> quote prefix does not automatically hide anymore when out of edit mode Because with the attributed characters a rich text cell is created of all input. We should maybe implement the same behaviour there as for any other text input: discard a leading ' apostrophe if the cell wasn't already formatted as text. On the other hand, such attributed content is never converted to numeric or other data types. > 4. add a space at the end of the string > -> partial direct formatting is lost; prefix is again hidden when out of > edit mode Because editing in the Input Line removes attribution,, > (In reply to Eike Rathke from comment #14) > > I don't understand the question. How do +/- and = differ? > > I was thinking of the difference in output between these two formulas: > =2+test > +2+test > > ...but I realise now that a single quote should always be prepended when the > formula is not valid, whereas an equal sign is prepended when it is. So > scrap that comment :) See above, it's actually text cell content vs formula content.
So all this speculation about formula or not is completely moot, it's simply in-cell rich text attribution that when editing in the Input Line with gtk3 is not preserved for the EditEngine text of the cell content. e.g. enter one two in a cell and format the word two as red and close with Enter, then edit the cell in the Input Line and as soon as a character is typed the cell content attribution is lost. Let's add Caolán for this.. Caolán, an idea why that happens only for gtk3 but not kf5 or gen backend?
(In reply to Eike Rathke from comment #19) > So all this speculation about formula or not is completely moot, it's simply > in-cell rich text attribution that when editing in the Input Line with gtk3 > is not preserved for the EditEngine text of the cell content. > > e.g. enter one two in a cell and format the word two as red and close with > Enter, then edit the cell in the Input Line and as soon as a character is > typed the cell content attribution is lost. > > Let's add Caolán for this.. > Caolán, an idea why that happens only for gtk3 but not kf5 or gen backend? OK, I've identified the formula bar regression and opened 155453 to track independently, and made it block this one. It is indeed from one of Caolán's commits in 7.2. Let's keep this report open for the issues seen before 7.2.