Issue 90907 - Mouse wheel scroll increments too tiny
Summary: Mouse wheel scroll increments too tiny
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOo 3.1
Hardware: Mac Mac OS X, all
: P4 Trivial (vote)
Target Milestone: ---
Assignee: h.ilter
QA Contact: issues@sw
Keywords: needmoreinfo, oooqa
: 106713 (view as issue list)
Depends on:
Reported: 2008-06-20 07:05 UTC by anscgn
Modified: 2017-05-20 11:42 UTC (History)
8 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description anscgn 2008-06-20 07:05:31 UTC
Mouse wheel scrolling does almost not move the document at all (very tiny steps). Should move approx. 
line-wise at least.

Tested on Leopard with a 90+ page document. 

Hint: AppKit mouse wheel events use floats (not integers), representing the proportional speed of the 
Comment 1 eric.savary 2008-06-22 21:40:43 UTC
Please attach a sample document.
Comment 2 anscgn 2008-06-26 17:06:39 UTC
A sample document is not necessary: Simply open a new, blank document and paste a couple pages of 
plain text. Compare mouse wheel scrolling responisveness to, say, Safari or any other Mac program. OO 
Writer does not consider scrolling speed, i.e. it is almost impossible to scroll down an entire page, for 


Comment 3 Raphael Bircher 2008-06-28 09:23:03 UTC
Can't confirm with Leopard and DEV300_m19

Scrolling works fine with two finger scroll. You ar sure, that OOo was in focus?

Set myself to CC
Comment 4 anscgn 2008-06-28 13:59:08 UTC
Yes, it works to some extent on MacBook with two-finger scrolling (albeit still very small scroll steps 
only), but doesn't work with a mouse wheel. Using Microsoft 3-button mouse (USB), which works fine with 
all Macs.

I suspect the scroll speed is not regarded. Looks like it always scrolls at the minimum increment, no 
matter how fast the wheel is being scrolled.
Comment 5 lohmaier 2008-06-29 14:25:42 UTC
Has been confirmed that scrolling is slow with Microsoft Mouse by maveric. But
works better with a Logitech mouse. Compared to X11 version, both are slow.

confirming & rassigning
Comment 6 anscgn 2009-05-13 08:36:41 UTC
Just noticed this is still present in released 3.0.1. It's ashame that I had to go back to 2.4 again, as I 
need to scroll a lot in long documents.

I however think I can possibly contribute some more input to this:  

(1) The scrolling is choppy and stuttering even on a very fast machine, which might indicate that mouse 
events get lost. I haven't had a chance to look at the sources, but I would suspect an event queuing 
problem (?)

(2) As mentioned earlier, AppKit mouse wheel events include floats that carry speed information which 
might not be considered here.

(3) The particular mouse model (Microsoft or Logitech) should not matter at all, because other 
applications work fine with any model. Coping with that is the responsibility of the OS.

Unfortunately I don't have the time and resources to work on the sources myself. So hopefully this 
information might help. 

Comment 7 anscgn 2009-05-13 09:04:07 UTC
Move this to the current owner, because it seemded that it got lost in the old porting project. Hopefully I 
didn't miss anything important.
Comment 8 eric.savary 2009-06-18 02:26:49 UTC

*** This issue has been marked as a duplicate of 101742 ***
Comment 9 eric.savary 2009-06-18 02:27:02 UTC
Comment 10 elentirmo 2009-06-18 08:17:07 UTC
I don't think that issue 101742 is a duplicate of this one; it describes an entirely different issue on a 
different platform. At any rate, the steps to reproduce issue 101742 cannot be performed on Mac OS X.
Comment 11 anscgn 2009-06-18 11:59:57 UTC
Yes, please. This issue is different from 101742 and is specific to MacOS X. Actually this is a dramatic 
problem that probably puts off many Mac users, because it makes OOo Writer almost unusable on the 
Mac (and it is the only reason I am still using 2.4 with X11).

Please compare mouse wheel scrolling with other apps, e.g. Safari. OOo Writer should behave similar, 
or it will likely not be used.

Again: Mouse wheel events include speed/amount information on the Mac. That should be regarded to 
determine the amount to scroll.

Comment 12 eric.savary 2009-06-18 13:06:12 UTC
Indeed, the issue I referred has not a lot to do with this one. Sorry!

Well I could reproduce that OOo (Writer and Calc testen) scrolls slower than
Safari or MS-Word MS-Excel.

Now we need metrics to surround the problem: how "too small", "too tiny"?

Please give some metrics indicating: how many lines of text in average get
scrolled with a text formatted using a defined font, font size and let's say a
Zoom at 200% (or whatever you choose as reference)?

Please note that we already have changed the scroll behavior 84825.

Comment 13 anscgn 2009-06-18 13:48:23 UTC
The mouse wheel event already contains information on how many pixels the view should scroll. The OS 
calculates an appropriate amount depending on speed and other parameters. Slow scrolling moves only 
one pixel, fast scrolling up to 1/2 page. A fixed amount of pixels per scroll event won't cut it.

Search the API reference for kEventMouseWheelMoved and you'll find the parameter kEventParamMouseWheelDelta. There should be a corresponding API for Java or Cocoa too.
Comment 14 eric.savary 2009-06-18 14:30:46 UTC
That's not exactly the answer I expected.
Sorry the code doesn't speak to me!

I wanted to know what *you* experience on your system to compare with my
findings and be sure I have reproduced what you describe.

So "how small" is the scroll you experience?
Comment 15 elentirmo 2009-06-18 14:51:56 UTC
Currently a calc sheet always scrolls a single row for each "wheel click" of the scroll wheel, no matter how fast you turn the 

It is usual on Mac OS X that when you turn the scroll wheel faster (e.g. three wheel clicks in one go), the calc sheet should 
scroll more than three rows, i.e. it should accelerate. So we experience always scrolling a single row for each click of the 
scroll wheel as "slow".

The same for text documents: it should be scrolling line-by-line when you turn the wheel slowly, but scrolling progressively 
faster when you turn the wheel faster.

What anscgn means is that his "speed" at which the scroll wheel is turned is encoded in the information received from the 
Comment 16 anscgn 2009-06-18 16:10:15 UTC

I am experiencing approx. 1 line of text per wheel step, which is ok for fine scrolling inside one 
paragraph. It is hower almost impossible to use the wheel to scroll page-wise, i.e. to quickly skim a 
document's layout. The fixed wheel resolution keeps me turning the wheel 6-8 times per page.

Moreover, it feels like scroll events get lost (not queued?). This could be due to very slow screen updates, 
Comment 17 eric.savary 2009-06-18 16:13:02 UTC
Yes that is exactly what I could reproduce :)

@PL: Please have a look.
Comment 18 Raphael Bircher 2009-06-18 16:25:01 UTC
Well, now I understand the problem. I don't use mous wheel to navigate in a big
document. I click on the blue thing in the scrollbar and move it up or down.

One line scroll for mous wheel it's normaly on So, that's not a
Defect, thats a enhancement

Change issue type
Comment 19 Raphael Bircher 2009-06-18 16:30:08 UTC
rbircher > hdu

Do you understand the problem. allow only one line steps in mous
wheel. It is possibel to take the scroll speed from the cocao framework?

Set hdu on CC
Comment 20 anscgn 2009-06-18 16:49:20 UTC
Its not an enhancement: OOo 2.4 under X11 worked perfectly as expected. It's a regression that it now no 
longer works. All other applications I know of allow for page-wise scrolling with the mouse. That's 

A software should not enforce its own assumptions about how the user is supposed to use something as 
basic as the mouse. That's the responsibility of the OS. As of current, OOo Writer ignores the delta 
information passed in the wheel events, which causes a serious usability issue.
Comment 21 anscgn 2009-06-18 17:25:21 UTC
Please do not underestimate this issue. Consider that the mouse wheel is superior for long documents, 
where the scrollbar gets too sensitive and fiddly (because of its scale). The wheel is always relative and 
works equally for all sizes of documents. There's good reason why the OS supports a variable delta 
information in the event.
Comment 22 philipp.lohmann 2009-06-18 17:26:36 UTC
The OOo Macport first worked this way until (a few) users complained, that the
scrolling was too fast. That was changed with issue 84825. So please take that
up with the good people at uxer experience on the
mailing list.

The bottom line is I will not change this behavior AGAIN, until a reasonable
amount of people say, it should actually be changed and exactly how.
Comment 23 anscgn 2009-06-18 17:35:18 UTC

I agree with you in that neither a small, nor a large step increment will satisfy anyone, because it is 
variable. For this reason, the OS passes a pre-computed value (delta). You can simply use it (IIRC, its in 
pixel units already). This will make the behavior 100% Mac compliant and nobody will complain.
Comment 24 philipp.lohmann 2009-06-18 17:45:14 UTC
Sorry, but as I said: somebody has complained when the behavior was to scroll
the pixel value.
Comment 25 anscgn 2009-06-18 17:52:09 UTC
No, not 1 pixel (sigh)

The delta increment passed with the event varies between a few pixels and some 200-300 pixels, 
depending on how fast the wheel is scrolled. This was perfectly tuned by Apple engineers and this value is 
used by /every/ Mac application, so there is no reason why any Mac user should complain. Nobody would 
notice a difference to standard apps.
Comment 26 philipp.lohmann 2009-06-18 17:57:21 UTC
Who said something about 1 pixel ? And the fact remains that when we still
passed the delta value from the scroll event to the application, some people
complained that scrolling was too fast.
Comment 27 anscgn 2009-06-18 18:56:37 UTC
Ok, I didn't know that. Sorry. 

I really wonder how someone could complain about the standard Mac behavior. Perhaps there was some 
unintended additional scaling in effect that overly distorted the speed factor? 

Anyway, I can't help but feel some minority took over this matter to their personal liking. This is a pity 
IMO. As I unfortunately don't have enough time to engage in community discussions, I will stay with 2.4 
under X11 and forget about version 3 entirely. Skimming a 200 page documentation with the scrollbar is a 
Comment 28 michael.ruess 2009-11-09 09:50:59 UTC
*** Issue 106713 has been marked as a duplicate of this issue. ***
Comment 29 nuss 2010-02-20 21:49:04 UTC
@pl: It seems like there wasn't a big discussion in issue 84825. I don't know
what happened behind the scenes, but I'd say anscgn's arguments are quite well
founded. You say "people complained" about the old behavior. Who did? Is there a
message board archive or something you could link to? I think there should be a
discussion about this again. 

I interpret issue 84825 as ssa saying "minimum should be something like 3
lines". I could live with that, but 1 line is just painful. I would definitely
argue this is a defect, whether intentional or not. The OS default value for
scrolling should be obeyed, in my opinion, and obviously in most other software
Comment 30 philipp.lohmann 2010-02-22 09:06:45 UTC
There is no "OS default value" for scrolling on the mac, the scroll event tells
about pixels to scroll. Writer however scrolls lines - plus only writer would
know what a pixel might be in relation to the current line. So at the moment
there is only some kind of arbitrary guess possible what might be a "line" when
translating the mac system event to a system independent event.
Comment 31 nuss 2010-02-22 11:26:47 UTC
> Writer however scrolls lines - plus only writer would know 
> what a pixel might be in relation to the current line. 

It doesn't seem like Writer is scrolling a page faster if font size is set to a
greater size, i.e. a page having fewer lines. It seems like a "scroll line" in
Writer is the equivalent 11 points in Arial (give or take a fraction of a
point), assuming the scroll wheel scrolls 1 line per click. Even if you set the
font size to 80 points, scrolling an A4 page takes 68 clicks (68*11 points =
26.39 cm. A4 = 29.7 cm).

I think there are 3 possible solutions to this (except to leave it be):

1. File a new issue saying "Use Mac OS X OS-wide scroll wheel event value for
scrolling in Writer". This would probably be the best solution, but I imagine it
might be difficult to implement.

