Issue 81907 - Mouse wheel scrolling jumps
Summary: Mouse wheel scrolling jumps
Alias: None
Product: Calc
Classification: Application
Component: ui (show other issues)
Version: OOo 2.3
Hardware: All Windows XP
: P3 Trivial with 5 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
: 81908 (view as issue list)
Depends on:
Reported: 2007-09-24 18:30 UTC by david
Modified: 2016-01-11 01:26 UTC (History)
8 users (show)

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

bug repro for large cell heights (6.50 KB, application/vnd.sun.xml.calc)
2007-09-25 13:31 UTC, david
no flags Details
problem repro for large cell height - unable to see the content (6.44 KB, application/vnd.sun.xml.calc)
2007-09-25 13:33 UTC, david
no flags Details
Separating Row and Cell Height (11.57 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-01-11 01:26 UTC, orcmid
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description david 2007-09-24 18:30:44 UTC
The user would expect mouse wheel scrolling to go smooth or one line at the 
time. This would be logical and user friendly.

However Open office 2.3 scrolls one CELL at the time which makes mouse wheel 
scrolling and even scrollbar scrolling jerky, uncomfortable and hard to use. If 
you have very large cell heights (like a long text) the page might jump HALF A 
PAGE making reading of the page really really hard.

Pleaes make wheel scrolling and scrollbar scrolling smooth - or at least in 
steps of 10 point font height/~0,5 cm/0,25 inch.

- David
Comment 1 frank 2007-09-25 08:52:26 UTC
*** Issue 81908 has been marked as a duplicate of this issue. ***
Comment 2 frank 2007-09-25 08:56:02 UTC
One for requirements.

IMHO it's Ok as it is now. What else as a row is a line ? 

The problem what a line can as high as the screen or even higher is a problem of
the spreadsheet designer I think.

Comment 3 david 2007-09-25 13:31:58 UTC
Created attachment 48480 [details]
bug repro for large cell heights
Comment 4 david 2007-09-25 13:33:14 UTC
Created attachment 48481 [details]
problem repro for large cell height - unable to see the content
Comment 5 david 2007-09-25 13:39:44 UTC
Why shouldn't open office be able to show "bad" spreadsheets properly - even on 
small screens? If you print out a "bad" spreadsheet og view it in Print preview 
it looks fine - but in the actual open office calc editor you simply can't see 
the cell content, scroll through it or even Edit it while seeing it.

Remember that "bad" spreadsheets my be scientific research with descriptions 
and measurement results - spreadsheets might be perfect for that. And - as I 
know from my work - spreadsheets are perfect for technical manuscripts and 
localizations with lots of text in different languages (one per columes) and 
huge cell heights. The whole translation business uses spreadsheets and excel 
sucks with large cell heights. Why now acknowledge that?

Why don't you think it's a problem that open office simply can't let the user 
see and edit the whole cell if its height is large or the user only has a small 
screen or a small window for open office?

All browsers try to show badly designed websites as good as possible letting 
the user scroll all over them to help the user see the entire page.
Programs are there to help the user - not force the user to act in a certain 
way. Software is meant to be adjusted to best do what the user wants - it 
shouldn't be the user that is limited to use the software _only_ the way the 
programmers could think.

Please see the attached scripts for repro. I think you might want to call this 
a DEFECT after seeing the problems this behavoir causes. Certainly not OK.

Perhaps you never made a user tests and examined the users' reactions on this 
exact functionality.

-- David
Comment 6 eric.bachard 2007-11-22 21:03:50 UTC
Issue confirmed on both :

- Linux Intel / amd 64
- Mac OS X Aqua ( m237 + aquavcl04 cws )

And yes, this is probably a design issue. 

Whom ask  ?
Comment 7 eric.bachard 2007-11-22 21:06:12 UTC
+ me on CC
Comment 8 pylanglois 2009-03-10 17:22:40 UTC
This bug is very annoying me. My laptop resolution is 1280x800 and it's very
difficult or impossible to see the end of a big cell that contains a lot of data....

The ideal behavior for me would be the be able to scroll the spreadsheet like a
canvas like in Gimp or Photoshop...  Something like ALT+ "Mouse 1" could make a
"Hand" cursor appears and each XY delta of one pixel moves the spreadsheet with
the same amount of pixel.

I'm sad to see that this bug is low on priority and planned to be resolved
"later". Their was no activity on this bug since 2007!! This is a simple
usability problem but it can make user mad enough to consider wining MSOffice. 

OpenOffice 3.0 is very nice and much better than 2.3 but I hope that those
little "cracks" here and their could be fixed rapidly to put OO ahead of MS

Comment 9 eric.bachard 2009-03-10 17:30:52 UTC

FYI, a student form Seneca College started working on that for his semester application.

For further information, please look at :

Please be patient, thanks.

Comment 10 pylanglois 2009-03-10 19:30:54 UTC
Hi Eric,

Thanks for the fast follow up!

It seems that MSExcel has the same issue! Happy to see that OOo will be
improved! Great software by the way.

Comment 11 tontonmanu 2009-12-18 22:06:44 UTC
No news from the developpers? All of this sounds like "wrong hopes"...

Should we wait for this function is implemented in Excel before this query is
seriously taken in account?... I think so.
Comment 12 tontonmanu 2010-08-09 23:26:33 UTC
This bug has been "NEW" for 3 years...
Is there any possibility for that function is implemented one day?
Did the student from Seneca College experiment particular problems? It's a pity
that no more information is shared about this issue.
Comment 13 pylanglois 2010-08-10 13:43:27 UTC

Good luck! ;)

