Bug 68961 - VIEWING: Cells scrolled in show contents of other cells.
Summary: VIEWING: Cells scrolled in show contents of other cells.
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: Other Linux (All)
: high minor
Assignee: Kohei Yoshida
URL:
Whiteboard: target:4.3.0 target:4.2.0
Keywords: bibisected, regression
: 72401 73007 73020 73500 73614 (view as bug list)
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2013-09-04 23:13 UTC by Terrence Enger
Modified: 2015-12-15 22:20 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
three screenshots (141.41 KB, application/vnd.oasis.opendocument.text)
2013-09-04 23:13 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2013-09-04 23:13:20 UTC
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.
Comment 1 Terrence Enger 2013-09-06 13:55:44 UTC
Removing keyword "regression" and keyword "bibisected" because it might be just my configuration which is the cause of the problem.
Comment 2 Joel Madero 2013-11-08 23:45:38 UTC
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
Comment 3 Joel Madero 2013-11-09 00:06:48 UTC
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
Comment 4 Terrence Enger 2014-01-08 15:41:23 UTC
*** Bug 73007 has been marked as a duplicate of this bug. ***
Comment 5 Jan Holesovsky 2014-01-09 09:17:11 UTC
Adding to MAB instead of bug 73007.
Comment 6 Kohei Yoshida 2014-01-10 01:28:38 UTC
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.
Comment 7 Commit Notification 2014-01-10 01:33:39 UTC
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.
Comment 8 Kohei Yoshida 2014-01-10 01:34:56 UTC
Request for 4.2 backport is underway: https://gerrit.libreoffice.org/7352
Comment 9 Commit Notification 2014-01-10 14:02:27 UTC
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.
Comment 10 Kohei Yoshida 2014-01-10 14:04:21 UTC
Fixed now.
Comment 11 Terrence Enger 2014-01-11 02:27:39 UTC
With master commit e36d8a6, fetched 2014-01-10 04:29 UTC, the proglem is fixed.

Thank you, Kohei.
Comment 12 Jean-Baptiste Faure 2014-01-11 09:37:27 UTC
Verified in 4.2.1.0+ too.

Best regards. JBF
Comment 13 Jean-Baptiste Faure 2014-01-11 15:37:18 UTC
*** Bug 72401 has been marked as a duplicate of this bug. ***
Comment 14 Jean-Baptiste Faure 2014-01-11 15:47:48 UTC
*** Bug 73500 has been marked as a duplicate of this bug. ***
Comment 15 Commit Notification 2014-01-11 16:12:30 UTC
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.
Comment 16 JPJ 2014-01-13 00:01:32 UTC
I have the same problem in 4.2.0.2 (4.2 RC 2).
Comment 17 Joel Madero 2014-01-13 04:47:44 UTC
It wasn't fixed in time for RC2 - it'll be fixed by stable
Comment 18 Kohei Yoshida 2014-01-14 20:48:57 UTC
*** Bug 73614 has been marked as a duplicate of this bug. ***
Comment 19 Chris 2014-01-24 20:26:49 UTC
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?
Comment 20 Kohei Yoshida 2014-01-24 20:29:38 UTC
Don't reopen this for Debian package.  Check with Debian.
Comment 21 Kevin Suo 2014-01-26 02:14:06 UTC
(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.
Comment 22 Thomas van der Meulen 2014-01-26 08:48:51 UTC
*** Bug 73020 has been marked as a duplicate of this bug. ***
Comment 23 Terrence Enger 2014-03-01 21:12:24 UTC
I see the problem is fixed in master 295bc87, fetched 2014-02-24.  Setting status VERIFIED FIXED.
Comment 24 Robinson Tryon (qubit) 2015-12-15 22:20:53 UTC Comment hidden (obsolete)