Bug 269451 - Scroll position flips back on scrolling with mouse wheel.
Scroll position flips back on scrolling with mouse wheel.
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: -- Other --
8.2
PC All
: P1 with 12 votes (vote)
: 8.2
Assigned To: Miloslav Metelka
issues@editor
82patch2-fixed, cndreq, 82patch-candi...
: REGRESSION, SIMPLEFIX
: 269397 269894 269960 (view as bug list)
Depends on:
Blocks: 269397
  Show dependency treegraph
 
Reported: 2016-12-29 19:24 UTC by ahah
Modified: 2017-07-12 11:55 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Screencast showing flip back during mouse wheel scroll (3.72 MB, video/mp4)
2016-12-29 19:24 UTC, ahah
Details
Another screencast showing Java editor skipping back when scrolling down (4.57 MB, video/quicktime)
2017-01-17 17:11 UTC, ebakke
Details
Proposed patch (1.30 KB, patch)
2017-02-25 13:04 UTC, ebakke
Details | Diff
Flipping in Patch 2 (3.40 MB, video/x-ms-wmv)
2017-07-07 11:12 UTC, mac3000
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ahah 2016-12-29 19:24:00 UTC
Created attachment 163309 [details]
Screencast showing flip back during mouse wheel scroll

To reproduce:
Click to a new position in the editor (seems to happen with java files only).
Start scrolling with the mouse wheel.

After a few hundred lines of scrolling the position flips back where you started 
and you need to start scrolling from scratch.

The second time however scrolling succeeds.

This is very distracting.
Everything worked fine until i accepted the proposed updates a couple weeks ago.


Thank you for taking time reading this.


Product Version: NetBeans IDE 8.2 (Build 201609300101)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 1
Java: 1.8.0_111; Java HotSpot(TM) 64-Bit Server VM 25.111-b14
Runtime: Java(TM) SE Runtime Environment 1.8.0_111-b14
System: Linux version 4.4.0-57-generic running on amd64; UTF-8; en_US (nb)
Comment 1 dhadzic9 2017-01-12 13:04:35 UTC
I've noticed the same bug on Windows.

Product Version: NetBeans IDE 8.2 (Build 201609300101)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 1
Java: 1.8.0_111; Java HotSpot(TM) 64-Bit Server VM 25.111-b14
Runtime: Java(TM) SE Runtime Environment 1.8.0_111-b14
System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
Comment 2 ebakke 2017-01-17 17:11:20 UTC
Created attachment 163415 [details]
Another screencast showing Java editor skipping back when scrolling down

I've observed this bug constantly since upgrading to 8.2, though I only just now managed reproduce it consistently. It's extremely disorienting. I'm on MacOS myself, scrolling mostly using the two-finger gesture on the MacBook Air trackpad.

