Description: Hello, To extract data from a not so small calc *.ods file (650ko file, 1200 lines sheet, with macros in it but not in the active sheet), I created a new calc *.ods file, having one on the left side of my screen and another on the right side of my screen, and I have processed a lot of copy and past between the two windows. It wasn't smooth at all, and I've got several oddities : - when pasting to the second window, the cell from the first one was deleted (as if I did a "cut and paste", but I'm sure that several times it disappeared after a "ctrl c" + "ctrl v"). This bug appeared quite often before I escaped the active cell on window 1 before pasting the data (text) in the second cell -LibreOffice was sometimes rather slow for doing which seems trivial tasks (mainly copy & paste and calculating easy formulas (sums and small ratios) -LibreOffice stopped responding several times when I tried to extract my data, and I've lost several work hours The last item leads to the following note : I've used LibreOffice (and before that OpenOffice) for a lot of years, and I've always been very happy with the recovering data features when the application closed abnormally, and I've nearly never lost data and work-time (and because of that I lost the habit doing frequently "ctrl +s" to avoid losing new data when working with the LibreOffice suite). Since I've updated to Debian 12 and LibreOffice 7.4.7.2 mid-December, crashes occurred 3 times, and the recovering tools didn't recover anything each time. I'm using Debian stable because I don't need to have the flashing new software, but I want something that works. It seems to me that with Debian 12 and LibreOffice 7.4.7.2, that's not the case anymore, and that's very sad. I want to add that I thank you all a lot for your work (even if this time I write to you to show grievance), and I beg you to excuse me for my bad English. Steps to Reproduce: 1.Have a quite large calc file with text (not always plainly formatted) in a window 2.Have a new calc file in another window 3.Process a large number of copy & pastes between the two windows More precisely : - click on a cell in window 1 - click on input line in window 1 (to select the text without formatting) - ctrl + c to copy - click on a cell in window 2 - click on input line in window 2 - ctrl + v to paste After about 10 iterations, you should see some bugs, firstly the cell on windows 1 whose content is deleted. If you try ctrl + z on window 1 to cancel, you should see other weird things. Actual Results: -Data disappearance from first window (even if it isn't cut & paste) -LibreOffice freezing/ 100% processor-infinite-loop -data loss when we have to restart LibreOffice Expected Results: Only a plain copy&paste behaviour Reproducible: Sometimes User Profile Reset: Yes Additional Info: Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Debian package version: 4:7.4.7-1+deb12u1 Calc: threaded
PS : Try with text in bold in window 1 to better see the copy & paste bugs.
(In reply to Bastien from comment #0) > - click on a cell in window 1 > - click on input line in window 1 (to select the text without formatting) > - ctrl + c to copy Here, after selecting the content of the input box and after pressing [CTRL]+[C], please press [ESC] (and even better, press it twice, just in case), before you continue with the next steps. > - click on a cell in window 2 > - click on input line in window 2 > - ctrl + v to paste With the additional step (pressing [ESC]), do you still have the same problems?
(In reply to Bastien from comment #0) > Version: 7.4.7.2 Please note that current versions are 7.5.9 (which was the last release in 7.5 branch) and 7.6.4. Version 24.2 is to be released in a month. Please try with a currently supported version. Also note, that without very specific steps (like "open *this* document (or create new, and type this to that cell, this to that cell, ...); put cursor here; press this (key combination / toolbar button / menu item); click there on the other document ..."), the bug will likely be unmanageable (at least for quite a long time, until someone manages to find repro steps).
(In reply to ady from comment #2) > (In reply to Bastien from comment #0) > > > - click on a cell in window 1 > > - click on input line in window 1 (to select the text without formatting) > > - ctrl + c to copy > > Here, after selecting the content of the input box and after pressing > [CTRL]+[C], please press [ESC] (and even better, press it twice, just in > case), before you continue with the next steps. > > > - click on a cell in window 2 > > - click on input line in window 2 > > - ctrl + v to paste > > With the additional step (pressing [ESC]), do you still have the same > problems? No, it's fine when I deliberately quit the source cell before pasting.
(In reply to Mike Kaganski from comment #3) > (In reply to Bastien from comment #0) > > Version: 7.4.7.2 > > Please note that current versions are 7.5.9 (which was the last release in > 7.5 branch) and 7.6.4. Version 24.2 is to be released in a month. Please try > with a currently supported version. Yes, I know debian is slow to add new versions of applications in its stable version, but I reported this problem for 3 reasons : - the first problem I met, cell contents which disappeared after pasting the cell content to another cell in another window. It seams to me to be a minor bug, and it can be easily tested if it appears in current version - the second problem I met, libreoffice calc crashing after a lot of processing between 2 windows : it seems to me to be a critical bug, and it should be linked to the first problem, and this bug may still exist in the current version (I can't test it myself) - the third problem I met, libreoffice calc recovering tool can't recover my work since last save (for the fist time for years, in my very personal case). It seems to me to be a major bug, I have no idea if it's linked to this specific bug or not, and it could still exist in the current version ; I thought it may be important to notify it. > Also note, that without very specific steps (like "open *this* document (or > create new, and type this to that cell, this to that cell, ...); put cursor > here; press this (key combination / toolbar button / menu item); click there > on the other document ..."), the bug will likely be unmanageable (at least > for quite a long time, until someone manages to find repro steps). - create a new calc document, window1, with for example a column full of bold random text (with a number in and of the line, to better follow what is done), for example an hundred line - open a new calc document, window2 - copy from window1, first cell, input line, and 'ctrl+a' to select all, 'ctrl+c' to copy it (normally without its style, as we are in the input line) - go to window2, any cell, input line, and "ctrl+v" to paste the cell content I've just done theses steps 3 times : -> the text formatting was always copied although it should'nt have -> the cell content from window 1 was deleted at the 2nd and 3rd iteration -> it's easy to see if that's the case in a current version. If you do theses steps a large number of times with 7.4.7.2 version, LibreOffice calc should freeze, and all changes in window1 and window2 should be lost. It is the case in current versions ?
(In reply to Bastien from comment #5) PS: the cell content I've used for this last test was "azffzfzfzff aefegzrg ergh ethtrh ergetgh ergetgetg erg tgt ghtg 1", and then I've draw it in an about a hundred lines column
(In reply to Bastien from comment #4) > > With the additional step (pressing [ESC]), do you still have the same > > problems? > > No, it's fine when I deliberately quit the source cell before pasting. While there might be some kind of "leak" or some kind of problem that eventually freezes Calc after multiple back and forth between 2 input boxes, the fact that the freeze is not there when the correct procedure is followed makes the matter much less important. @Bastien, I would like to present you with a different scenario. Let's assume that you were trying to relate or link one workbook with another, by using one formula in one workbook that takes arguments from another workbook. If the first input box were to be automatically "canceled" (or rather, left untouched, without modification, and not active) when you click on another workbook, it would imply that you cannot build such a formula by using the mouse. So, this is why you need the [ESC]: to get out of the cell's edit mode in the first workbook, instead of maintaining the edit mode and linking the other workbook with the first one. In this regard, I would consider the described behavior to be not a bug. Having said that, going back and forth between input boxes seems to be making the problem worse for you at every additional click, up to generating the crash. Maybe some developer (which I am not) would like to tackle that issue, but in such case the crash would need to be replicated. Additional question: was the procedure (without [ESC]) working without a freeze in any older version of LO, ever?
(In reply to Bastien from comment #5) > - the first problem I met, cell contents which disappeared after pasting the > cell content to another cell in another window. It seams to me to be a minor > bug, and it can be easily tested if it appears in current version Absolutely no. I tried, and I do not see anything similar - but I have no idea if it's because of different version; or different OS; or different document; or different cell ... Without *proper* way to repro (which would allow anyone to confirm it with the same version in the first place), any negative repro result is useless. > - create a new calc document, window1, with for example a column full of > bold random text (with a number in and of the line, to better follow what is > done), for example an hundred line Oh sigh. Please YOU do create such a document; check that it indeed repro on your system using some *specific* actions; post the file here, and provide these specific steps. It doesn't matter if these steps are only randomly chosen; it would be known, that exactly these clicks exactly on these cells in exactly this order in exactly this document are known to produce the problem.
(In reply to ady from comment #7) > (In reply to Bastien from comment #4) > @Bastien, I would like to present you with a different scenario. > [...] Thank you for your message, I understand better what may occur. But I'm not sure if you had another question for me or not (as I've written, I've just used cells with a text content, without any formula here) > Additional question: was the procedure (without [ESC]) working without a > freeze in any older version of LO, ever? The "procedure" was a unique one, because it seems to me that this way of doing was easier for me to extract the data I wanted, so as to create another sheet later (I'm sure I could obtain the same result with at least 5 others ways, as it is often the case with computers). So I cannot unfortunately answer your question :(
(In reply to Mike Kaganski from comment #8) > > - create a new calc document, window1, with for example a column full of > > bold random text (with a number in and of the line, to better follow what is > > done), for example an hundred line > > Oh sigh. Please YOU do create such a document; check that it indeed repro on > your system using some *specific* actions; post the file here, and provide > these specific steps. It doesn't matter if these steps are only randomly > chosen; it would be known, that exactly these clicks exactly on these cells > in exactly this order in exactly this document are known to produce the > problem. "Oh sigh" -> I've absolutely done that : create an empty document, check that theses actions indeed reproduced the bug I've described, and then only wrote the "2024-01-02 15:56:47 UTC" message : "- create a new [empty] calc document, window1, with for example a column full of bold random text (with a number in and of the line, to better follow what is done), for example an hundred line [the cell content I've used for this last test was "azffzfzfzff aefegzrg ergh ethtrh ergetgh ergetgetg erg tgt ghtg 1", and then I've draw it in an about a hundred lines column] - open a new [empty] calc document, window2 - copy from window1, first cell, input line, and 'ctrl+a' to select all, 'ctrl+c' to copy it (normally without its style, as we are in the input line) - go to window2, any cell, input line, and "ctrl+v" to paste the cell content" I can't be more precise in this not native (for me) language. It doesn't matter which column and which line for the cell, the bug (?) appears every time for me when I _do not_ escape the input line before pasting its content.
(In reply to Bastien from comment #10) > > Oh sigh. Please YOU do create such a document; check that it indeed repro on > > your system using some *specific* actions; **post the file here**, and provide > > these specific steps. It doesn't matter if these steps are only randomly > > chosen; it would be known, that exactly these clicks exactly on these cells > > in exactly this order in exactly this document are known to produce the > > problem. > > "Oh sigh" -> I've absolutely done that : create an empty document, check > that theses actions indeed reproduced the bug I've described, and then only > wrote the "2024-01-02 15:56:47 UTC" message : Sigh again. I wrote specifically: "post the file here". Not the instructions as specific as "column full of bold **random** text" (it is indeed so difficult to understand that your random text is different from my random text), but the *specific file* that you created on your system you used to test your problem, you made sure that it shown it to you; and now you say : this is the attachment that you may use, and may be sure that it is byte-to-byte identical to what failed on my system (even though I am sure that anything would show the same; but who knows - maybe there's something - e.g., language; default template; length of text in cells ... - so you asked for it, here it is!). Whatever, I've spent too much time persuading you to help us help you. I intended to test, and maybe fix it if I find the problem, but I know better ways to spend my time.
Created attachment 191878 [details] File asked by Mike Kaganski With this document for example, when I copy&paste text withouth formating from the input line, the source cell content is deleted.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Bastien from comment #12) > Created attachment 191878 [details] > File asked by Mike Kaganski > > With this document for example, when I copy&paste text withouth formating > from the input line, the source cell content is deleted. Reproduced with gtk3 only. Using two windows and copying text from the input line and trying to paste to the input line in the other window. Usually the first focusing attempt to the input line fails. The disappearance of the source text is not reliable, but the failing of the focus is much more so. There can indeed be other glitches, like contents of the other window getting frozen, so you can scroll the view and repainting does not happen. Bibisected with linux-64-7.1 to e087e25f05e689091cbf1c4f91b6e93878ac17ec weld InputBar