846814 - Invalidation errors when highlighting text on eeemo.net

Status: NEW

(Core :: Layout, defect)

Description

[Chris Lord [:cwiiis]]

Attachment: 3 screenshots demonstrating error

Highlighting and unhighlighting text exposes invalidation bugs on eeemo.net.

Highlighting a subsection of a line causes other parts of the line to disappear, and unhighlighting doesn't return it to the correct state. Forcing a full invalidation by resizing the window or some other method causes it to redraw correctly.

Comment 1

[Matt Woodrow (:mattwoodrow)]

I can't reproduce this on Aurora.

I do see the different text rendering, but only within the selected area, and it reverts when I unselect.

It looks like the changed rendering is intentional, to make the selected text easier to read, but I'm not sure how that works. Seems plausible that this is changing text outside of the bounds that invalidation knows about.

Jonathan: Does the above sound familiar at all?

Comment 2

[Jonathan Kew [:jfkthame]]

I don't think it's deliberately changing anything during selection, but note that the selection background color will -overpaint- any diacritics from earlier lines that happen to fall within the bounds of the selected area, so they'll appear to vanish. So that would tend to make the selected part of the text look a little "cleaner".

Is it plausible that invalidation/repainting doesn't always cover the full extent of the "ink" that's involved, but only the typographic bounds of the selected text? The stacked diacritics here extend way above and below the nominal ascent and descent of the line - maybe we don't (reliably) invalidate and repaint those "ink overflow" extents during selection?

Comment 3

[Matt Woodrow (:mattwoodrow)]

That sounds like a better description of the behaviour I'm seeing.

For me, the overpainting only occurs within the selected area, and we revert this correctly when I deselect.

However, by the looks of Chris' screenshots, he's seeing the overpainting on the entire line of text, even if it's only partially selected.

What code is responsible for this happening?

Comment 4

[Chris Lord [:cwiiis]]

I can understand it changing during selection, but the problem I'm seeing is that it doesn't revert when you unselect - I think what Jonathan suggests in comment #2 sounds plausible. If it isn't reproduceable on Aurora, possibly a regression? Also possibly accelerated layers only?

Comment 5

[Matt Woodrow (:mattwoodrow)]

Even on trunk builds I still only see the rendering change within the bounds of the selection.

That's what is leading me to think that it might be something platform/font specific that causes it to change rendering for the entire affected line.

Comment 6

[Chris Lord [:cwiiis]]

(In reply to Matt Woodrow (:mattwoodrow) from comment #5)
> Even on trunk builds I still only see the rendering change within the bounds
> of the selection.
> 
> That's what is leading me to think that it might be something platform/font
> specific that causes it to change rendering for the entire affected line.

so for your equivalent run, your screenshots 1 and 3 are identical? If so, could well be the case... Not overly concerned about this, was worried it might be indicative of a larger bug. Seems unlikely now.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.