I do not get the text prediction as I typed "a" in cell B1; from the description step 4.


Not reproducible in:

Version: 7.4.0.0.alpha1+ / LibreOffice Community
Build ID: f572585756494c59fb81f5d93c51cc2d35421f0e
CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: en-NG (en_NG); UI: en-US
Calc: threaded

No repro with Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: cfc8a8f5d841b3f84d207196153be67da7f60652
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.6.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ
Ubuntu package version: 1:7.3.6-0ubuntu0.22.04.2
Calc: threaded

For me, the autoinput is working per column and it doesn't pick up strings from other columns. I don't see any of the behaviour you describe.

Do you still see this in 7.5? One way to test on Linux is an appimage: https://www.libreoffice.org/download/appimage/

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.

Arch Linux 64-bit, X11
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f12e547c42103a3b934b393b6b63c2b096bbd06e
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 24 February 2023

(In reply to QA Administrators from comment #5)
> Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
> a lack of information which is needed in order to accurately
> reproduce and confirm the problem.
Apologies for the lack of activity.

I have completed a retest using the **exact steps** I provided in the original report, and they still reproduce the bug 100% of the time. As I said, a PHB could reproduce this. :-)

> a) Provide details of your system including your operating
>    system and the latest version of LibreOffice that you have
>    confirmed the bug to be present
Linux Mint 22

Version: 24.2.5.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-CA (en_CA.UTF-8); UI: en-US
Ubuntu package version: 4:24.2.5-0ubuntu0.24.04.2
Calc: threaded

I'll keep a closer eye on this. Let me know if other details are required.

NOTE: Since the original report I've built and moved to a new PC, on which, I started with Linux Mint 21.3 (was Ubuntu 18.04 on my old PC) and upgraded to Linux Mint 22 since. This _strongly_ implies to me that the issue is a Real Bug in Calc.

> b) Provide easy to reproduce steps – the simpler the better
The **exact** steps in my original report reproduce the bug 100% of the time.

> d) Provide screenshots of the problem if you think it might help
If someone can suggest a screen-video-capture tool, I'll provide a video of the issue occurring.

> e) Read all comments and provide any requested information
Done.

> Once all of this is done, please set the bug back to UNCONFIRMED
> and we will attempt to reproduce the issue.
Done.

