Repro.
Version: 6.2.3.2 (x64)
Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: es-ES (es_ES); UI-Language: en-US
Calc: CL
Version: 6.3.0.0.alpha0+ (x64)
Build ID: 3083fe569f96bf0289da1e9d0ef7da15ab22e2f6
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-16_03:05:57
Locale: es-ES (es_ES); UI-Language: en-US
Calc: CL

Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=632bc11ce8fab1c4046ab24810b90a7ce9ac5914

author	Maxim Monastirsky <momonasmon@gmail.com>	2018-04-24 01:23:33 +0300
committer	Maxim Monastirsky <momonasmon@gmail.com>	2018-04-27 13:35:38 +0200
commit 632bc11ce8fab1c4046ab24810b90a7ce9ac5914 (patch)
tree bca77bf682485765350e3db57afcb71ca493a648
parent 2815499d7c0b32fa05fcd697e7b2c2d897f78dfb (diff)
tdf#117017 Pasting into the formula bar shouldn't retain formatting

Bisected with: bibisect-linux64-6.1

Adding Cc: to Maxim Monastirsky

(In reply to Xisco Faulí from comment #2)
> Regression introduced by:
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=632bc11ce8fab1c4046ab24810b90a7ce9ac5914
Are you sure this has anything to do with this commit? I seem to reproduce the same behavior with much older builds too (I tested 6.0.0.3, 5.4.3.2, 4.4.0.3).

Exact steps, just to make sure we're testing the same thing:

1. Open the file. Cell A3 is selected.
2. Press Shift+Ctrl+F2 to enter the input line.
3. Press Insert to activate overwrite mode.
4. Press ESC to leave the input line.
5. Press Shift+Ctrl+F2 to enter the input line again.
6. Move the cursor over the 'A' letter with the arrow keys.
7. Press 'b'.

Is these steps correct? If yes - could you please test again? It not - please give exact steps, as I couldn't reproduce the problem in any other way.

funny thing, 

repro in: 

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4
CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04
Locale: de-DE (de_DE); UI-Language: en-US
Calc: *unthreaded*

on first try it looked like 'no repro', started described behaviour after first use of ctrl-shift-F2 to enter edit (first try had been just clicking in the edit-bar) and persisted after that also when switching back to enter with mouseclick. 

bibisection looks wrong, 

also repro with ver: 

Version: 4.1.6.2
Build ID: 40ff705089295be5be0aae9b15123f687c05b0a

but! ... not on first try, but on second!

used a new file and entered '=A1' in cell A3

reg. 

b.

additional, don't know if intentional, 

in both above versions switch to overwrite mode is persistent from one edit to the next for the edit-bar, but not! for a cell, cell edit always starts in insert mode. 

reg. 

b.

This bug is tricky.

1: select A3
2: click before A on InputLine, in Overwrite mode (Note); cell A3 goes into edit mode, with cell A1 highlighted;
3: hit key b: A is replaced with b in editLine, but not in cell A3: '=bA1'. Bad.
	However, if the initial mode is Insert in step 2 when editing begins (Note), hit Ins to set mode to Overwrite; now, highlighting of cell A1 disappears, and step 3 gives the correct result: '=b1'.
	Note: The initial mode is important: hit Esc to end editing, then click the editLine for a 'fresh' edit in the last mode (Insert or Overwrite), which is now the initial mode.

Thanks for confirming. So as said, it has nothing to do with my commit. Removing 'regression', 'bibisected' keywords, and setting 4.1.6.2 as the earliest affected version.

still wrong with: 

Version: 6.4.0.3 (x64)
Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc:

Version: 7.2.5.2 (x64) / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-CA (en_CA); UI: en-US
Calc: CL