Created attachment 85213 [details] three screenshots When you use a scrollbar to move the view into spreadsheet, cells scrolled in at the edge of the window show not the value they contain, but the value of the cell which previously was at the edge of the window. Steps to reproduce: (1) In an empty spreadsheet, position to cell A1 and enter sixteen columns of data: Now<tab>is<tab>the<tab>time<tab>for<tab>all<tab>good<tab>men<tab> to<tab>come<tab>to<tab>the<tab>aid<tab>of<tab>the<tab>party<enter>. (2) Position to cell A3 and enter sixteen rows of data: Now<enter>is<enter>the<enter>time<enter>for<enter>all<enter>good<enter> men<enter>to<enter>come<enter>to<enter>the<enter>aid<enter>of<enter> the<enter>party<enter>. (3) Position to cell A1. (4) Unmaximize the window if is maximized, and reduce it to show four columns and a bit and 10 rows. Result is shown in screenshot in the attachment (5) Drag the horizontal scrollbar to the right until column D is at the left edge of the window, and continue to hold the mouse button down. Expected result: cells D1 through G1 should show values "time", "for", "all", "good". Actual result: cells D1 through G1 show values "time", "for", "for", "for". Result is shown in screenshot in the attachment. (6) Release the mouse button. The displayed values are as expected. (7) Position to cell A1. (8) Drag the vertical scrollbar until row 4 is at the top of the data area and continue to hold the mouse button down. Expected result: cells A3 through A12 should show "is", "the", "time", "for", "all", "good", "men", "to", "come", "to". Actual result: cells A3 through A12 show "is", "the", "time", "for", "all", "good", "men", "to", "to", "to". Result is shown in screenshot in attachment. (9) Release the mouse button. The displayed values are as expected. My LibreOffice is commit 939693b, pulled 2013-09-03 12:38 UTC, configured with --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --without-help --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --disable-werror built on ubuntu-natty (11.04) 32-bit, and executing on both that system and ubuntu-quantal (12.10) 64-bit. For comparison, the problem is not evident in daily bibisect (updated 2013-07-16) version `latest`. I am assigning low priority because (a) The possibilty for confusion is brief. (b) The confusion can be avoided by watching the column and row headings instead of cell contents while scrolling. (c) I was looking for trouble when this happened. <grin /> Anybody actually inconvenienced by the behaviour is welcome to raise the priority back to normal.
Removing keyword "regression" and keyword "bibisected" because it might be just my configuration which is the cause of the problem.
Indeed - attaching a test document so next person doesn't have to type all that out ;) Marking as NEW While I agree it's minor (no data loss) it is a regression so I think minor-high is appropriate. Going to try to bibisect it now
f5ac2f724a49dc002f9fc6be7afe17f741cc7f8f is the first bad commit commit f5ac2f724a49dc002f9fc6be7afe17f741cc7f8f Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Fri Oct 18 07:35:26 2013 +0000 source-hash-dca003a486acb63ea7ba6aaba94f6c9d3715b004 commit dca003a486acb63ea7ba6aaba94f6c9d3715b004 Author: Matúš Kukan <matus.kukan@gmail.com> AuthorDate: Mon Jun 17 15:41:34 2013 +0200 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Mon Sep 9 22:08:59 2013 +0200 install images with filelists Change-Id: I3946b44838c659cad12d288c8a1ed5137c3e554e :100644 100644 a18229d33ca4eb27f5eab4ca4f0f9bb2e0be5edf 5193bfaec02ff1244ddff721bb4d35c7ba38097c M ccache.log :100644 100644 421d7f829e6c80f4807e9a94194ac2e6572a300e 08801cbdb474993c2d6950e28df083146a69034c M commitmsg :100644 100644 304ace99817feb95174f2495acf131557391d336 9761c01d435cf318c105affea28af359a0b02409 M dev-install.log :100644 100644 80d286b683b673d2a90e0ea3d07b47a728e6a0de eaceb6e288ddff95db8cc6cc326e1a01398fa7b9 M make.log :040000 040000 a8850b2f33a368a3d2d87439936928ceb6cb4fb1 d89f8fb8f4560104e92f5f7d9c09f649a03749d2 M opt # bad: [25428b1e953636f74986622c5df614f04c150ed1] source-hash-cb4e009c4539c535108021934e545194b35cad9d # good: [f0f6c65eb764f0303f59c58d320e9b0d5a894377] source-hash-4b9740b4ec3987e1d4d2ad6d20b4dcf996a4fa2e git bisect start 'latest' 'oldest' # good: [a72833796a7e527d9efc9ca6d8fe9b579e469105] source-hash-1472b5f87314fe660ef1a7b254e51272669f12f6 git bisect good a72833796a7e527d9efc9ca6d8fe9b579e469105 # good: [b21386bf459ae47bd6e461ea94cea6a06729a1ff] source-hash-570fe620e9d573cfc9fc260e6518563c6a6c1a3c git bisect good b21386bf459ae47bd6e461ea94cea6a06729a1ff # good: [091d742e82f2b4608690c697d14f846ffc9164c7] source-hash-349c91c8ec6afc1f5c8499529d559af34d115a76 git bisect good 091d742e82f2b4608690c697d14f846ffc9164c7 # good: [14568733447b0c4b9218b7258182594ee4e9ad6e] source-hash-d3ff876f3c7f441fd72a037ed31fb973f223ca6d git bisect good 14568733447b0c4b9218b7258182594ee4e9ad6e # bad: [f5ac2f724a49dc002f9fc6be7afe17f741cc7f8f] source-hash-dca003a486acb63ea7ba6aaba94f6c9d3715b004 git bisect bad f5ac2f724a49dc002f9fc6be7afe17f741cc7f8f # good: [42c3b422339a4d15dd66dcdb7e7662b348f36307] source-hash-d261ddf3c8e76b44b07ea8be69234a123d2f4271 git bisect good 42c3b422339a4d15dd66dcdb7e7662b348f36307 # good: [e591a26e04a66d7fd2b8f17b0027a988e6dc8b03] source-hash-7be7824bbbdeee6fa998b950e6046ab37fe690cb git bisect good e591a26e04a66d7fd2b8f17b0027a988e6dc8b03
*** Bug 73007 has been marked as a duplicate of this bug. ***
Adding to MAB instead of bug 73007.
I have no clue what change could've introduced this, and that bibisect "bad" commit makes no sense at all. Anyway, I have a pretty simple commit that fixes this.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e36c8a674845ab19577fc06d44b780549757e1e7 fdo#68961: Check visible range during scrolling, and re-paint if necessary. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Request for 4.2 backport is underway: https://gerrit.libreoffice.org/7352
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f349d3240115651346da04daeb3459b31782301&h=libreoffice-4-2 fdo#68961: Check visible range during scrolling, and re-paint if necessary. It will be available in LibreOffice 4.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed now.
With master commit e36d8a6, fetched 2014-01-10 04:29 UTC, the proglem is fixed. Thank you, Kohei.
Verified in 4.2.1.0+ too. Best regards. JBF
*** Bug 72401 has been marked as a duplicate of this bug. ***
*** Bug 73500 has been marked as a duplicate of this bug. ***
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=02404b1d3ad2120fc803e40ceab303fff86a408b&h=libreoffice-4-2-0 fdo#68961: Check visible range during scrolling, and re-paint if necessary. It will be available already in LibreOffice 4.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have the same problem in 4.2.0.2 (4.2 RC 2).
It wasn't fixed in time for RC2 - it'll be fixed by stable
*** Bug 73614 has been marked as a duplicate of this bug. ***
Hi LibreOffice 4.2.0.3 Build ID: c63c03decdf780d8fb80823950665b782ec9ecd0 Windows 7 & 8 - fixed, work fine. Linux (Debian) - no changes, still buggy. Needs someone to confirm?
Don't reopen this for Debian package. Check with Debian.
(In reply to comment #19) > Linux (Debian) - no changes, still buggy. > Needs someone to confirm? Tested in Ubuntu 13.10 x86 and confirm it's fixed.
*** Bug 73020 has been marked as a duplicate of this bug. ***
I see the problem is fixed in master 295bc87, fetched 2014-02-24. Setting status VERIFIED FIXED.
Migrating Whiteboard tags to Keywords: (bibisected) Remove redundant 'ConfirmedRegression' [NinjaEdit]