Svatopluk Dedic created NETBEANS-6232:
-----------------------------------------
Summary: Line number and folding Sidebars may detach from the text
view after expand-all
Key: NETBEANS-6232
URL: https://issues.apache.org/jira/browse/NETBEANS-6232
Project: NetBeans
Issue Type: Bug
Components: editor - Code folding, editor - Painting & Printing
Affects Versions: 11.3
Reporter: Svatopluk Dedic
Attachments: detach_bug.png
This is a long-standing peculiar bug that possibly affects *all versions* of
NetBeans platform. It is not reproducible on NetBeans IDE as such (detals
later).
Consider a structured document, such as XML or JSON, that supports folding.
Let's configure autofolding, or have a FoldManager that autofolds all possible
lines.
When user is viewing such file with autofolded everything, he expands all - and
when scrolling down, the sidebars in the editor detach from the text content,
stop moving, but the text view is freely scrolled up to the end of the file.
See the attached screenshot. The right part is a scrolled contents - line
numbers are the same (remain at their positions), but the text content is
shifted.
The cause of this bug is timing: the sidebars (Glyph gutter, code folding, ...)
gets an appropriate *ViewHierarchyChangeEvent* marked as Y-change, and each of
them will post an update into EDT. The text component's *preferredSize*
property is already computed at the time the hierarchy event is delivered, but
the size did not yet materialize in text view's *bounds* or *size.* This will
happen after revalidation of the component tree, which has a low priority.
At the time the update proceeds, the text the revalidation *still did not
occur* sometimes - so these sidebars compute their effective height from *old
getSize()* value of the text editor. Only after that the text editor
revalidates, and has correct *size* property set from the layout manager.
The funny reason why this works in *NetBeans* is that there's an
AnnotationSideBar, that what god-knows-why reason multiplies the current size
of the editor * 2, so it computes always the preferredSize higher than the
screen slot, therefore forcing all other sidebars to be at least that high.
Our NB platform-based application has no such mathematician, so the bug
surfaced there.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