In the attached screencast, the bug happens at 00:05. The bug seems to trigger when the cursor is located after the brace closing a method, such that the editor pops up a little tooltip to show what the first line of the method is (the tooltip that says "private static boolean isXPTheme() {" in the example, although in this case the tooltip doesn't show up until a little while after the bug is triggered).
Comment 3 ebakke 2017-01-17 17:14:39 UTC
Actually, as the original poster describes, this bug happens once _every_ single time the user clicks to change the cursor position in a Java file and then scrolls away--the scroll viewport skips back to put the cursor in the middle of the screen.

This is a high-impact bug.
Comment 4 Geoff_C 2017-02-10 04:11:30 UTC
Constantly reproducible in Java files, but it appears to be dependent on the number of lines you scroll.

It has to be about 240 lines or so, so the file needs to be long enough. Size of the view/amount of file visible doesn't have any effect, have seen it with 10 lines visible and 40. Semantic location within file also had no effect.

Open a file of say 400 lines. Place cursor at line 100, scroll as slowly or as quickly as you like to around 340 (you can even pause along the way), and as soon as you hit the magic number you'll be flipped back.

I thought it was poor mouse control on my part the first few times, glad to read that it's not!

Product Version: NetBeans IDE 8.2 (Build 201609300101)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 1
Java: 1.8.0_92; Java HotSpot(TM) 64-Bit Server VM 25.92-b14
Runtime: Java(TM) SE Runtime Environment 1.8.0_92-b14
System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)
Comment 5 Geoff_C 2017-02-10 05:12:19 UTC
(In reply to Geoff_C from comment #4)
> Constantly reproducible in Java files, but it appears to be dependent on the
> number of lines you scroll.
> 
> It has to be about 240 lines or so, so the file needs to be long enough.
> Size of the view/amount of file visible doesn't have any effect, have seen
> it with 10 lines visible and 40. Semantic location within file also had no
> effect.
> 
> Open a file of say 400 lines. Place cursor at line 100, scroll as slowly or
> as quickly as you like to around 340 (you can even pause along the way), and
> as soon as you hit the magic number you'll be flipped back.
> 
> I thought it was poor mouse control on my part the first few times, glad to
> read that it's not!
> 
> Product Version: NetBeans IDE 8.2 (Build 201609300101)
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 1
> Java: 1.8.0_92; Java HotSpot(TM) 64-Bit Server VM 25.92-b14
> Runtime: Java(TM) SE Runtime Environment 1.8.0_92-b14
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (nb)

I might be leading you astray with the number of lines, it seems to differ when scrolling up as opposed to down, and while the number is often consistent, it's not always so.
Comment 6 ebakke 2017-02-17 01:09:19 UTC
I ended up downgrading to NetBeans 8.1 to avoid this bug--it was very difficult to work in the IDE otherwise. Having now used NetBeans 8.1 for two weeks, I can confirm the bug does not occur in that version--it must have been introduced in 8.2.
Comment 7 Vladimir Voskresensky 2017-02-17 10:03:53 UTC
I agree, that it become very annoying, when you scroll up the file, see you code and suddenly you are out of lines again
Comment 8 Pere 2017-02-24 13:10:29 UTC
Oh my god! I've had to ask for THREE new mouses in my new job, which involved switching from programming in PHP to Java. As I've been a Netbeans user for years and never experienced this, I though it was a hardware problem, just to find that it only happens in Java. 

This is very annoying, distracting and unproductive. To the point that is the last factor I needed to abandon this IDE in favour of a more robust one. This even put my new job at risk, as my new bosses and colleagues thought I was mad...
Comment 9 ebakke 2017-02-24 22:30:36 UTC
Attaching a listener to the vertical scroll pane from org.netbeans.modules.editor.NbEditorUI.createExtComponent, the big jump in Y position happens from the following stack trace:

======================================================
java.lang.Exception
	at org.netbeans.modules.editor.NbEditorUI$3.stateChanged(NbEditorUI.java:270)
	at javax.swing.DefaultBoundedRangeModel.fireStateChanged(DefaultBoundedRangeModel.java:364)
	at javax.swing.DefaultBoundedRangeModel.setRangeProperties(DefaultBoundedRangeModel.java:302)
	at javax.swing.JScrollBar.setValues(JScrollBar.java:623)
	at javax.swing.plaf.basic.BasicScrollPaneUI.syncScrollPaneWithViewport(BasicScrollPaneUI.java:285)
	at javax.swing.plaf.basic.BasicScrollPaneUI$Handler.stateChanged(BasicScrollPaneUI.java:1039)
	at javax.swing.JViewport.fireStateChanged(JViewport.java:1369)
	at javax.swing.JViewport.setViewPosition(JViewport.java:1125)
	at javax.swing.JViewport.scrollRectToVisible(JViewport.java:436)
	at javax.swing.JComponent.scrollRectToVisible(JComponent.java:3111)
	at javax.swing.JComponent.scrollRectToVisible(JComponent.java:3111)

	at org.netbeans.api.editor.caret.EditorCaret.update(EditorCaret.java:2020)
	at org.netbeans.api.editor.caret.EditorCaret.access$400(EditorCaret.java:169)
	at org.netbeans.api.editor.caret.EditorCaret$7.run(EditorCaret.java:1901)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
	at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
======================================================
Comment 10 ebakke 2017-02-25 13:04:14 UTC
Created attachment 163708 [details]
Proposed patch

Here's a proposed patch that fixes the bug. The one-line change should probably be reviewed by someone who knows the code in EditorCaret.

The problem is that in some cases, EditorCaret.runTransaction sets the scrollToLastCaret flag to true without dispatching a call to EditorCaret.update (via dispatchUpdate) to reset the flag again.

Here are the full details of how the bug happens. When the user clicks in the editor to move the text caret, the following happens:
* On mousePressed:
  * EditorCaret$ListenerImpl.mousePressed is called, calling EditorCaret.setDot,
    which calls EditorCaret.runTransaction.
  * EditorCaret.runTransaction sets scrollToLastCaret to true and calls
    dispatchUpdate, which calls update.
  * EditorCaret.update scrolls to the cursor and resets scrollToLastCaret. All
    good.
* On mouseReleased:
  * EditorCaret$ListenerImpl.mouseReleased is called, calling
    EditorCaret.moveDot, which calls EditorCaret.runTransaction. (The caret dot
    is updated both on mousePressed and mouseReleased.)
  * Like before, EditorCaret.runTransaction sets scrollToLastCaret to true.
    But this time, it does _not_ call dispatchUpdate, because the dot has not
    changed and activeTransaction.isDotOrStructuralChange() returns false.
    Instead, scrollToLastCaret is just left on.
* Much later, say after the user has done some scrolling of their own and some
  unrelated editor-related module causes EditorCaret.dispatchUpdate to be
  called, dispatchUpdate picks up on the old "true" value of scrollToLastCaret
  flag and scrolls back to the cursor.
  * In this case, it was
    org.netbeans.modules.editor.fold.ui.CodeFoldingSideBar.getPaintInfo which
    called BaseTextUI.getPosFromY, which caused some recalculations in the
    DocumentView, which caused DocumentView.validChange to get called, which
    caused EditorCaret.dispatchUpdate to be called when BaseTextUI.getPosFromY
    called LockedViewHierarchy.unlock.
  * Even though BaseTextUI.getPosFromY sounds like a read-only operation, I
    don't think it's a bug that EditorCaret.dispatchUpdate is called as a
    result; it seems to be part of the design. The bug is that an old value of
    EditorCaret.scrollToLastCaret is left behind for dispatchUpdate to stumble
    upon.

The proposed fix makes sure to call dispatchUpdate if CaretTransaction.isScrollToLastCaret() returns true, even if the caret hasn't moved (per CaretTransaction.isDotOrStructuralChange()). An alternative would be to not set EditorCaret.scrollToLastCaret in this case, but the "Scroll even if setDot() to same offset" comment in CaretTransaction suggests the former solution is more correct.

Tested on latest mercurial checkout 0c47e1af3257.
Comment 11 Tuupertunut 2017-02-25 15:06:31 UTC
*** Bug 269397 has been marked as a duplicate of this bug. ***
Comment 12 Vladimir Voskresensky 2017-02-26 18:50:17 UTC
Rising this regression to P1. It bothers quite a few people
Comment 13 Pere 2017-02-28 07:56:11 UTC
Is this patch already applied in some nightly? Please address it soon, as it doesn't simply "bothers", but renders the full IDE almost unusable...
Comment 14 emi 2017-02-28 21:43:58 UTC
Miloslav, I see this class has been modified almost exclusively by you so I've reassigned this bug.

Please take a look at the patch, it seems correct.
Comment 15 Pere 2017-03-01 07:20:17 UTC
I'm answering myself because I tried nightly 20170228 and of course the patch is not applied there.
Comment 16 emi 2017-03-01 09:00:24 UTC
The patch has just been suggested by ebakke, it has not been reviewed by somebody from NetBeans or applied.
Comment 17 Miloslav Metelka 2017-03-02 15:20:09 UTC
(In reply to ebakke from comment #10)
> Created attachment 163708 [details]
> Proposed patch
> 
ebakke many thanks for the detailed analysis and the patch. I've slightly modified the patch to only dispatch an update (and not fire caret change) in case just the scroll flag was set.

http://hg.netbeans.org/jet-main/rev/bbbf519928ab
Comment 18 ebakke 2017-03-03 08:36:52 UTC
Thanks, Miloslav--I tested the updated patch and it still fixes the bug on my system.
Comment 19 Quality Engineering 2017-03-04 04:00:23 UTC
Integrated into 'main-silver', will be available in build *201703040002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/bbbf519928ab
User: Miloslav Metelka <mmetelka@netbeans.org>
Log: #269451 - Scroll position flips back on scrolling with mouse wheel.
Comment 20 Geoff_C 2017-03-06 06:01:51 UTC
Will this fix be issued as an update for 8.2 IDE, or do we need to start using the Dev builds to take advantage of it? Thanks!
Comment 21 Milutin Kristofic 2017-03-07 13:41:02 UTC
*** Bug 269894 has been marked as a duplicate of this bug. ***
Comment 22 Milutin Kristofic 2017-03-07 13:41:20 UTC
*** Bug 269960 has been marked as a duplicate of this bug. ***
Comment 23 Pere 2017-03-10 12:00:19 UTC
I've been testing this since the 1st build with the patch was available, and it seemed to be working. However, I just seemed to experience a suspicious jump a moment ago while scrolling a lot of text and (maybe?) reaching the end of the file. Will keep an eye on this.
Comment 24 ilia 2017-04-13 10:45:32 UTC
https://netbeans.org/bugzilla/show_bug.cgi?id=269451 Changesets:
    http://hg.netbeans.org/releases/rev/5f544e743ce5 # #269451 - Scroll position flips back on scrolling with mouse wheel.
Comment 25 shoujin 2017-05-10 10:41:07 UTC
So, when can we have this in 8.2? Checking for updates comes up with nothing.

And it isn't ideal at all having to install a completely new version of Netbeans, seeing as we can't make the nightly install replace the old installation...
Comment 26 snackr 2017-05-23 04:20:04 UTC
Can we apply the patch w/o having to install a new version of NetBeans?
How can we get the fix applied?
This is so annoying.
Comment 27 twifty 2017-05-23 04:40:04 UTC
I've been using the patch since it was created and can confirm it is fixed. I have not had a single issue.

For those of you still on 8.2, try upgrading to the development build, at least until 8.3 is released. TBH, Ever since I start using the dev build, I have never switched back. It's also useful for the netbeans team in that we can catch these bugs before they reach production.
Comment 28 emi 2017-05-23 05:20:57 UTC
> snackr@netbeans.org
> Can we apply the patch w/o having to install a new version of NetBeans?
> How can we get the fix applied?

You could take a nightly build and copy the editor.lib2/src/org/netbeans/api/editor/caret/EditorCaret class file into your own JAR. Or just replace the editor-lib2 JAR altogether. Make a backup before so you don't break your install.
Comment 29 Geoff_C 2017-05-25 01:09:15 UTC
For every user that gets involved in bug reporting and followup, especially to the extent of downloading and using nightlies, or trawling through modules to pick out a fix to put in their production environment, there are probably a dozen or even a hundred who wont or can't do that. How many of them will walk away?

Is Netbeans a production-ready IDE offering, or a proof-of-concept experiment? Do most people want to be downloading nightlies and messing with restoring broken installs when they're supposed to be writing software?

Netbeans has an auto-update feature. Why is it that this jar cannot be supplied via that feature? Then you have 100 satisfied (or at least not disgruntled) users for every user that is satisfied by the solution of "download a nightly or pick out a jar".
Comment 30 shoujin 2017-05-25 02:16:11 UTC
(In reply to Geoff_C from comment #29)
> For every user that gets involved in bug reporting and followup, especially
> to the extent of downloading and using nightlies, or trawling through
> modules to pick out a fix to put in their production environment, there are
> probably a dozen or even a hundred who wont or can't do that. How many of
> them will walk away?
> 
> Is Netbeans a production-ready IDE offering, or a proof-of-concept
> experiment? Do most people want to be downloading nightlies and messing with
> restoring broken installs when they're supposed to be writing software?
> 
> Netbeans has an auto-update feature. Why is it that this jar cannot be
> supplied via that feature? Then you have 100 satisfied (or at least not
> disgruntled) users for every user that is satisfied by the solution of
> "download a nightly or pick out a jar".

This is so true.

For example, I have registered because of this and I have tried the nightly. It just isn't satisfactory for me.

This fix seems benign to me to be definitely distributed over the auto-update feature rather than a completely separate version that needs a full blown download, install, reconfiguration etc.
Comment 31 emi 2017-05-25 05:47:12 UTC
Indeed, the patch is small enough to be a patch candidate for the release82 branch.

I'm reopening the bug so it is taken into consideration for inclusion.
Comment 32 emi 2017-05-25 05:50:04 UTC
Actually, I see the patch is already part of 8.2: http://hg.netbeans.org/releases/rev/5f544e743ce5

So, it's just a matter of waiting for the next point release.

Sorry for reopening the issue.
Comment 33 xupwup 2017-05-25 11:36:26 UTC
(In reply to emi from comment #32)
> So, it's just a matter of waiting for the next point release.

When will that be?
Comment 34 tcfurrer 2017-05-25 16:32:58 UTC
Please do a point release as soon as possible.  Users need this fix.
Comment 35 Jiri Kovalsky 2017-05-31 22:36:49 UTC
Once bug #270757 is fixed on 6/2 we will build the installers together with new Update Center, test it and then finally publish the patch on live UC.
Comment 36 emi 2017-06-05 15:12:07 UTC
I believe this fix should be in the Update Center.
Comment 37 Geoff_C 2017-06-05 23:14:31 UTC
It is indeed, and I can confirm it updates and fixes the problem. Thanks very much to you all!
Comment 38 shoujin 2017-06-06 11:31:16 UTC
Thank you!
Comment 39 snackr 2017-06-19 23:53:49 UTC
Thanks for fixing this and adding it to the last patch !!!
Comment 40 mac3000 2017-07-07 11:10:14 UTC
My NetBeans still flips back to cursor when scrolling by mouse wheel, I already have patch 2. Most often when Netbeans is not maximized, I add a video when it is on half screen in a moment. I cannot record when Netbeans is maximized, but sometimes it happens in such condition.


Product Version: NetBeans IDE 8.2 (Build 201609300101)
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
Java: 1.8.0_121; Java HotSpot(TM) 64-Bit Server VM 25.121-b13
Runtime: Java(TM) SE Runtime Environment 1.8.0_121-b13
System: Windows 7 version 6.1 running on amd64; Cp1250; pl_PL (nb)
User directory: C:\Users\*\AppData\Roaming\NetBeans\8.2
Cache directory: C:\Users\*\AppData\Local\NetBeans\Cache\8.2
Comment 41 mac3000 2017-07-07 11:12:12 UTC
Created attachment 164719 [details]
Flipping in Patch 2
Comment 42 ebakke 2017-07-11 22:10:21 UTC
(In reply to mac3000 from comment #41)
> Created attachment 164719 [details]
> Flipping in Patch 2

Hmm, I have never observed the bug since applying Patch 2, and was not able to reproduce it with the old method (or by trying to mimic the video you posted). Mac3000, do you have a reliable way of reproducing the "resurfaced" bug?
Comment 43 twifty 2017-07-12 04:20:42 UTC
@ebakke

I recently created a new issue https://netbeans.org/bugzilla/show_bug.cgi?id=270972 with the same symptoms. It is directly related to the code folding feature.

I have also noticed the same symptoms, auto scrolling, when the cursor is placed on or near a closing brace in such a way that the editor pane creates a popup window containing the opening brace line contents. This one is difficult to reliably reproduce and may in fact be fixed alongside the above new issue.

To reproduce, a large function block is required. place the cursor, make sure the popup window is created, then scroll up but not all the way to the opening brace (keeping the popup in view). After a second or so, the auto scroll kicks in. It's very difficult to reproduce and only happens about 10% of the time.

To be honest, I would fix the above new issue before investigating this any further.

As for this issue, I believe it is fixed.
Comment 44 Vladimir Voskresensky 2017-07-12 09:48:54 UTC
So, closing as fixed


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo