Cannot reproduce with Version: 5.1.0.0.alpha1+
Build ID: 6b7354ae66db40246a09e00aa876443057655a43
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-19_01:05:16

Created attachment 118234 [details]
Animated gif of screen not redrawing properly

Hmm.  I can reproduce using:

Version: 5.1.0.0.alpha1+
Build ID: ce0bba5fc1090caa7fb80f1bcc6ce64f67f11238
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-19_23:36:11
Locale: en-US (en_US.UTF-8)

I actually had a bit of trouble finding split/freeze, since they've now been moved under the "View" menu in the dev builds.  I'll need to test on another system, but this might be one of those bugs that is impossible to reproduce in window managers with fancy compositors which call for additional redraws.  I'm using pure X.  I'll test this again under a window manager with fancy desktop effects later.

I've uploaded a short gif of my experience using the version mentioned above.  Note at the end, I select the cell I just typed into and you can see the contents do show in the formula bar, but not in the actual cell.  Parts of the tooltip text also appear to stick around when the page scrolls up.

No repro Verze: 5.0.0.5
ID sestavení: 1b1a90865e348b492231e1c451437d7a15bb262b
Win7

Sorry, this one does appear to be tricky to reproduce.  I originally ran into it using a Fedora 21 thin-client connected to a RHEL6 server using xdmcp.  I was then able to reproduce it using a Fedora 20 laptop running pure X (no window manager, no compositing).  If I then enable compositing, by running xcompmgr, I can no longer reproduce the bug.  Finally, I was then able to reproduce it under KDE by disabling "desktop effects" (alt-shift-F12 to toggle), which disables compositing.

I don't have access to a native MS Windows machine right now, but I tried and failed to reproduce this under MS Windows 7 using VirtualBox.  In the past, I have been able to reproduce similar compositing bugs in MS Windows (Vista and earlier) by setting all visual effects to "best performance" (Control Panel->System->Advanced system settings->Performance).  I'll try a few more tests later, but we can probably mark this "Linux only."

It also appears that it's only reproducible when the cells have no direct formatting (using the default style).  So, one workaround is to select all affected cells and simply reapply the current font.  And once the cell's font has been changed, it will remain fixed for that session, even if you clear direct formatting.

Cannot reproduce with 5.1.2.1 on Linux.

I'm not too sure what is going on, but I can still reproduce using version 5.1.2.2 under Arch Linux.

Version: 5.1.2.2.0+
Build ID: 5.1.2.2 Arch Linux build-1
CPU Threads: 6; OS Version: Linux 4.5; UI Render: default; 
Locale: en-US (en_US.UTF-8)

Again, to reproduce, I have to disable compositing effects (alt-shift-f12 under KDE).  This means the bug might not be reproducible under many modern desktop environments like Unity, Cinnamon, Gnome3, XFCE, etc...  Which environments (window managers/desktop environments/compositing effect settings...) are you guys running when you can't reproduce?

I used Ubuntu 15.10 and MATE desktop with marco window manager. I disabled the compositing. Still cannot reproduce.

I just installed MATE 1.12.1 on a 64bit fedora 23 machine.  With marco and compositing disabled, I was able to reproduce the bug using the fedora included LO 5.0.5.2.  To test if my repro steps were unclear, I had a coworker running IceWM under Fedora 21 using LO 4.4.5.2 reproduce the bug from this report.

Sorry that you're having trouble reproducing, but I'm still pretty sure this bug is still valid.

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.

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.

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

(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.

Thanks for the explanation of the use case. Bumping the importance seems right.

Dear tmacalp,

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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug