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.

Bug 241652 - Horizontal scrollbars stay put even after edited file no longer contains a long line
Summary: Horizontal scrollbars stay put even after edited file no longer contains a lo...
Alias: None
Product: editor
Classification: Unclassified
Component: Painting & Printing (show other bugs)
Version: 7.4
Hardware: Macintosh (x86) Mac OS X
: P4 normal with 1 vote (vote)
Assignee: Miloslav Metelka
Depends on:
Reported: 2014-02-10 16:50 UTC by ebakke
Modified: 2016-07-07 17:33 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description ebakke 2014-02-10 16:50:54 UTC
This bug is easy to reproduce:
1) Create a new empty file in NetBeans, and open the editor for it. Since the file is empty, there are no horizontal scrollbars.
2) Now type long line that goes beyond the end of the screen. Horizontal scrollbars will appear.
3) Now delete the long line, so that the file is once again empty. Here's the bug: the horizontal scrollbars still exist.
Comment 1 ebakke 2014-02-10 17:45:40 UTC
Some observations:
* JEditorPane.getPreferredSize() uses the preferred size calculation of its parent JComponent.getPreferredSize(), which takes its result from BasicTextUI.getPreferredSize(), which gets its result from BasicTextUI.RootView.getPreferredSpan(), which gets its result from RootView.view.getPreferredSpan().
* RootView.view is populated based on the editor kit for the JEditorPane. org.netbeans.editor.BaseKit.getViewFactory() returns org.netbeans.modules.editor.lib2.view.ViewFactoryImpl.INSTANCE which produces a org.netbeans.modules.editor.lib2.view.DocumentView when asked to create an element with name SectionElementName.
* So, in the end, the preferred size of the editor contents is given by org.netbeans.modules.editor.lib2.view.DocumentView.getPreferredSpan(), which actually defers to DocumentViewChildren.width().
* The problem seems to lie in DocumentViewChildren.childWidthUpdated, which is the only place where childrenWidth seems to be updated:

if (newWidth > childrenWidth)
  childrenWidth = newWidth;

* The only way to reset childrenWidth seems to be by creating a new DocumentView instance. But that only seems to happen when a new EditorKit is registered.
Comment 2 Martin Balin 2016-07-07 07:28:22 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss
Comment 3 ebakke 2016-07-07 17:33:39 UTC
Still reproducible in the latest build, but I now think it's by design (for performance reasons). It's possible to work around in applications that need the scrollbars to remain accurate. So WONTFIX seems reasonable.

Product Version: NetBeans IDE Dev (Build 201607070002)
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: Mac OS X version 10.9.5 running on x86_64; UTF-8; en_US (nb)