Bug 565230 - Mouse scrolling resets to one line at a time
Summary: Mouse scrolling resets to one line at a time
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.16   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 569031 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-14 16:55 EDT by James Sheridan CLA
Modified: 2020-11-22 06:53 EST (History)
3 users (show)

See Also:


Attachments
Font change dialog and location within the UI (79.24 KB, image/png)
2020-07-14 16:59 EDT, James Sheridan CLA
no flags Details
Top of editor window before scrolling (2.34 KB, image/png)
2020-07-21 00:53 EDT, James Sheridan CLA
no flags Details
Top of editor window after single scroll (3.08 KB, image/png)
2020-07-21 00:54 EDT, James Sheridan CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description James Sheridan CLA 2020-07-14 16:55:18 EDT
Go to General -> Appearance -> Colors and Fonts -> Basic -> Text Font and change to something different than the default.  Apply.

After some (indeterminate) time, the mouse scroll in editor windows changes from the OS default (3, in my case) to 1 line at a time.

Go back to the same settings page and change the font to a different size.  Apply.  Scrolling is once again (for some short period of time) back to 3 lines at a time but it will not last.

This is easily worked around but HUGELY annoying because it happens so often.

BTW, large screen at high rez (3440x1440) and old eyes :)  I *do* need to push the font size up.


-- Configuration Details --
Product: Eclipse IDE 4.16.0.20200615-1200 (org.eclipse.epp.package.php.product)Installed Features:
 org.eclipse.platform 4.16.0.v20200604-0951
Comment 1 James Sheridan CLA 2020-07-14 16:59:08 EDT
Created attachment 283601 [details]
Font change dialog and location within the UI
Comment 2 Rolf Theunissen CLA 2020-07-16 11:32:52 EDT
This is probably an issue in SWT or it is an issue with the specific editor you are using.

Do you observe this behavior in all editors? In which editors do you observe this behavior?
I assume that your OS default is not affected, is that correct (just to be sure).

At least moving to the Text component, as that is more related.
Comment 3 James Sheridan CLA 2020-07-17 00:36:35 EDT
I'm not sure what editor, at least in terms that the Eclipse team uses :)

I'm using the PDT for PHP development predominately and I'll update if I notice this in anything other than editing files of that type.

The OS scrolling is not impacted, no, just in eclipse.

Thanks for the component adjustment; it's hard to determine the right one.
Comment 4 James Sheridan CLA 2020-07-21 00:52:47 EDT
Very odd behavior. I restart Eclipse and scrolling is all reset to roughly one-line (see two attached images showing it scrolling about 1.25 lines per wheel tick) on all file editors (I have almost exclusively PHP files open).

I clicked into three files and tested scrolling on each, then changed the Text Font to "fix" the problem.  The three editors I clicked into all scroll by exactly 3 lines, as they should, but all other open editors that I did NOT click into remain with the 1.25 lines per scrolling.  Opening a new file has that file scrolling at 3 lines per tick.

I've attached two images showing the 1.25 line scrolling.  First shows the top part of an editor window view with two lines of code, the second shows that area after a single tick down on the scroll wheel.
Comment 5 James Sheridan CLA 2020-07-21 00:53:40 EDT
Created attachment 283658 [details]
Top of editor window before scrolling
Comment 6 James Sheridan CLA 2020-07-21 00:54:05 EDT
Created attachment 283659 [details]
Top of editor window after single scroll
Comment 7 Rolf Theunissen CLA 2020-07-21 05:13:30 EDT
I can confirm that I see the same behavior in the Java editor. Never noticed this before, even though I use a slightly bigger font too.
After restarting Eclipse it seems that the default font size is used for determining the scroll height.

This might be an Windows SWT issue. Can somebody try to reproduce this on Mac or Linux?
Comment 8 Rolf Theunissen CLA 2020-07-23 17:38:51 EDT
The problem arises from org.eclipse.swt.custom.StyledText.handleVerticalScroll(Event)

It calculates the number of pixels to scroll, based on the scrollbar and the scrolloffset. Both of these values are to low, when changing the font these values become correct and the scrolling is correct.

I was not able to find the root cause why the two values are too low.
Comment 9 Nitin Dahyabhai CLA 2020-07-23 18:44:39 EDT
Could UI scaling be a factor?
Comment 10 Rolf Theunissen CLA 2020-07-24 04:41:15 EDT
(In reply to Nitin Dahyabhai from comment #9)
> Could UI scaling be a factor?

I have been testing on a monitor without scaling, and the difference in pixels seems to be correlated to the font size. Therefore, I don't think UI scaling is a factor.
Comment 11 Rolf Theunissen CLA 2020-07-24 04:47:56 EDT
Upon further investigation, the increment of the vertical bar is incorrect. It is correctly set during initialization, but the value is changed afterwards by the RulerLayout.

In org.eclipse.jface.text.source.SourceViewer.RulerLayout.getVerticalScrollArrowHeights(StyledText, int) line 222, the increment is reset to 10.
Commenting out this line fixes the problem.
Comment 12 James Sheridan CLA 2020-08-24 11:35:59 EDT
(In reply to Rolf Theunissen from comment #11)
> Upon further investigation, the increment of the vertical bar is incorrect.
> It is correctly set during initialization, but the value is changed
> afterwards by the RulerLayout.
> 
> In
> org.eclipse.jface.text.source.SourceViewer.RulerLayout.
> getVerticalScrollArrowHeights(StyledText, int) line 222, the increment is
> reset to 10.
> Commenting out this line fixes the problem.

I assume there is nothing I can do as a user except wait and hope this makes it in to a release?
Comment 13 Rolf Theunissen CLA 2020-11-22 06:05:47 EST
*** Bug 569031 has been marked as a duplicate of this bug. ***
Comment 14 Nir Lisker CLA 2020-11-22 06:53:26 EST
As reported in the duplicate issue, occurs also in 4.17.