https://bugs.documentfoundation.org/show_bug.cgi?id=93123

--- Comment #11 from tmacalp <[email protected]> ---
(In reply to mahfiaz from comment #10)
> Yep, I finally am able to reproduce it.
> 
> It turns out my habit to close parenthesis of expressions failed me this
> time. You should type =SUM(<drag with mouse><Enter>, otherwise the tooltip
> is hidden before the scrolling takes place.

Thanks for retesting!  I'm really not looking specifically for the actual
tooltip artifacts.  The main problem is that calc shows our recently input
formulas as EMPTY cells.

I still trigger the bug a number of ways... even after closing the parenthesis.
 For example,
=sum(<drag with mouse>)<enter>

As long as I've selected a range, I can even modify the formula and trigger the
bug.
=sum(<drag with mouse>)+5*7<enter>

Even without the mouse, use the arrow keys to select a range, as long as that
range doesn't include the cell directly over our formula range.
=sum(<arrow over to start of range><shift-arrow to select range>)<enter>

It still shows as an empty cell.  Basically, I trigger this bug using any
graphical method of selecting a range when inputting a formula in the last
visible row of a sheet and completing it with <enter>.

> In its current form this takes place only if you drag with your mouse. Click
> to select, just typing or numerous other sequences won't cause this.
> Therefore lowering it's importance.

I don't believe this is as isolated as you thinking.  The user I was helping
when I discovered this bug is quite advanced.  When she ran into this, she was
inputting formulas down a column while summing various regions in the sheet. 
She then realized her entire column was blank and other numbers in that pane
were in the wrong cells.  Her workaround for now is to keep scrolling so her
active cell is never at the bottom of the screen.  If she does corrupt her
screen, she minimizes/restores to get the pane to redraw properly.

If you're not expecting this bug, it can lead to some very confusing and
error-prone situations.  According to the prioritizing bug flowchart, I'd argue
it at least warrants a "makes it substantially harder to make high quality work
or requires users not to use some features" (Medium/Minor).  Then the priority
should potentially even be bump because it's a recent regression.  But I'll
leave the QA to others.

> That said there are other similar strange cases when tooltips, parts of
> selection area borders and possibly more are left behind.

I also found that you can reproduce this bug in the bottom visible row of the
upper right quadrant of a split sheet by pressing <enter>.  It's also possible
to reproduce if you select a cell in the right-most visible column and end the
formula with <tab>.  My guess is it's another case where someone didn't
consider the case for redrawing all panes of a split/frozen window.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to