Created attachment 102486 [details] Test ODS file LibreOffice 4.2.5 Windows 7 64bit Problem isn't present in 4.1.6 so it's introduced in 4.2. Load test ODS file. Select columns B:H (by clicking on column letter so you select whole column). Delete columns B:H. Expected result: Only column A should be visible, everything else should be empty cells. Result: Column A is visible, but also some reminents of deleted columns, check attached picture. Clues: It has something to do with column width. 1. If I set WHOLE SHEET columns to AUTO width (marking whole sheet and then double click between any two columns), problem isn't present any more. 2. If I set every column in sheet to same width (marking whole sheet and then set width for any sigle column), problem isn't present any more. Problem is visible only when some columns have different width then other and that isn't result of auto-width column option.
Created attachment 102487 [details] Result after deleting columns in test.ods
Same applies when deleting rows also.
Confirm same behavior in 4.2.5.2 and 4.3.0.2 - Ubuntu 12.04 x86 Mouse scrolling or minimize/maximize window resolves the display glitch
Hello, I can reproduce with Version: 4.3.1.0.0+ Build ID: ca88a0ea6ed7277e8522d83458e3cfb975fcfb7d TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-07-25_10:06:25 but can not reproduce with Version: 4.4.0.0.alpha0+ Build ID: 613cc91bb5c169ad5294f04567df526d2181a6f9 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-08-16_22:57:54 Seems to be fixed. Please, could you retest with dev version?
This appears to have been fixed by the below commit. It's already in 4.4 and 4.5 master, but doesn't seem to be in 4.3 - not sure if it's a good candidate or not Removing Whiteboard:bibisectRequest, adding fixedInMaster commit 642d64d8fe54b7577fb4184f1ad6e0e8b3f809c4 Author: Caolán McNamara <caolanm@redhat.com> Date: Tue Jul 15 16:42:42 2014 +0100 scrolling very slow in calc even on a short spreadsheet scrolling up and down leaves the first/last row (depending on the direction of scroll) unchanged until the scrolling stops. http://people.freedesktop.org/~mst/calc_4.2_scrolling.webm On larger document there are rendering artifacts during scrolling which go away after scrolling for me and mstahl, but a bunch of people can show us piles of horribly broken spreadsheets after scrolling, esp wheel scrolling Revert "fdo#75026: Sometimes we need to update grid view... while not being active." This reverts commit 52cc88d6191ba0c4b6477e5c4b9c5d0f0228030d. Revert "fdo#68961: Check visible range during scrolling, and re-paint if necessary." This reverts commit e36c8a674845ab19577fc06d44b780549757e1e7. Revert "Repaint grid view when the visible area changes." This reverts commit b54c1a53b4d400b1c2d282c186af1fa8f151894e. Conflicts: sc/source/ui/app/scmod.cxx Revert "Update visible ranges when updating the scroll bars." This reverts commit 391a57ef65687f2e373bac8d410e551aafa780ec. Change-Id: Ie170308cba18a9a74c7c72daf07dfa0a4ef7bd13 Reviewed-on: https://gerrit.libreoffice.org/10350 Tested-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Kohei Yoshida <libreoffice@kohei.us> Tested-by: Kohei Yoshida <libreoffice@kohei.us>
As far as I can see, it's fixed in 4.4 beta 2. Should probably be ported back to 4.3 if possible.
Replacing fixedInMaster with backportRequest. 4.2 is EOL, and this is fixed in 4.4 and 4.5 (master), so Whiteboard -> backportRequest:4.3
TESTING with Ubuntu 14.04 (In reply to Mikeyy - L10n HR from comment #0) > Load test ODS file (attachment 102486 [details]). > Select columns B:H (by clicking on column letter so you select whole column). > Delete columns B:H. Deleted column contents using Edit -> Delete Cells. > Expected result: > Only column A should be visible, everything else should be empty cells. > > Result: > Column A is visible, but also some reminents of deleted columns, check > attached picture. Looks like it's still a problem with the latest 4.3 build: 4.3.6.1: CONFIRMED: vestigal data left on right-hand side in spreadsheet (clears away if I arrow over several columns and back) 4.3.5.2: CONFIRMED 4.3.2.2: CONFIRMED Just to double-check: 4.4.0.2: NOREPRO So fixed in latest version: Status -> RESOLVED WORKSFORME (In reply to Matthew Francis from comment #5) > This appears to have been fixed by the below commit. It's already in 4.4 and > 4.5 master, but doesn't seem to be in 4.3 - not sure if it's a good > candidate or not > > Removing Whiteboard:bibisectRequest, adding fixedInMaster I guess we don't need a bibisect? Whiteboard -> bibisectNotNeeded (not sure we have a standardized tag for this)
unfortunately nobody saw that backport request, 4.3 is EOL now
Migrating Whiteboard tags to Keywords: (bibisectNotNeeded) [NinjaEdit]