Bug 82599 - Insert and overwrite mode reversed in cell while editing on the Calc Formula bar
Summary: Insert and overwrite mode reversed in cell while editing on the Calc Formula bar
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 153750 (view as bug list)
Depends on:
Blocks: Calc-Formula-Bar
  Show dependency treegraph
 
Reported: 2014-08-14 07:06 UTC by domenik.hein
Modified: 2023-03-07 05:53 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
A picture that proofs the different output of the same cell (6.19 KB, image/png)
2014-08-14 07:06 UTC, domenik.hein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description domenik.hein 2014-08-14 07:06:04 UTC
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
Comment 1 Jacques Guilleron 2014-08-22 14:08:01 UTC
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
Comment 2 domenik.hein 2014-11-12 07:35:52 UTC Comment hidden (no-value)
Comment 3 tommy27 2016-04-16 07:26:51 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2017-05-22 13:23:10 UTC Comment hidden (obsolete)
Comment 5 Timur 2018-08-20 07:54:49 UTC
Looks not resolved with Bug 119128. Repro 6.2+.
Depending on how you edit, could be seen from subsequent edits.
Comment 6 QA Administrators 2019-09-02 09:21:28 UTC Comment hidden (obsolete)
Comment 7 Timur 2019-09-03 12:57:23 UTC
Repro 6.4+. As noted, the first time is correct behavior, more edits shows the bug.
Comment 8 QA Administrators 2021-09-03 04:03:31 UTC Comment hidden (obsolete)
Comment 9 Stéphane Guillou (stragu) 2023-03-06 18:13:16 UTC
*** Bug 153750 has been marked as a duplicate of this bug. ***
Comment 10 Stéphane Guillou (stragu) 2023-03-06 18:25:47 UTC
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
Comment 11 Stéphane Guillou (stragu) 2023-03-07 05:53:13 UTC
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.