Problem description: The handle of the vertical scroll bar has a very small clickable area that does not match the handle's length; it's confined to the very top of the handle. Steps to reproduce: 1. Open a large enough document in Writer so that the vertical scroll bar appears. 2. Click somewhere between the middle and the bottom of the handle of the vertical scroll bar. Current behavior: Writer will directly page-down the document. Expected behavior: Be able to drag the handle. Platform (if different from the browser): Mac OS X Lion 10.7.3 Additional discussion already in the mailing list: http://nabble.documentfoundation.org/Problem-with-vertical-scroll-bar-in-LibreOffice-Writer-3-5-for-Mac-OS-X-tp3752844p3752844.html Browser: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
*** Bug 48860 has been marked as a duplicate of this bug. ***
Always occur with LibreOffice 3.5.3.2 / Version ID : 235ab8a-3802056-4a8fed3-2d66ea8-e241b80 on MacOS Lion 10.7.3
Created attachment 61634 [details] Screen shapshots and description of scroll bar bug
This has been bothering me since Mac OS 10.7.0. I've added a JPEG showing what I'll describe below. I have several 300+ page writer documents. When at the beginning of those documents, in order to select the scroll bar (which is really tiny in such large documents), you have to position the pointer about 1/4" BELOW the scroll bar. If you do that, you can select and drag the scroll bar. At the bottom of a large document, to select the scroll bar requires positioning the pointer about 1/4" AVOVE the actual scroll bar. When at the middle of a large document, the scroll bar can be selected normally. I've converted the same long documents to MS Word format and Word doesn't exhibit this problem. Same for Apple's TextEdit. And, it did start with Mac Lion (10.7) when Apple changed the appearance of the scroll bars. Not a critical but, but somewhat annoying. Also, it only happens in long documents when the size of the scroll bar shrinks pretty small. I don't know what the magic number of pages is; however, as the number of pages increases, the area of selection on the scroll bar begins to decrease.
Always occur with LibreOffice 3.5.4.1 Version ID : 7306755-f4f605c-738527d-1cf4bc1-9930dc8 on MacOS Lion 10.7.3
Always occur in Version 3.6.0beta1 (Build ID: 1f1cdd8)
Problem also occurs in Calc 3.4.5, OS X 10.7.4. Affects only larger documents. Spreadsheet with >4K rows - grabbable handle is invisible, ca 1 cm below/above grey scroll button region; small sheet of 40 rows - scroll button is several times larger, grabbable as expected.
Always occur in Version 3.6.1.2 (Build ID: e29a214) I will attach this bug to the most annoying bugs in 3.6
The problem might be explained by this note, where the small deviations are multiplied. vcl/source/control/scrbar.cxx /* #i77549# HACK: for scrollbars in case of thumb rect, page up and page down rect we abuse the HitTestNativeControl interface. All theming engines but aqua are actually able to draw the thumb according to our internal representation. However aqua draws a little outside. The canonical way would be to enhance the HitTestNativeControl passing a ScrollbarValue additionally so all necessary information is available in the call. . However since there is only this one small exception we will deviate a little and instead pass the respective rect as control region to allow for a small correction. So all places using HitTestNativeControl on PART_THUMB_HORZ, PART_THUMB_VERT, PART_TRACK_HORZ_LEFT, PART_TRACK_HORZ_RIGHT, PART_TRACK_VERT_UPPER, PART_TRACK_VERT_LOWER do not use the control rectangle as region but the actuall part rectangle, making only small deviations feasible. */
*** Bug 50474 has been marked as a duplicate of this bug. ***
/rant on My apologies if this is not the place to issue complaints and all but I believe this bug has been with us for a good year now...anyone would be so kind as to let us know if and when this is supposed to be looked into? I find it increasingly frustrating to work with large (i.e. many pages) word and excel documents knowing that this behaviour will kick into my workload given the first opportunity. Please please someone at least put a timeframe into resolving it.. P.S. I'm on 10.7.5, i believe this also stands true for 10.8.x...Most of the people i know have already jumped ship and abandoned 10.6.8, it's a pitty that LibreOffice still exhibits the same crappy vertical scrollbar bug, a pitty to say the least. /rant off
(In reply to comment #10) > *** Bug 50474 has been marked as a duplicate of this bug. *** Bug 50474 doesn't look like a duplicate of this bug. Are you sure you didn't mistype the bug number?
It's not a duplicate. See: https://bugs.freedesktop.org/show_bug.cgi?id=50474#c6
Always occurs with Version 3.6.3.2 (Build ID: 58f22d5) On Mac OS X Lion 10.7.5
I just noticed that the problem is not restricted to the main document window, but possibly to vertically scrollable areas in general. For instance, you can see the same problem with the typeface selection drop-down, when you have lots of typefaces installed. Mac OS X Lion 10.7.5 LibreOffice 3.6.4
I can confirm that the issue is still present on Mac OS 10.8.2, LibreOffice version 3.6.4.3. There are workarounds (click above the scrubber or use a trackpad gesture to scroll), but there is no quick way to go to the top of a long document. Might this issue get in the queue for the next version?
I'm the originator of this bug report. Let me also add that this bug, when using the same very long documents, is not present in other Mac OS X apps. I took a 300 page .odt document I have and saved it as a .doc file. I then opened that file in both Word for Mac (latest version) and Apple's Pages (latest version). In both cases I could grab the small visible scroll bar and drag it. When I first found this bug I was sure it was a general Mac OS X bug but that isn't the case.
For information, We have payed someone to work on this issue. I hope it will be resolved soon.
*** Bug 60295 has been marked as a duplicate of this bug. ***
*** Bug 60247 has been marked as a duplicate of this bug. ***
Problem still exists in 4.0.2.2. When the cursor is at the beginning of a long document, the scrollbar indicator can actually be dragged by starting to drag from just below the indicator, and when at the end of the document, dragging works if you start dragging just above the indicator. While dragging, one notices that the scrollbar indicator overtakes the mouse, so it seems that mouse position and scrollbar indicator are somehow out of sync. The same error shows up e.g. in the various font combo boxes. Cheers Burkhard.
*** Bug 53351 has been marked as a duplicate of this bug. ***
I just downloaded LO and have found a small issue. Sliders/scrollers especially small sized will not scroll home easily using the sidebar. Sometimes the only way is to use the mouse wheel over the list to make them scroll. Attached is an image of one example. Notice vertical slide scrollbar is at the bottom. Using the mouse I cannot grab it to slide upward. I am using Mac OS X Mountain Lion. Same problem with horizontal sliders especially the spreadsheets. Using the mouse "wheel" vertically or horizontally works perfectly. Can this be corrected?
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8c467d134c1c49d2b25c72fbd45dd1c6b77b171 fdo#46271: No arrows in scrollbars in OS X 10.7 and later 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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c64554aec5a90daa800dd3a70b777dca510c56dc&h=libreoffice-4-1 fdo#46271: No arrows in scrollbars in OS X 10.7 and later It will be available in LibreOffice 4.1.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.
I cannot reproduce this issue anymore, if someone else can also confirm then we can close this issue. @Joren, could you try to reproduce this? @Tor, thank you very much for this fix.
I confirm the bug has been squashed in the nightly of 31 July. This makes LibreOffice much more usable. Thanks!
And this is history.
Excellent news! I know this bug is now closed and all, but ... Would anybody have access to Maverick Developer Preview to test it there as well?
Although I can attest to how much better the behavior now is, the issue is surely not solved yet. In creating a new doc and inserting several blank pages (using cmd+enter) to the extend that the scrollbar becomes quite small (similar to having a 100page document open) trying to click the lower edge of it yields a page down result. In addition clicking the upper edge seems to exhibit an inversely proportional to the previous action extra space that yields an "active" scrollbar ready to be pushed either upwards or downwards. Again..this is hugely better than before but surely still there.. :/
The bug is fixed is the latest nightly builds of LibreOffice--not the released version. After Ralph Martin's confirmation earlier in this thread, I downloaded the latest nightly build to confirm that the bug has been fixed. I used a 300-page LO Writer document. I had to see for myself that this has been fixed--and it has. I have no idea how it will take for the fix to make it into the released version of LO, but it is coming.
I'm also referring to the latest daily builds of LO in which the "fix" has been issued, found here: http://dev-builds.libreoffice.org/daily/libreoffice-4-1/MacOSX-10.8@21-10.7SDK/ as seen below: http://img844.imageshack.us/img844/6521/jdkc.png
(In reply to comment #32) > I'm also referring to the latest daily builds of LO in which the "fix" has > been issued, found here: > http://dev-builds.libreoffice.org/daily/libreoffice-4-1/MacOSX-10.8@21-10. > 7SDK/ as seen below: > > http://img844.imageshack.us/img844/6521/jdkc.png I don't have a Mac to test, but as far as I see, there's just a small position shift between the scrollbar and the effective drag area... does it really impairs user experience?
It doesn't to the extend that it used to, but still it's wrong to state that the bug's been fixed. It's miles better than before don't get me wrong, yet still not quite there yet.
@RTouris so would it be right to say that the fix improved the situation from major annoyance to minor annoyance?
indeed
so, let's remove it from the Most Annoying Bugs list
Same problem as described, but reproduced even with a "short" document (e.g., a 2-page document in Writer, but same in Calc, not tested in others). When the vertical scroll bar goes down (almost half the document), the shape do not correspond to the clickable area. It is more evident in large documents, of course. In large documents, the scroll bar behaves properly only above 1/4 of the bar. Using MacOS 10.8, but it also happened in 10.7 at the least, and since Libreoffice 3.x (not quite sure when I first noticed). I consider this is an important issue. It is annoying enough to prevent unaware users from using Writer, for instance.
(In reply to comment #33) > (In reply to comment #32) > > I'm also referring to the latest daily builds of LO in which the "fix" has > > been issued, found here: > > http://dev-builds.libreoffice.org/daily/libreoffice-4-1/MacOSX-10.8@21-10. > > 7SDK/ as seen below: > > > > http://img844.imageshack.us/img844/6521/jdkc.png > > I don't have a Mac to test, but as far as I see, there's just a small > position shift between the scrollbar and the effective drag area... does it > really impairs user experience? Yes. Quite a lot.
(In reply to comment #37) > so, let's remove it from the Most Annoying Bugs list No, please. I can tell you this bug has been annoying me really a lot. Maybe some users do not click at the vertical scroll bar at all, but I use it constantly to revise documents in Writer. It makes the scroll bar unusable even in rather short documents. This kind of bugs gives a very bad impression of the product to MacOS users. Not to me, but to standard users that just want to write a document, not filing an error and patiently waiting for it to be solved.
(In reply to comment #40) > (In reply to comment #37) > > so, let's remove it from the Most Annoying Bugs list > > No, please. I can tell you this bug has been annoying me really a lot. Maybe > some users do not click at the vertical scroll bar at all, but I use it > constantly to revise documents in Writer. It makes the scroll bar unusable > even in rather short documents. > > This kind of bugs gives a very bad impression of the product to MacOS users. > Not to me, but to standard users that just want to write a document, not > filing an error and patiently waiting for it to be solved. Sorry, not noticed that it was solved in the pre-release (I thought you were talking of 4.1, which I just downloaded). Thank you for fixing it.
As it was mentioned in Comment 30 that the patch alleviated the bug but didn't fix it completely, here is some info to fix the bug completely: You have to copy some parts of the source code of NeoOffice 3.2 Patch 5, which was released in July 2011 and which fixed the scroll bar bug completely for NeoOffice users. Further details can be read on https://issues.apache.org/ooo/show_bug.cgi?id=121583 from my 3rd comment. I don't know if the Apache OpenOffice staff has noticed my comments there, because nobody reacted to my comments so far. Maybe somebody of the LibreOffice staff can work together with the Apache OpenOffice staff to extract the bug fix from NeoOffice's source code or somebody of the LibreOffice staff can extract it on his own?
@raupe27k please open a followup bug report about residual issues with current LibO 4.2.5.2 release and put the current bug number under "See also"