Bug 553377

Summary:

StyledTextRenderer max width can be invalid

Product:

[Eclipse Project] Platform

Reporter:

Paul Pazderski <paul-eclipse>

Component:

SWT

Assignee:

Paul Pazderski <paul-eclipse>

Status:

REOPENED ---

QA Contact:

Severity:

normal

Priority:

Version:

4.13

Target Milestone:

---

Hardware:

All

OS:

All

See Also:

https://git.eclipse.org/r/153247
https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=795aeac59686647adf9dd0ea194583482609ac01
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559230

Whiteboard:

Bug Depends on:

Bug Blocks:

343086

Attachments:

Description	Flags
Not claimed horizontal space after text change	none

Description Paul Pazderski

2019-11-22 17:38:34 EST

Created attachment 280766 [details]
Not claimed horizontal space after text change

StyledTextRenderer tracks the width of the longest line. This value can be wrong because the current max width is not correctly invalidated on some text changes.

This first situation can be reproduced by scrolling to the right end of the control and remove some text from the longest line and (in the same operation) something from the next line.
See attached screenshot for the steps and result. It should claim the free horizontal space but did not as you can see on the still available horizontal scroll bar.
This test case is derived from bug 343086. It is also triggered by wrong max width and an additional bug in StyledText.

Another impact of this bug I found can be triggered programmatically. When the longest line is not currently visible and this longest line is changed the horizontal scroll bar is updated for the second longest line (the longest line not modified by the change event). This is automatically corrected as soon as the longest line is visible again.

Comment 1 Paul Pazderski

2019-11-22 18:02:53 EST

I wanted to make a minimal change which worked for the first case but not for the second. The first problem arise in StyledTextRenderer#textChanging. As last step it updates max width if the current max width line is part of the change. But the code block before can change the startLine variable which breaks the test if longest line is part of the change.

But the update of max width itself is invalid. It calculates the longest line on partial unavailable data and the result is the longest known(!) line and not the longest of all lines.

My proposed solution is to calculate max width more on demand. If the current max width is known we update it as we can but if not, e.g. a content change changed the max line the recalculation of max width is postponed until the width is actually needed.

Comment 2 Eclipse Genie

2019-11-22 18:07:29 EST

New Gerrit change created: https://git.eclipse.org/r/153247

Comment 3 Paul Pazderski

2020-01-06 03:29:12 EST

Had not yet found the reason for test failure so need to move target milestone.

Comment 4 Paul Pazderski

2020-01-06 11:35:07 EST

Finally got this awful failure. Apparently the test was only failing on gerrit because of different system font...

Will merge after M1.

Comment 5 Eclipse Genie

2020-01-10 13:39:24 EST

Gerrit change https://git.eclipse.org/r/153247 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=795aeac59686647adf9dd0ea194583482609ac01

Comment 6 Paul Pazderski

2020-01-16 05:39:41 EST

Reopened because fix was reverted.