Comment 14 eric.bachard 2010-08-15 17:44:14 UTC
@tontonmanu :

To my knowledge, there is no student form Seneca working on that at the moment. This means the 
topic is open, and if you are interested, you are welcome to contribute, e.g. providing patches or 
whatever equivalent.

Please remember that I'm working for free (I'm not paid), and I can't do more, but if you can provide a 
couple student + prof (both with C++ knowledge), then I think it should be possible to drive them for 
fixing the issue.

Off topic : discussing about old bugs, and for the record, this summer, I managed two students, as 
mentor for the Google Summer of Code, and we did a lot on the starmath improvement. This includes 
fixing the 9 years bug of the misaligned baseline in OOo (Equation editor) ;-)


Comment 15 pylanglois 2010-08-16 02:36:45 UTC
Hi Eric,

How can I get involved about this particular issue? I don't say I can solve it
shortly but if I can help, I am ready to give it a try. One thing is sure, I can
code c++ very well (says the humble guy :)).


Comment 16 tontonmanu 2010-08-31 21:50:55 UTC
Unfortunately, I've got no knowledge in C++; I'm a "simple user", and I give you
my feeling because I use OpenOffice everyday and I enjoy it.
I don't blame you for this long waiting, I'm aware of the difficults that such
an important project represents. Now, it's a good thing that you say that the
study is stopped, we know that the project is waiting for coders.
I think we've got here a real possibility of innovating in spreadsheets work -
not to say 'in comparison with another spreadsheets program' ;)
All that makes OpenOffice different and more user-friendly than other programs
makes its popularity.
...And it's alway a pleasure to say to MS users "I've done this with OpenOffice,
you can't do the same with MS Office" ;b
Comment 17 webassistant5.tft+openoffice 2013-08-12 14:38:14 UTC
It doesn't jump around as much in OpenOffice 4.0, but I noticed it's still not "smooth" it seems to have two speeds: 1 row per second (slow), or 5,000+ rows per second (impossible to control). Definitely not overly smooth.. but it's likely better than it was when this bug was opened. Here's hoping for a smoother scroll.
Comment 18 webassistant5.tft+openoffice 2013-08-12 14:40:18 UTC
(In reply to webassistant5.tft+openoffice from comment #17)
> It doesn't jump around as much in OpenOffice 4.0, but I noticed it's still
> not "smooth" it seems to have two speeds: 1 row per second (slow), or 5,000+
> rows per second (impossible to control). Definitely not overly smooth.. but
> it's likely better than it was when this bug was opened. Here's hoping for a
> smoother scroll.

I see regular scrolling still jumps a bit. I was referring to smooth scrolling (middle mouse button). Both need a slight bit of improvement.
Comment 19 sybren 2014-02-13 16:09:45 UTC
It would be really nice if scrolling could be done on a per-pixel basis instead of a per-cell basis. "X cells per click of the scrollwheel" only makes sense when you have a clicking scrollwheel. Touchpad- or touchscreen-scrolling is much smoother, and generally works best if the displacement of the document is linearly dependent on the displacement of the finger(s). Even with a scrollwheel I feel that the displacement of the document (in pixels, or centimeters) should be a constant.

In the current situation, the speed of scrolling is depending on the height of the rows. If you have a mix of taller and shorter rows, a continuous scrolling motion causes a non-continous displacement of the document.

A table in a OOo Write document can be scrolled through in a row-height-independent way. The same goes for a table in a HTML document when viewed in a browser. I think that the behaviour in OOo Calc shouldn't be any different.
Comment 20 adironj 2016-01-10 23:36:24 UTC
The scrolling problem on calc has been open for several years.  What specific skill is needed to solve the problem ?  Programming, coding?  Make recommendations, then we can try to find a person willing to voluntarily work and solve this problem.
Comment 21 orcmid 2016-01-11 01:26:46 UTC
Created attachment 85246 [details]
Separating Row and Cell Height

There is a workaround.

Don't make very tall cells by making rows higher.  Make the cells tall by doing a merge cells on rows of reasonable heights.  The same idea applies to horizontal scrolling also.

The scrolling will still be by rows/columns, but the ability to see into and navigate within the large cell should be improved.

Where this is workable, based on what the actual usage is, it should provide enough user control.

This upload illustrates a solution on the first example, 48480.

Note that this procedure works when large cells are not in adjacent columns of the same rows and in other cases.  

This might not be suitable all of the time, depending on how the cell contents are obtained.  I hope it will help in some cases.