Created attachment 104603 [details] A picture that proofs the different output of the same cell When I'm using the isnert key toggled on my keyboard and double clicking a cell and editing the text in the formular line the behaving isn't as expected. Steps to reproduce: 1. Doubleclicking a Cell and put the cursor on the end of the line in the formular editor whiles the insert keyboard function is toggled on. 2. now moving with the arrow keys some letters before the end. So that the black block appears. (When the insert key gets activated while the formula editor line has already focus it "MOSTLY" works) 3. Now write something. Current behavior: The text in the formular editor line gets replaced as its the intended behaving of the toggled insert function. But the line in the table which you can vie at the same time doesn't. It merges it instead. And also if you confirm the line in the formula editor. the letters in the cell differ from those you confirmed (made me a big effort to review my work and correct this) Expected behavior: The value in the cell should be also replaced, same as the one in the formula editor. Or at least if it is the intention to not support the insert key, dont make the via enter confirmed value be different from the one written in to the cell by using the isnert key. Operating System: Windows 7 Version: 4.3.0.4 release
Hi domenik, I reproduce this behaviour too with LO 4.3.0.4, except the first time after opening where I have the correct behaviour (all versions). The second time and the others, even if caracters are replaced in the editing windwow, caracters after inserting point are kept in the cell. The same with: LO 4.4.0.0.alpha0+ Build ID: eddd7646d672ea9b0561dacb09da224d098e531e TinderBox: Win-x86@39, Branch:master, Time: 2014-07-18_06:42:50 LO 4.2.7.0.0+ Build ID: 92216be6ce13990b8ea6b6264c656d2bc1746401 TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-07-14_16:21:42 LO 4.2.2.1 LO 3.6.7.2 LO 3.5.7.2 LO 3.5.3.2 So I assume this has never be seen before. Windows 7 Home Premium. Set Status to NEW. Thanks for your report, Jacques
I'm sorry if I'm pushing a bug that is already known and handled /fixed under another ID, or pushing at all is unwellcome. But reading of the 4.3.4 RC And still not noticing any attention for this bug made me feel this to be necessary. As this bug is tricky, interupting workflow. And if you don't know of it and expect different things to be saved as they have been saved. There could be many cases where it even could harm statistical data and lead into harmfull results. So I think this should get more attention.
** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
** 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 on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Looks not resolved with Bug 119128. Repro 6.2+. Depending on how you edit, could be seen from subsequent edits.
Dear domenik.hein, 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
Repro 6.4+. As noted, the first time is correct behavior, more edits shows the bug.
Dear domenik.hein, 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
*** Bug 153750 has been marked as a duplicate of this bug. ***
Note the difference if the cell has just text or a formula: - bug visible on second go for text, as Timur mentioned - bug straight away visible in formula Timur reproduced on Linux back in 6.4+, which I can confirm from 6.4.7.2 to: Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded But not anymore in: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded So from what I can see, it is a "works for me" on Linux. However, on Windows 10, I can still reproduce in: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded and a recent master build. It was already present in: Version: 6.0.0.3 (x64) Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-GB (en_GB); Calc: group
I bisected the Linux fix with linux-64-7.2 repo to core commit e388a4d6d7ab355fc7aa5fca05e06070693847e9, which turns out is a GTK3-only fix: author Caolán McNamara <caolanm@redhat.com> Tue Mar 01 16:50:37 2022 +0000 committer Adolfo Jayme Barrientos <fitojb@ubuntu.com> Wed Mar 02 04:30:47 2022 +0100 tree 7f842d4e3888bd934be4293e2198e9262408f53a parent b228045cf3fb50128fd40a8f26376443ad22f874 Resolves: tdf#145580 need to use gtk_im_context_filter_keypress for at least xim, ibus works fine. To reproduce under Fedora with gtk3 can use a keyboard layout of "US International with dead keys" with export GDK_BACKEND=x11 export GTK_IM_MODULE=xim and 'a in writer comment or calc header/footer dialog Change-Id: I49425887dccc23c4fadf2bc007b6e83fc7993f7a The issue is still present for gen and kf5 VCLs in a recent master build (as well as for Windows). Caolán, copying you in just in case your GTK3 fix inspires ideas for a global fix? (In reply to Stéphane Guillou (stragu) from comment #10) > Note the difference if the cell has just text or a formula: > - bug visible on second go for text, as Timur mentioned > - bug straight away visible in formula Please ignore this bit. It does not depend on what kind of content is in the cell: very first insert action in session works as expected, all subsequent ones will display the bug.