Apache OpenOffice (AOO) Bugzilla – Issue 121583
Vertical scrollbar scroll bar miscalculations
Last modified: 2020-08-09 23:25:50 UTC
This is an attempt to clarify the problems I see reported in Bug # 121266. The vertical scroll bar on the mac version in a word processor window has an area at the bottom reserved for several buttons. Thus the whole height of the window is not used for the scroll bar. In all likelihood, these size of these buttons was not understood and threw off some calculations regarding the usable area of the scroll bar. In this shorter scroll bar range, the visible thumb actually can appear in any position, as it should. (However, it looks like a slight miscalculation of thumb position allows it to overlap the top pixels of the buttons below it when the thumb is in its bottom-most position.) Now, even though the visible position of the thumb seems to be nearly correct in its use of the visible space, the clickable area of the vertical scroll bar is more restricted. This has some curious effects. The mapping of the clickable range onto the visible range causes the thumb to be under your mouse when the mouse is at the top of the scroll bar. However, as the mouse moves further toward the bottom of the scroll bar, the visible thumb starts to move further and further BELOW the mouse. By grabbing the thumb when it as at the top of the scroll bar and dragging it slowly down, you can see that the thumb moves progressively more and more below the cursor. In this way, you can discover the approximate clickable range and how much it differs from the space in which the scroll bar thumb moves. When the visible thumb is at the bottom, you cannot "grab" it with the mouse, since it is outside the clickable range. The user must guess at the where the bottom of the clickable range is and click there to be able to grab the thumb. The thumb then tracks the mouse, but is not visibly overlaid by the mouse until the mouse approaches the top of the scroll bar. This explains some effects described in Bug # 121266. There can be a "dead zone" above the visible thumb when it as the bottom of the scroll bar, since the miscalculated clickable range ends some distance above the thumb. Strangely, there are two clickable areas (one for scrolling up and another for scrolling down) which fall below this dead zone and even span the visible thumb when at the bottom of the scroll bar. Perhaps these are byproducts of some code intended to support a different scrolling mechanism on a different platform. Also, if one has the visible thumb in the middle of the scroll bar, and the system preferences are set so a click on one side of the thumb jumps in that direction by one page, the results can be very confusing, since the program thinks the visible thumb is in a different location from where it appears on the screen. Thus, on the screen, the user thinks he is clicking above the thumb but the program thinks he is clicking below it. I see that this bug appears in a previous version of OpenOffice, which I've been using (3.3.0). In addition, the same bug appears in LibreOffice. Hence, it must date back to some code common to these products. This bug is an annoyance. However, it works in a predictable fashion, if you understand how it arises. I find that having my system preferences set to position the document to a relative location on a click anywhere in the scroll bar minimizes the problems.
FWIW I first noticed it after upgrading to Mac OSX Mountain Lion. I upgraded to v3.4.1 and it's still there.
*** Issue 121266 has been marked as a duplicate of this issue. ***
I use Apache OpenOffice 4.0.1 under OS X 10.7.5 and can confirm this bug. I also noticed this bug in Apache OpenOffice Versions 3.4.0, 3.4.1 and 4.0.0. The same bug appeared in LibreOffice and was numbered there as Bug 46271: https://bugs.freedesktop.org/show_bug.cgi?id=46271 Since there was made a patch for LibreOffice's Bug 46271, maybe it's possible to apply this patch to Apache OpenOffice as well. Here's a shortcut to an illustration of the bug which was made by the creator of "Comment 3" in the discussion about Bug 46271: https://bugs.freedesktop.org/attachment.cgi?id=61634 Furthermore, in a discussion about NeoOffice 3 this bug was mentioned and patched too: http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&t=8366
Since it was reported in the above discussion about LibreOffice's Bug 46271, that the patch alleviated the bug but didn't fix it completely, it could be useful to examine the source code of the NeoOffice patch. Maybe the NeoOffice patch solves the problem better than the LibreOffice patch.
Out of curiosity, i have installed on my Mac OSX 10.7.5 both NeoOffice 3.3 (Patch 0) and LibreOffice 4.1.3.2. In LibreOffice 4.1.3.2 i opened a 70 pages document and the scroll bar behaved as described by the creator of "Comment 30" on https://bugs.freedesktop.org/show_bug.cgi?id=46271 See also his screenshot at http://img844.imageshack.us/img844/6521/jdkc.png When i was between page 1 and 69 and i clicked on the lower edge of the scroll bar, the page "jumped" a bit downwards before i was able to get a hold of the scroll bar with my mouse. And this hold was not very strong, because the dragging speed downwards was quite low and the distance between mouse pointer and scroll bar became greater and greater; dragging upwards wasn't possible at all. Only when i grabbed the scroll bar at its middle or upper part, the scrolling was ok. So the LibreOffice patch indeed just alleviated the scroll bar bug but didn't fix it completely. Contrary to this, the NeoOffice patch fixed the scroll bar bug completely: in NeoOffice i can click on the lower edge of the scroll bar and the page does not jump downwards but i get a strong hold of the scroll bar immediately and can drag it both upwards and downwards. Therefore it would be desirable to include the NeoOffice patch in both LibreOffice and Apache OpenOffice. Here's some info about the NeoOffice patch again: http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&t=8366 (I suppose that it hasn't been altered since its first appearance in NeoOffice 3.2 Patch 5).
To clarify the scope of the scroll bar bug in Apache OpenOffice: It affects not only Writer but all scroll bars in the whole office suite. E.g. you can observe it in menus "Preferences > OpenOffice > Appearance" and "Preferences > Language Settings > Writing Aids". The bug is also visible in drop-down menus for font and font size in Writer and Calc. Nevertheless, if you want to verify that the LibreOffice patch didn't fix the scroll bar bug completely, in LibreOffice 4.1.3.2 you better examine the scroll bar of a 70 pages document in Writer, because in many other menus the scroll bar seems to behave bug-free with the LibreOffice patch.
I better correct my last sentence above: In many other menus the scroll bar does NOT behave bug-free with the LibreOffice patch, because dragging upwards isn't possible if i click on the lower edge of the scroll bar. Many other menus just don't show the additional phenomenon that the distance between mouse pointer and scroll bar becomes greater and greater when i drag downwards further and further.
Some more info about the scope of the scroll bar bug in Apache OpenOffice: The scroll bar bug is not limited to long documents, but already can be observed in shorter documents. The following observations can be made if the scroll bar is in its lowest position: in a Writer document which is only 1 page long, the lowest 20th part of the scroll bar isn't clickable with the mouse. If you create more pages in this Writer document, the not clickable part of the scroll bar increases. Finally, in a Writer document which is 8 pages long, the whole visible scroll bar isn't clickable anymore, because the "true" invisible scroll bar is completely located above it. While people in NeoOffice and LibreOffice forums only mentioned problems in long documents, the NeoOffice bug and LibreOffice bug most probably affected short documents in these office suites too. For informational purposes, here's a Wiki entry about NeoOffice 3.2 Patch 5 which fixed the scroll bar bug completely: http://neowiki.neooffice.org/index.php/NeoOffice_3.2_Release_Notes http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&t=8366
Regarding the source code of NeoOffice, i've found this site map: http://neowiki.neooffice.org/index.php/NeoOffice_Build_Instructions Among its links, the following sites seem to be especially interesting: http://www.neooffice.org/neojava/en/build.php#source http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=18560#18560 http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=25404#25404 http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=18919#18919
Brief comment. I was the person who first reported this bug in LibreOffice. There is currently a different bug in the latest versions of LibreOffice that is particularly affecting me. I just downloaded the most recent version of OpenOffice and was surprised to see the scrollbar bug still present for Mac users running later versions of Mac OS X. I was considering returning to OO but I work with really large Writer documents and the scrollbar bug is worse than the other bug I'm dealing with in LibreOffice. Bummer. Since it's been fixed in NeoOffice and LibreOffice I guess I can hope that it will eventually be fixed in OO.
Around page 100 in my document the scroll bar becomes very difficult to grab and drag. At the top of the document it works fine, but the farther down I am, I need to click a small area about 1/4" above the gray oval in order to drag it up or down (very easy to miss).
The scroll bar bug has been greatly alleviated in Apache OpenOffice 4.1.1: The visible area of the scroll bar matches the actual clickable area of the scroll bar now. Only a minor problem remains: Independently of the current position of the scroll bar, the actual clickable area of the scroll bar is a little bit below the visible scroll bar; therefore the uppermost edge of the visible scroll bar isn't clickable, whereas you can click below the visible scroll bar and still get hold of it. Ironically in LibreOffice this minor problem is reverse: according to the following screenshot, in LibreOffice the actual clickable area of the scroll bar is a little bit ABOVE the visible scroll bar: http://img844.imageshack.us/img844/6521/jdkc.png In the end this minor problem isn't very severe and already now it's possible to work with Apache OpenOffice 4.1.1 under OSX 10.7 smoothly. Many thanks!
Hi to whom concern, Generally the scenario isn't hard to understand and I fully understand and know the way to replicate the issue with the given information from all previous comment.I cannot replicate the bug which originally reported in 2013 since it seems to be fixed in later release and have adapted new UI. But the description of the last comment match with my observation. Part1 Replicate the Report: Precondition: My testing version is OOO v4.1.2 from mac OS X 10.11.6. 1.Open the OpenOffice Writer 2.Create one new document with 1 single page 3.Manually click the scrollbar up and down on the right hand side of tool bar right next to blank page. Notice the vertical rectangular position indicator adjusts to the designated area where click happens along the position of the scrollbar. Please refer to screenshot. 4. Click mouse at area very near the top of scrollbar, there’s no response. Indicator cannot move and get closer to the top of scrollbar. Meanwhile the displayed page adjusts to corresponding position. 5. Click mouse at area very near the bottom of scrollbar, there’s no response. Indicator cannot move and get closer to the bottom of scrollbar.Meanwhile the displayed page adjusts to corresponding position. (reporter meant this is replicable, but due to the up and down arrow buttons so close to the bottom of scrollbar I am not able to reproduce this part) 6.Repeat steps 2-6 while create new document with more than 100 pages, observe if the location indicator can move together with the click. Meanwhile the page adjust to corresponding position. Expected:Click on any corresponding location the scroll bar indicator can be adjusted to the designated area and jump to corresponding page location. The issue: For top of scrollbar and button of scrollbar, after click on scrollbar the location indicator doesn’t respond and move to corresponding location. Part 2 Summary of current issue: The scroll bar matches with the clickable area most of the area from scroll bar except the upper top of the scroll bar. Due to the impact of the "previous page" button, the lower scroll bar isn't clickable isn't easy to verify. Please see screenshot on the problematic area in red. After read through all the comments from the bug report, no extreme value used but it implies boundary such as long and short document. I have created a file for more than 100 pages to simulate reporter's long document which is the scenario originally reported. From some other reporter later updates, the issue also replicates on 1 page long as well as more than 100 pages. Part 3 Part not able to replicate according previous comments and additional info needed: The visible thumb doesn't show up while I was testing and I think a screenshot would be quite helpful to clarify uncertain part. I would also suggest to have more specific information in bug report such as list the operating system information and the file size/pages in precondition and list steps one by one on how to replicate. List different section in bulletin such as precondition, steps to reproduce, expected results and actual results. Part 4 To further find out the root cause(problem area) I would like to suggest follow-up tests mentioned below: 1.On single page what is the pixel of the non-clickable area from top upper right scroll bar. 2.On long document such as document with 100 pages, whether the pixel of the non-clickable area is the same. If the value differs, how much is the percentage? To verify the response is the same as single page. 3. For the test doc with 1 page, enlarge the Writer doc view to be 200% and see if the non-clickable area is the same as 100% view. To check whether this is proportional to the view customization. 4. For the test doc with 100 page, enlarge the Writer doc view to be 200% and see if the non-clickable area is the same as 100% view. To check whether this is proportional to the view customization. 5.Check scroll up and down with the mouth control position is 100% responsive over the scroll bar which means it should bring the location indicator to the up top or bottom of the scroll bar. To identify whether this can be the workaround to help overcome the non-clickable area defect. 6.Check scroll up and down with the page up/down arrows is 100% responsive over the scroll bar which means it should bring the location indicator to the up top or bottom of the scroll bar. To identify whether this can be the workaround to help overcome the non-clickable area defect. 7.Whether this issue is applied to other OpenOffice product? like Spreadsheet, Drawing and Formula. To check whether this is a common problem across the application therefore can identify the impact area. 8.If I have more time, I would repeat the test over Window operating system to see if this issue persist on Windows operating system as well. This would help product manager to understand the scope of impact from this bug. Also can help developer to fix the bug better. By doing all those tests mentioned above, we can identify the scope of impact on this bug, work around and whether this is related to zoom in/out. Please let me know any feedback, thank you.
/Users/wwang001c/Desktop/Screen Shot 2017-04-17 at 12.14.13 AM.png /Users/wwang001c/Desktop/Screen Shot 2017-04-17 at 12.14.00 AM.png