innerText randomly removes newline of `white-space: pre-line`
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox133 | --- | fixed |
People
(Reporter: m.englisch, Assigned: jfkthame)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Steps to reproduce:
- Open the showcase.html (attached) in Firefox.
- In the contenteditable table field, just add any char after "three"
(And then read it's content using innerText.)
Actual results:
innerText returns:
"one
twothree"
Tested to fail on version:
133.0a1 (2024-10-09)
132.0b5
128.3.1esr
Expected results:
innerText should return:
"one
two
three"
There is no reason for innerText remove the newline between two and three.
|
||
Comment 1•16 days ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•16 days ago
|
||
Can confirm this behaviour in Fireofx. Can repro on a build from Jan2021, so not a new regression.
Chrome prints "one two three".
|
||
Comment 3•11 days ago
|
||
Indeed, I reproduce this bug too, but it seems that it's not related that whether the content is editable or not. And I reproduce this only with pre-line but not with pre. It seems that this is a bug in nsTextFram::GetRenderedText() because GetInnerText() implementation in the DOM module does not build the result string by itself.
|
Assignee | |
Comment 4•11 days ago
|
||
Yes, I think this is a bug in nsTextFrame::GetRenderedText(). Specifically, it iterates over a chain of continuation frames (the loop here) with textFrame being the current continuation to be examined. But a few times inside that loop, like here, it calls nsTextFrame methods (like HasSignificantTerminalNewline()) without the textFrame-> prefix, and so it's actually calling the method on the primary frame (this), not the continuation that it's trying to handle.
|
|
Assignee | |
Updated•11 days ago
|
|
|
Assignee | |
Comment 5•11 days ago
|
||
For clarity, we refactor body of the loop-over-continuations in
nsTextFrame::GetRenderedText into a helper method AppendRenderedText
that handles a single continuation in the chain.
This avoids the footgun of an nsTextFrame method iterating over its
continuations (using the textFrame variable) but potentially calling
methods of the primary frame within the loop, instead of the current
frame being processed.
Marcel Englisch: Thank you for your bug report. I have a question about the reported case. Your testcase specifies white-space: pre-line to an editable element. That means that if users types multiple white-spaces consecutively, browsers replace some white-spaces with non-breakable spaces (a.k.a., NBSP, , U+00A0) to make the consecutive white-spaces visible. Therefore, I didn't assume that web developers want to use pre-line with contenteditable. So, my question is, why do you want to use pre-line rather than normal, pre and pre-wrap?
|
Reporter | |
Comment 12•8 days ago
|
||
You're very welcome. Glad I could help.
To your question: I had an web app that uses innerHTML and encodes/decodes all by itself. Last week I experimented using innerText and white-space as it fits better my use case. It was pre-line because I didn't understand how exactly white-space-values work at that time. Shortly after I reported this bug I noticed that pre-wrap is the correct value for my use case. Impressive that you noticed that even without knowing what I'm doing.
Thank you for your work and fast response!
Thank you for explaining the detail. Okay, then, we don't need to fix bug 1925428 before shipping contenteditable=plaintext-only.
Description
•