Bug 141749 - Text Tearing, Font Shrinkage, and Line Shifting bug related to use of Sidebar
Summary: Text Tearing, Font Shrinkage, and Line Shifting bug related to use of Sidebar
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Kerning
  Show dependency treegraph
Reported: 2021-04-18 21:48 UTC by Eek! A Bug. Kill it!
Modified: 2023-06-18 03:14 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Eek! A Bug. Kill it! 2021-04-18 21:48:34 UTC
The so-called text tearing bug seems to be a side effect of having the View>Sidebar option checked, regardless of whether or not the sidebar is maximized, in minimized tab view, or hidden (a tiny sliver of it is still there to indicate the left-pointing Show arrow alongside the vertical scroll bar that’s used to expand the sidebar). There is an exception to this and that is if the sidebar is docked to the left-hand side of the monitor screen, then the bug no longer manifests itself.

I say so-called text tearing bug because that is only one symptom of this particular bug. There are times when the text does indeed seem to tear across either an entire line of text as you are scrolling up/down through a document or just a highlighted section of text when using the Clone Formatting tool, but more often than not the issue is that the lines of text shrink in height (sometimes only marginally, sometimes rather significantly).

Note: Some users may NOT notice this bug because they are using 100% screen layout view. The bug is far more noticeable if using the Fit Width or Optimal Zoom Factor settings, as the problem is thus magnified. Also, some shorter documents do not seem to ever demonstrate the above mentioned symptoms.

Also of importance in replicating the bug is that you do NOT actually have to see the text tearing or font shrinkage to know it is there. The tell-tale sign of the bug is line shifting, which you can easily see and verify for yourself by scrolling down a document to a point, then Toggle Automatic Spell Checking. Of course the red and blue squiggly lines indicating a spelling or grammatical error will come and go, but the text lines should be rock solid, but if they shift up or down even slightly—then you are experiencing the bug.

So, the short-term, band-aid "fix" is to deselect the View>Sidebar option (Ctrl+F5) until someone delves into the source code for a permanent fix.

Steps to Reproduce:
1. Select a long, heavily formatted document (headers, lists, tables, etc.)
2. Either select text for formatting, scroll vertically, or toggle automatic spell checking after scrolling (first two in particular are intermittent)

Actual Results:
Text tearing while selecting text, font shrinkage after scrolling, and line shifting when toggling automatic spell checking.

Expected Results:
No text tearing, font shrinkage, or line shifting during use.

Reproducible: Sometimes

User Profile Reset: Yes

Additional Info:
Version: (x64) / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 1 Eek! A Bug. Kill it! 2021-04-19 19:24:12 UTC
With regards to my initial bug post, which I tried to keep as concise and to the point as possible, there are a couple of things I thought went without saying but perhaps should have been explicitly stated for completeness.

One, since I maintain that the three issues this bug causes are all seemingly related to the sidebar being docked to the right-hand side of the monitor screen—but not to the left-hand side, then undocking the sidebar and leaving it to float is also a “solution”. However, it is doubtful that either of those “solutions” would be something any user would do because, in the former case, there already is an apparently unmovable media sidebar located there and, in the latter case, due to the sheer size and shape of the “sidebar”, having it floating is not a viable solution as it would block too much of the workspace. 

Two, since having no sidebar on the right-hand side of the monitor screen is a “solution”, then changing the view from Normal to Web or Full Screen are also “solutions.” Again, it is doubtful that many users would use the Web view because the margins are, at least for me, annoyingly too close to the edges of the screen for easy reading (at least with larger font sizes) and the Full Screen view lacks title and menu bars that users might want access to (unless you happen to know all the shortcuts off the top of your head).

So, the best temporary “solution” would seem to be to deselect the Sidebar option from the View drop-down menu and, if you need the functionality of the Navigator, for example, then access it via the View drop-down menu until a permanent software solution is found.
Comment 2 Xisco Faulí 2021-04-22 09:44:11 UTC
Thanks for reporting this issue.
Could you please attach a screenshot of the problem ?
Comment 3 Eek! A Bug. Kill it! 2021-04-28 17:04:28 UTC
(In reply to Xisco Faulí from comment #2)
> Thanks for reporting this issue.
> Could you please attach a screenshot of the problem ?

The line shifting cannot be captured in a screenshot because it's transitory, so only a video would be able to show the lines shifting vertically. The other symptoms have been written up a number of times in the past as text tearing, although that term does not adequately encompass the three related issues. Since those other two issues are intermittent, it's best to work on the line shifting issue because it's much easier to replicate.
Comment 4 Eek! A Bug. Kill it! 2021-05-10 16:26:41 UTC
It appears nobody has yet taken an interest in finding the cause of these three related issues I described above. Not using the sidebar seemingly eliminates the text tearing issue and greatly reduces the occurrences of, and minimizes the severity of, the font shrinkage and line shifting issues. I have also noticed that deselecting the Toggle Automatic Spell Check before scrolling a document seems to at the very least minimize, if not eliminate, the font shrinkage and line shifting issues. So, the combination of the two (not using the sidebar and not scrolling with the Toggle Automatic Spell Check selected) seems to be an effective band aid for these pesky problems. 

Based on my Bugzilla readings, it seems that LibreOffice uses the int data type instead of the double type, which would seemingly be the root cause of this flaky behavior. I have not been able to figure out how to download the source code into Code::Blocks so I can view it and possibly do the debugging myself. Any easy-to-follow, step-by-step process would be appreciated, as once I get access to the source code, I should be able to fix this bug myself.
Comment 5 Telesto 2021-11-29 19:59:51 UTC
Setting to UNCONFIRMED, because lack of reproducer.. 

Everything described here exist. However kind of complicated to find easy system independent reproducers; I did few attempts left & right: like bug 144862
And see also the "see also' section at bug 140161.

You might find bug 103322 interesting..

Related to the source code. Starting point would be https://wiki.documentfoundation.org/Development 

Not sure how good/bad the documentation is at this point in time.
Comment 6 Telesto 2022-01-17 20:12:26 UTC
Line shifting part should be gone with latest Master build.
Comment 7 Stéphane Guillou (stragu) 2022-11-18 13:47:32 UTC
I could reproduce the lines moving when turning Automatic Spell Checking on and off after scrolling, but I found it unrelated to if the sidebar was showing or not.

Version: (x64) / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

However, I can't see it anymore in the latest master build:

Version: (X86_64) / LibreOffice Community
Build ID: 0eec6d44c65f895c6fe2172792717418627db05d
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

The related Bug 149322 was recently fixed (for LibreOffice 7.4.4 and 7.5). Could you please test to see if you can still see the issue you describe, using a recent development build available here: https://dev-builds.libreoffice.org/daily/master/current.html
Thank you!
Comment 8 QA Administrators 2023-05-18 03:18:54 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2023-06-18 03:14:49 UTC
Dear Eek! A Bug. Kill it!,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team