Bug 84240 - EDITING: red squiggly underline does not appear instantly
Summary: EDITING: red squiggly underline does not appear instantly
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Deena Francis
URL:
Whiteboard: target:5.0.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2014-09-23 11:15 UTC by Dennis Francis
Modified: 2015-12-17 08:36 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (22.27 KB, image/png)
2014-09-28 19:36 UTC, raal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Francis 2014-09-23 11:15:30 UTC
How to reproduce ?

Type the word "foobar" into a cell say B1, and then copy it down say 20 times so you have a column of "foobar"

What is observed ?

The manually typed word "foobar" has red squiggly underline (RSU).
The rest of the cells with "foobar" in column B does not have RSU's, but they appear if the vertical scrollbar is used to scroll down.

Expected behavior ?

RSU should appear in a cell as soon as that cell is populated with content.


Libreoffice - 4.2.5.2
Operating system - Fedora Linux 20 64 bit / Mac OS X 10.6.8
Comment 1 tommy27 2014-09-28 17:12:47 UTC
I don't reproduce it under Win7 using LO 4.3.1.2
Comment 2 raal 2014-09-28 19:36:20 UTC
I can reproduce with Version: 4.3.3.0.0+
Build ID: 14907346d792f2f93a00083bbab5086cf56ddb24
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-09-26_03:56:08
Comment 3 raal 2014-09-28 19:36:57 UTC
Created attachment 107021 [details]
screenshot
Comment 4 tommy27 2014-09-29 05:00:36 UTC
@raal
now thanks to instructions in your screenshot i can reproduce the bug
Comment 5 Joel Madero 2015-01-11 06:19:29 UTC
This is a regression. But it's a bit tricky to bibisect as it went from "good" to "really bad" to "kind of okay" (which is where we are now). 

The first bibisect is when it went from good to really bad (which is not where we are now)

The second bibisect is when we went from really bad to "kind of okay" (i.e. where we are now).

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
# bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb
# bad: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b
git bisect bad e1d0365cd2b073a859f59ad0a4584385a66dc611
# bad: [98a55bf95f3ec29298751fd8fba76dd2236dce43] source-hash-58dfc97ca697875c36b7ddf14f5505a93d7b9cf8
git bisect bad 98a55bf95f3ec29298751fd8fba76dd2236dce43
# good: [92ca7e7dd4470107453ce3e99f3675387f91bf24] source-hash-ed5065d8b080bfaf51ea1232cebf3ff72af1e640
git bisect good 92ca7e7dd4470107453ce3e99f3675387f91bf24
# good: [c3997dfb709772c28f4b90559431662e3a81d651] source-hash-d803483f6a5938b0d0708b8db74b30c511dd8e31
git bisect good c3997dfb709772c28f4b90559431662e3a81d651
# good: [5d0e5af3cc4db0c25b97ec65cc5258b07daca350] source-hash-4f3012fc05fa0eeae412d9e2bfca3d7e60914a8c
git bisect good 5d0e5af3cc4db0c25b97ec65cc5258b07daca350
# good: [60932907a26d372fa1481b2249bb915e14dc94aa] source-hash-8df4ce0ebe1240ed8f6def3af8f810e3f207555f
git bisect good 60932907a26d372fa1481b2249bb915e14dc94aa
# first bad commit: [98a55bf95f3ec29298751fd8fba76dd2236dce43] source-hash-58dfc97ca697875c36b7ddf14f5505a93d7b9cf8
Comment 6 Joel Madero 2015-01-11 06:56:25 UTC
Second bibisect - from when it went from terrible to current state

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
# bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb
# good: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b
git bisect good e1d0365cd2b073a859f59ad0a4584385a66dc611
# skip: [8f55938c891ee3e4c252b193dba9419f130537bc] source-hash-93f3f72d18e551c8edd6a010cb78d9cbe404f8ef
git bisect skip 8f55938c891ee3e4c252b193dba9419f130537bc
# bad: [7518fcaf863962bf4f6f3cdf84f6e42f0f59225f] source-hash-ab1f5eab4830f00dbbd7c883b98b59975ecd3bb1
git bisect bad 7518fcaf863962bf4f6f3cdf84f6e42f0f59225f
# good: [2e56ba511184c20aa8ada64d35e9f1d27d596790] source-hash-8be2cbc856fb5ba61203872d8f01ed8162aa4256
git bisect good 2e56ba511184c20aa8ada64d35e9f1d27d596790
# good: [6738b3ad82bbc77ce9a788be07da490e530de3ff] source-hash-43fc67adcc3bdc5efaaaf9b0d65e53e99880b18a
git bisect good 6738b3ad82bbc77ce9a788be07da490e530de3ff
# good: [0e47d65bd5b2b2e544679d254078754fa456ce3d] source-hash-09e5de8278dd8f13adcf614db35c8a8a04ba8e47
git bisect good 0e47d65bd5b2b2e544679d254078754fa456ce3d
# good: [ac38fcace77aa0e6d8aaf421ff8cbd1273ba915c] source-hash-387b9122b049202164ba34a942e04c54a3b00120
git bisect good ac38fcace77aa0e6d8aaf421ff8cbd1273ba915c
# good: [05cfe9211144f539d265c8810ce992df34e6bfd1] source-hash-aee12451d1d99881833b9f6a1a6af5598802801a
git bisect good 05cfe9211144f539d265c8810ce992df34e6bfd1
# first bad commit: [7518fcaf863962bf4f6f3cdf84f6e42f0f59225f] source-hash-ab1f5eab4830f00dbbd7c883b98b59975ecd3bb1
Comment 7 Matthew Francis 2015-01-11 08:07:34 UTC
This isn't as reproducible as it seems at first glance. Sometimes you have to fill in two or more columns before the bug appears

I get a different result for the first transition:-

# first bad commit: [f2554751603ad8537257b3cf52d6171056c76eeb] source-hash-f42768fe0b60ecbbe9c68d775329bf28c0690131
Comment 8 Joel Madero 2015-01-11 08:27:10 UTC
For me the bug is 100% reproducible with Raal's steps (seen in his attachment)
Comment 9 Matthew Francis 2015-01-11 09:06:38 UTC
The first transition seems to occur at the below commit.
(It's surrounded by a lot more commits pertaining to spell checking, which may also be relevant)


commit 309c766d99cc7efc11fc439d119ba1944f2d710a
Author: Kohei Yoshida <kohei.yoshida@gmail.com>
Date:   Sun Sep 1 13:57:52 2013 -0400

    Separate misspelled ranges when entering a new cell value.
    
    And store them at appropriate locations.
    
    Change-Id: Iaf38c0cd01e9b3dc9dc98f7ccc1951d572a422e9
Comment 10 Matthew Francis 2015-01-11 09:45:13 UTC
The second transition, for the bibisect range of comment 6, happened at the below commit. It seems to me that this is not directly related to Calc, and fixing it may just have caused the Calc specific problem to be visible again?


commit 9705fbc1119da91e73c00a2ec848565929eeb483
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sun Mar 2 12:19:16 2014 -0600

    Fix editeng missing spellchecking redline on load
    
    Change-Id: I16bfbff85978702c93932d723180a7f9166bd39e
Comment 11 Joel Madero 2015-01-11 16:56:47 UTC
Norbert - seems like you partially fixed an issue introduced in commit 309c766d99cc7efc11fc439d119ba1944f2d710a. Any thoughts on getting it back to where it began?


Note: Attachment has best reproducible steps if you're looking to reproduce. Thanks!
Comment 12 Deena Francis 2015-02-17 14:15:15 UTC
I'd like to work on this to learn this part of the code. The approach I'm taking is to just look at the current code and understand it. By stepping through code in the debugger it appears that ScInputHandler::EnterHandler and callees are where the action is. This function is called when you type in text into a cell and it appears to work correctly then. It is also called when you extend a range using the mouse, however the RSUs do not appear. They do appear later when you (a) scroll the window (b) when you paste (using ctrl-v) into a new selection (c) resize the window. An interesting thing is that when you paste using ctrl-v ALL THE RANGES will repaint with the RSUs correctly (and slowly enough so that you can observe it). It will take me some time to learn the affected parts of the code base and understand how they cause these effects. If anyone has comments to guide me, I'd welcome them.
Comment 13 Joel Madero 2015-02-17 14:31:20 UTC
@Markus & Eike

Calc issue - either one of you have some time to help Deena out with some pointers?
Comment 14 Deena Francis 2015-03-14 21:12:12 UTC
Submitted a patch at https://gerrit.libreoffice.org/#/c/14872/
Comment 15 Commit Notification 2015-05-05 21:31:09 UTC
Deena Francis committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5c793b582e5afda68bb6acf7aa22f70c48f59b12

Resolves tdf#84240 : Red squiggly underline does not appear instantly

It will be available in 5.0.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 Robinson Tryon (qubit) 2015-12-17 08:36:12 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]