Elements with text-overflow: ellipsis; do not remove the dots when their content shortens via javascript
Categories
(Core :: Web Painting, defect)
Tracking
()
People
(Reporter: hier-bei-mir, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
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
Assignee | ||
Comment 2•5 years ago
|
||
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•5 years ago
|
||
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.
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
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•5 years ago
|
||
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.
Assignee | ||
Comment 6•5 years ago
|
||
Alright, that's great, thanks!
Will give something like that a shot.
Assignee | ||
Comment 7•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
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 :)
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3b85097d2d63 Invalidate old display items if overflow changes on an element that can display ellipsis. r=mattwoodrow
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/21939 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Comment 12•5 years ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Updated•5 years ago
|
Description
•