2. File a new issue saying "Add setting to prefs allowing user to set how many
lines the scroll wheel will scroll in Writer". This way the user may choose
himself how many lines a scroll click should trigger. I imagine this is easier
to implement, and I'd think it would satisfy most users.

3. Discuss and pick a value that somewhat resembles the out-of-the-box set
"scroll event" on Mac OS X (non-accelerated seems the easiest way). This way we
pick a new value, which some might dislike. But if we don't just pick a value
randomly, but put some thought behind this, I think a majority of users will be

> So at the moment there is only some kind of arbitrary guess possible
> what might be a "line" when translating the mac system event to a 
> system independent event.

Let's make a couple of general and specific assumptions: 
a) Out-of-the-box values are the most widely used values since most people
doesn't change their settings. Partially because they don't know they can or
don't feel the need, and partially because:
b) Out-of-the-box values set by Apple or Microsoft are based on user testing,
the values are not arbitrary.
c) Most people who write in Writer do so i 12 points (the default value)

Fact: Windows XP and Vista has a default of 3 lines per wheel "click". Though I
haven't verified it (I will create a clean profile if you ask me to, to do some
testing), anscgn say that Mac OS X default value is 200-300 pixels per wheel
"click" (where I assume 200 pixels is the non-accelerated value). In a document
with Times, 12 pt, zoom 100%, resolution 1920x1200, 200 pixels is the equivalent
of 13 lines (which doesn't seem right to me, but I might be wrong). 

In conclusion: this issue should not be solved based on arbitrary guesses, but
based on facts and well thought-out assumptions. Based on the facts and
assumptions I've presented above, the default value should be somewhere between
3 and 13 lines. I'm certain we are able to do some more testing to make that
window smaller. But I think it's important to acknowledge that 1 line is too
small. There are plenty of complaints about this on the internet:

I've followed the discussion at Mozilla about scrolling and these are the
relevant bugs in Bugzilla:
Comment 32 anscgn 2010-02-22 13:35:46 UTC
Thanks for bringing up this issue again. However, there is no need to guess a default number of lines 
to scroll, because

    [NSEvent deltaX]
    [NSEvent deltaY]

deliver exactly the number of pixels to scroll (see documentation of class NSEvent). These values even 
increase automatically depending on the speed the user moves the wheel. It is possible to scroll by 1 
pixel only (very slow), up to an entire screen at once (very fast).

Please consider using these functions, as they make OOo behave exactly the way that is expected for 
every MacOS X application. Just try it out with Safari, Mail, or any other app.
Comment 33 philipp.lohmann 2010-02-22 13:50:41 UTC
Please read again what I said: the abstracted event writer gets contains lines
(as in "lines of texts"). Mac is the only platform insisting on pixels (which
for the end user is mostly a useless quantum). So with the current architecture,
the code translating the mac event into an cross platform event needs to put a
factor "pixels/line" in there, which is arbitrary.

Of course writer (and the other apps) could be rewritten to use pixel scrolling
just for the mac - which is why this is an enhancement.
Comment 34 anscgn 2010-02-22 14:37:40 UTC
Ok, I see. Thanks for explaining the details. I dont think it makes sense to switch the entire application 
suite to pixel-wise scrolling, though.

It would be perfectly sufficient if the number of lines to scroll would range from 1 to 20 (just guessing) 
depending on how fast the wheel is actually moved. This would allow for both, very fine steps as well as 
very coarse page-wise skimming of a document.  The user could control the scroll speed intuitively 
without changing any preference settings.

The value of [NSEvent deltaY] could be divided by a suitable constant to give the number of lines to 
scroll. I'm fine with the idea of assuming a 12pt font height as 1 line, as long as the dynamic speed 
factor is incorporated.
Comment 35 philipp.lohmann 2010-02-22 14:59:45 UTC
12pt seems reasonable. The current factor is 8 pixels/line, with a cap of 15
lines (which is as arbitrary a 8pixels/line). This is what the result of the
last issue gave. Changing this to 12 points/line (depending on the display that
would be around 15 pixels per line, resulting in scroll speed about twice the
current speed).

At the same time I would change the independent event to transport the actual
pixel value laying the foundation for applications to be able to scroll the
correct pixel amount. I don't think it's that hard for the apps to scroll
pixelwise (aside from calc perhaps who might not want that at all seeing how
they use a rigid grid).
Comment 36 nuss 2010-02-22 20:25:14 UTC
Actually, I'd argue we're talking about separate issues, and that separate
issues should be filed (considering this is the way we do it here, I'm most
familiar with Mozilla's Bugzilla). 

I think everybody can agree that the most desirable behavior is the native
scrolling of Mac OS X - a complete rewrite. Thus, I think filing a separate
issue for this is in order. I get the feeling this is not implemented in a snap
and therefore, it could be defined as ENHANCEMENT and set to whichever milestone
best suited for this. 

What seems reasonable to implement in the near future is more of a quick fix, if
I interpret pt's comments correctly: a greater scroll value per "click" but no
acceleration. Have I understood this correctly if I say this is what this issue
is all about?

If this is the case, I suggest we focus on finding a value that everybody can
agree upon for this particular issue. I'd argue that without acceleration, the
number of lines per "click" should be greater than twice of what we have now.
With acceleration it's a different question. My suggestion is the equivalent of
three 12pt lines. I base this suggestion on the fact that this is the how most
Windows users experience OOo (using default settings in Windows) and the
following calculations.

With a three lines/scroll "click" it would take 23 "clicks" to scroll through an
A4 page instead of 67 as it is now. With the "almost twice" value that pt
suggested it would take more than 34 "clicks". While definitely better, I think
the precision of two lines is a bit more than necessary. If you use the scroll
wheel you probably don't just want to move one or two lines down. In most cases
you could use the arrow keys instead. Three lines (or four or five or maybe even
six) lines keep a sense of precision but is still quite fast enough to scroll
through a page to the next one. 

If we assume a user scrolls 4 "clicks" per "turn" of the wheel:
1 line/click = 17 turns
2 lines/click = 9 turns
3 lines/click = 6 turns
4 lines/click = 4 turns
5 lines/click = 3 turns

I'd argue that 4-6 turns is precise enough and still quick enough to get to the
next page. Thus, 3 or 4 lines per "click". If you consider the behavior on OOo
for Windows and previous complaints, I'd settle for 3 lines. This is a
compromise I hope everybody could live with. :)
Comment 37 philipp.lohmann 2010-03-01 09:55:11 UTC
Fixed in CWS vcl110

Well, the theory with "12pt = 1 line" was nice while it lasted. Turns out the
smallest scroll event that happens is 0.1 pixel, the maximum being somewhere
around 50 (depends on how fast you can scroll). That gives way to few scroll
lines due to rounding. So I changed the scroll speed to faster. I also added the
possibility for applications to scroll the amount of pixels (at least 1 of
course), but don't know when the app developers might come around to do that.

For everybody who wants to look I've uploaded an install set with the changes at

If you think that scrolling is still too slow, now's the time to complain.

@mod: I changed all wheel events in vcl/aqua/source/window/ since
they behaved the same before and probably should now. Could you please verify
that your gesture code still works as expected ?
Comment 38 max.odendahl 2010-03-08 13:05:28 UTC
mod->pl: yes, will have a look, especially in regards to issue 102807. I guess
your fix either made things worse there, or maybe fixed it as a side effect....
Comment 39 nuss 2010-03-08 21:36:13 UTC
@pl: Thank you. I think it's a great enhancement (albeit small - it's all in the
details). Nicely done!

Regarding native scrolling behavior: if it's feasible to get OOo to obey the
global, native mouse settings from the OS (in even a distant future), perhaps a
new issue should be filed for this? I'd be happy to file it, but I'm unsure of
the terminology and the technical difficulties involved.
Comment 40 philipp.lohmann 2010-03-09 10:34:03 UTC
Created issue 109967 for that.
Comment 41 philipp.lohmann 2010-03-26 16:16:46 UTC
please verify in CWS vcl110
Comment 42 h.ilter 2010-04-07 12:01:59 UTC
Verified with cws vcl110 = OK; Now it is possible with one wheel spin to reach
the end of page.