This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Scroll position flips back on scrolling with mouse wheel. | ||
|---|---|---|---|
| Product: | editor | Reporter: | ahah |
| Component: | -- Other -- | Assignee: | Miloslav Metelka <mmetelka> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | akobberup, Geoff_C, issues, jinahya, Pere, shoujin, tcfurrer, twifty |
| Priority: | P1 | Keywords: | REGRESSION, SIMPLEFIX |
| Version: | 8.2 | ||
| Hardware: | PC | ||
| OS: | All | ||
| See Also: | https://netbeans.org/bugzilla/show_bug.cgi?id=270972 | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 269397 | ||
| Attachments: |
Screencast showing flip back during mouse wheel scroll
Another screencast showing Java editor skipping back when scrolling down Proposed patch Flipping in Patch 2 |
||
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) 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).
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. 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) (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. 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. I agree, that it become very annoying, when you scroll up the file, see you code and suddenly you are out of lines again 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... 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) ====================================================== 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.
*** Bug 269397 has been marked as a duplicate of this bug. *** Rising this regression to P1. It bothers quite a few people 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... 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. I'm answering myself because I tried nightly 20170228 and of course the patch is not applied there. The patch has just been suggested by ebakke, it has not been reviewed by somebody from NetBeans or applied. (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 Thanks, Miloslav--I tested the updated patch and it still fixes the bug on my system. 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. 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! *** Bug 269894 has been marked as a duplicate of this bug. *** *** Bug 269960 has been marked as a duplicate of this bug. *** 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. 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. 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... 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. 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. > 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.
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". (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. 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. 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. (In reply to emi from comment #32) > So, it's just a matter of waiting for the next point release. When will that be? Please do a point release as soon as possible. Users need this fix. 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. I believe this fix should be in the Update Center. It is indeed, and I can confirm it updates and fixes the problem. Thanks very much to you all! Thank you! Thanks for fixing this and adding it to the last patch !!! 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 Created attachment 164719 [details]
Flipping in Patch 2
(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? @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. So, closing as fixed |
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)