(In reply to Ezinne from comment #1)
> I do not get the text prediction as I typed "a" in cell B1; from the
> description step 4.
I'm using stock Calc, 99%.

I've added a single toolbar button to run a macro.

I've customized [shift ctrl :] to [Insert Current Time] per https://bugs.documentfoundation.org/show_bug.cgi?id=126888#c27

That's it.  
  
I do not know why text prediction does not work for you. I agree that without text prediction working, the bug can't be invoked. The bug exists nevertheless.

(In reply to Buovjaga from comment #3)
> For me, the autoinput is working per column and it doesn't pick up strings
> from other columns. I don't see any of the behaviour you describe.
You'll notice that the problematic text prediction in my original report is by column. A1 contains a sample string. A2 is where the prediction occurs.

> Do you still see this in 7.5?
Still occurring in current LibreOffice, see my recent comment.

> One way to test on Linux is an appimage:
> https://www.libreoffice.org/download/appimage/
Note: With the AppImages, there is an extra starting step of "Click 'Create: Calc Spreadsheet'". This extra step does not change the bug behaviour.

NOTE: AppImage variant type is not reflected in the version info. That's probably a bug. I really did download and try all three variants:

user@home:~/Downloads/LibreOffice$ ls -alF
total 1067736
drwxrwxr-x 2 stuart stuart      4096 Aug 27 11:26 ./
drwxr-xr-x 4 stuart stuart      4096 Aug 27 11:25 ../
-rwxrwxr-x 1 stuart stuart 286495936 Aug 27 11:25 LibreOffice-fresh.basic-x86_64.AppImage*
-rwxrwxr-x 1 stuart stuart 471954624 Aug 27 11:26 LibreOffice-fresh.full-x86_64.AppImage*
-rwxrwxr-x 1 stuart stuart 334881984 Aug 27 11:26 LibreOffice-fresh.standard-x86_64.AppImage*

AppImage, Basic:
Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Calc: threaded

Bug is reproducible 100%

AppImage, Standard:
Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Calc: threaded

Bug is reproducible 100%

AppImage, Full:
Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Calc: threaded

Bug is reproducible 100%

Updated glxinfo:

glxinfo | grep OpenGL
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 5500 XT (radeonsi, navi14, LLVM 17.0.6, DRM 3.57, 6.8.0-41-generic)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.9-0ubuntu0.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.9-0ubuntu0.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.9-0ubuntu0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

(In reply to studog from comment #8)
> (In reply to Buovjaga from comment #3)
> > For me, the autoinput is working per column and it doesn't pick up strings
> > from other columns. I don't see any of the behaviour you describe.
> You'll notice that the problematic text prediction in my original report is
> by column. A1 contains a sample string. A2 is where the prediction occurs.

That only means that all your prior mentions of "exact steps" (with or without additional symbols) are incorrect, as your "step 4" in comment 0 points to the wrong cell address, which explains why other users cannot replicate the behavior.

As for the behavior you described, I am guessing that redrawing every pixel of every cell and every layer for every individual inserted character (or any kind of edition), and also for every AutoInput reaction, and for every Spell-check reaction, would result in an unbearable low performance (or unreasonable request for additional resources).

After [ENTER], a screen refresh is effectively and successfully done, as expected.

Moreover, similar issues are seen when editing a (long) formula within a cell, which makes it not-so-easy to click on adjacent cells (for instance, to use such adjacent cell as argument of a function).

Whichever the content of a cell, it has to take priority over other layers on screen, until the edition of the cell is finalized.

The behavior also depends on cell's alignment.

IMNSHO, this is a very minor issue.

Corrected steps:

1. New spreadsheet in Calc
2. Enter this in A1: a very long sentence about dogs, jumping and foxes
3. Enter this in B2: don't hide me
4. Enter this in A2: a
5. Hit Backspace to cancel the AutoInput

This is already seen in 3.5.0, so probably inherited.

I noticed a newer glitch and reported it as bug 162651.

I guess we can accept this, if this can be changed while not affecting performance.

(In reply to ady from comment #10)
> That only means that all your prior mentions of "exact steps" (with or
> without additional symbols) are incorrect, as your "step 4" in comment 0
> points to the wrong cell address, which explains why other users cannot
> replicate the behavior.
_arg_ You are correct. This is a case of me reading what I expected I had written instead of what I actually wrote. Thanks for the spot. It doesn't look like I can edit that comment to fix it though.

> As for the behavior you described, I am guessing that redrawing every pixel
> of every cell and every layer for every individual inserted character (or
> any kind of edition), and also for every AutoInput reaction, and for every
> Spell-check reaction, would result in an unbearable low performance (or
> unreasonable request for additional resources).
I disagree. This should be pretty quick: on drawing the prediction, save the underlying graphics state; on cancelling the prediction, restore the state.

> After [ENTER], a screen refresh is effectively and successfully done, as
> expected.
Correct. There is a workaround.

> Whichever the content of a cell, it has to take priority over other layers
> on screen, until the edition of the cell is finalized.
This is the point though. The predicted text is not content, and once cancelled does not exist. What it was covering should be redrawn.

> IMNSHO, this is a very minor issue.
I agree the priority is low, given the workaround.

(In reply to Buovjaga from comment #11)
> I guess we can accept this, if this can be changed while not affecting
> performance.
It arose for me when I was filling in a large amount of data, where the data was dependent on the data that the prediction draws over, and the prediction is not itself valuable.

To use the workaround added quite a lot of extra work, and an exponential amount of user frustration. I'd have to cancel the input altogether, then memorize the drawn-over data or copy it to somewhere that wouldn't be overdrawn, then, restart the data input, then clear the copy if I'd done that. For every input, and I had a lot of them. 1,000s or 10,000s of rows.

Not only more work, but much longer to complete the job.  
  
So, even with a workaround, a large impact to affected users, even if the percentage of users affected is slow.

(In reply to studog from comment #13)
> Not only more work, but much longer to complete the job.  
>   
> So, even with a workaround, a large impact to affected users, even if the
> percentage of users affected is slow.

Workaround:

1. Before introducing the new data, select the cells (e.g. entire column "A" in the STR).
2. Set the cell alignment to "Right".
3. Introduce the new data to all the relevant cells.
4. Select the relevant cells again.
5. Change the cell alignment as you want/need.

With that "step 2", the adjacent cell on the right of the active cell will not be overdrawn by the text being inserted. You can introduce those 1000s of new entries while the adjacent cells are all entirely seen.

The same workaround is relevant for formulas, because you can temporarily modify the cell alignment during edition.

(In reply to ady from comment #14)
> With that "step 2", the adjacent cell on the right of the active cell will
> not be overdrawn by the text being inserted. You can introduce those 1000s
> of new entries while the adjacent cells are all entirely seen.
> 
> The same workaround is relevant for formulas, because you can temporarily
> modify the cell alignment during edition.

Thanks for the tip. My need has passed. Others may discover this in the future.

There's no way I would have thought to try the alignment as a workaround.