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.
The knob (or thumb, slider, whatever you call it) of the vertical scrollbar represents, in position and size, the vertical region of the document that is currently visible in the editor's viewport. Similarly, the markers in the vertical stripe at the right of the scrollbar represent the position of errors, versioning changes etc. within the document. In NB 6.7, the scrollbar knob and the markers on the stripe are not correctly matched up any more, due to the fact that the scrollable region now may extend beyond the last line of the document, which (as far as I can tell) wasn't the case in NB 6.5.1 and earlier. Example: 1) Create a Java source file with a length of 100 lines. 2) Resize the editor such that exactly 50 lines are visible. 3) Write some invalid code in line 70 so that an error marker appears in the stripe. 4) Move to the top of the document (Ctrl+Home), and then jump to the bottom (Ctrl+End). Result: You'll see that the scrollbar knob now overlaps the error marker, although the line with the error is not currently visible in the editor. If you move the caret up line by line, you'll see that it reaches the top of the editor's viewport (line 76) long before the caret marker on the stripe reaches the top of the scrollbar knob. The reason for this is that a space of about 25 lines has been added below the document, which counts into the scrollbar's range, but not into the stripe, hence the discrepancy. This discrepancy can be very confusing, for example when you see in the stripe that there is a compile error (or versioning mark, etc.), and by the position of the scrollbar knob you know that you should see that error in the editor, but nothing is visible there. Besides this, there is another inconsistency: When moving to the bottom of the document not with Ctrl+End (or Page-Down), but line by line with Cursor-Down, scrolling stops at the last line of the document, which now is at the bottom of the viewport. But at the same time the scrollbar knob is not at the bottom of the scrollbar region, indicating that the document is actually longer. In that situation, even Page-Down or scrolling with Ctrl+Down does not scroll any further. Even weirder, when some part of the extra space at the bottom is visible, Ctrl+Down on the last line of the document causes the space to disappear, i.e. scrolls UP instead of down! Suggested solution: Having some extra space beyond the end of the document is nice, so that should be kept. A correct, consistent way to deal with that space is the following: 1) Only include as much of that space as is currently visible into the scrollbar's range. In other words, the knob would get slightly smaller as more of that extra space becomes visible. This has the desirable effect that the knob would always be at the bottom of the scrollbar when the bottom line of the document is visible. 2) Make the marker positions on the stripe match the scrollbar knob's size and position. As a consequence from (1), this means that the stripe's vertical range gets compressed a little bit as more of the extra space becomes visible. 3) Let Ctlr+Up/Ctrl+Down have the same effect as the up/down buttons of the scrollbar. That is they should include the extra space to scroll out of or into. (This suggestion is not my invention, it's taken from other editors I've worked with, and it's the only consistent design I'm aware of when providing such extra space.)
PS: NetBeans version is 6.7 RC3.
*** Issue 165175 has been marked as a duplicate of this issue. ***
*** Issue 167470 has been marked as a duplicate of this issue. ***
Thanks for the analysis. It's caused by the changes introduced in 6.7 by fixing issue #161700.
Matthies: Can you please clarify suggested solution 1? If I understand it correctly, it means that it would not be possible to scroll down to see all of the extra space using the scroll knob, right? I'm not saying it's right or wrong, just making sure I understand correctly.
olangr: Yes, it would not be possible to use the scroll knob to see more of the extra space than is already visible (if any). It would be possible to use the scrollbar's scroll-down button, or Ctrl+Down and possibly Page-Down, to see more of the extra space. The scroll knob would become slighlty smaller along with that, while remaining at the bottom. On second thought: It would theoretically be possible to detect downwards mouse dragging on the scroll knob, and make more of the extra space visible thereupon. (Similar to how, in a paint program, dragging a selection boundary or similar out of the viewport may cause scrolling.) But the scroll knob wouldn't move in that case (just change its size a little), as it already is at the bottom of the range.
PS: You wrote "solution 1". Just to be clear, the points 1-3 under "Suggested solution" in the description are three points that together constitute the (single) suggested solution.
Matthies: yes, I got it :-). Just that I was clear what you mean by points 2-3, I wasn't quite sure about point 1. +1 to suggested solution on behalf of NB UI team. note1: Scrolling down using the scroll-wheel should also reveal more of empty space beyond the EOF. note2: With large screens, there are over 20 empty lines beyond EOF. About 10 lines would certainly be more than enough (or 1/4 of the visible area)
It would be really nice to have this fixed for 6.8, as it keeps being quite annoying.
In issue 168075 I've modified the root view to return the extra vertical space instead of the text component which should fix the first problem. The extra vertical space is now just 1/3 of the viewport height. IMHO it's not desirable to tweak the scrollbar in the proposed way. It would be a non-standard behavior that would confuse users. Currently the Ctrl+Down can be used to scroll the view down including the extra vertical space. Not sure whether Down (and PgDn) once it reaches the last line should scroll into the extra space. Please check if the current behavior is acceptable for you and if not then please reopen the issue or better (since IMHO the issue is partly fixed) create a new issue with the specific things that do not currently work as desired.
Continued in issue 175712, as suggested by mmetelka.