1615811 - Elements with text-overflow: ellipsis; do not remove the dots when their content shortens via javascript

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Martin]

Attachment: truncate.html

Suppose there is an element p with overflowing text truncated by displaying the three dots using text-overflow:ellipsis. Now the textual contents of p changes (either by changing the innerHTML or the text node's nodeValue) and the new text is shorter than the available space.

Actual Behaviour:
The three dots do not dissappear. They only do after somehow another redraw of that region is triggered e.g. by hovering over a scrollbar or by resizing the window.

Expected Behaviour:
The three dots should disappear when the text is updated.

See also the attached minimal example and gif animation (attached as comment) demonstrating the problem.
I can reproduce the issue on Windows 7 and Linux x64_64.

Any workaround to let the dots disappear using javascript is highly appreciated, as this is a big issue for me at the moment.

kind regards

Comment 1

[Martin]

Attachment: demonstration of the problem

Comment 2

[Emilio Cobos Álvarez (:emilio)]

This one is an interesting one. Ellipsis is just a paint-time effect, and I think we're not invalidating them properly.

Anything that causes a repaint of the block (like changing color or something of that sort) "fixes" it.

It'd be interesting to know if this is a regression, but I can't run mozregression right now due to bandwidth limitations.

Comment 3

[Alice0775 White]

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47752e9824da5125cb99c9d8160795b59adcc407&tochange=fc194660762d1b92e1679d860a8bf41116d0f54f

Regressed by: Bug 1416055

I can reproduce the issue on Nightly75.0a1(20200215095617)
And I confirmed that set layout.display-list.retain to false fixes the issue.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Thank you Alice, you're awesome :)

I'm not quite sure how to better invalidate this... It seems we have to invalidate the block when the overflow area becomes less than the frame size or such... Matt / Miko do we invalidate frames in response to overflow changes already somewhere? If so, where? I suspect this'd be a pretty simple change.

Comment 5

[Matt Woodrow (:mattwoodrow)]

We don't rebuild display items when overflow changes, since overflow frequently changes on the ancestor of the modified frame, and then we'd rebuild items for all descendants of that ancestor. Generally, that's a lot more than what actually changed.

text-overflow:ellipsis is a weird special case where the painting of the ancestor block depends on changes from descendants (the text content).

I think we could detect when overflow changes (FinishAndStoreOverflow returns this), we're a block with text-overflow:ellipsis and then use something like nsFrame::DiscardOldItems.

That'll mark the individual items created by the block as being invalid, but won't trigger rebuilding of that whole subtree. If we've changed overflow, then building must descend through the current frame to get to the modified descendant, so we should be guaranteed that we'll rebuild the items for the current frame if needed.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Alright, that's great, thanks!

Will give something like that a shot.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1615811 - Invalidate old display items if overflow changes on an element that can display ellipsis. r=mattwoodrow,miko

Comment 8

[Emilio Cobos Álvarez (:emilio)]

The suggested change by Matt in the revision breaks the testcase again, so I have to dig tomorrow to figure out why. Some chat copy-paste for my own benefit tomorrow:

emilio mattwoodrow: passing false for aFrameChanged breaks the text-overflow test again, so that won't fly :-/
mattwoodrow emilio: Aww :( Do you know why?
My expectation is the text frame descendant itself is modified, so DL building will descend through the block to build the new text items
emilio mattwoodrow: I don't, but I can dig tomorrow if you tell me what to look for... What do you expect that should happen?
mattwoodrow The existing ellipsis items have been individually marked as to be discarded, so those should be dropped
emilio (ok, midaired, sorry :))
mattwoodrow and the block won't build new one, since we no longer need them given the new overflow
emilio Ok, will look at why that's not happening tomorrow, thanks!
mattwoodrow RetainedDisplayList builder has some commented out dumps that show you the new partial list (which should not contain ellipsis items, but should have the new text)
emilio Cool, noted, thanks again :)

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3b85097d2d63
Invalidate old display items if overflow changes on an element that can display ellipsis. r=mattwoodrow

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/21939 for changes under testing/web-platform/tests

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 12

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/3b85097d2d63

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot