Bug 182023 – White-space erratic behaviour in contenteditable elements

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[holytrousers]

Created attachment 332094 [details]
white-space pre not working on contenteditable div and textarea

setting white-space: pre; on a textarea (or any contenteditable element) doesnt prevent long lines from wrapping; 
actually it breaks inside a word.
the problem happens only in webkit2gtk based browsers ( tested on midori, luakit, surf, vimb etc )
and doesn't happen on chromium. 
tested webkit2gtk 2.18.5-1 on arch linux

[Michael Catanzaro]

(In reply to holytrousers from comment #0)
> Created attachment 332094 [details]
> white-space pre not working on contenteditable div and textarea

^ This attachment shows the problematic behavior (thanks!). I see horizontal scrollbars in Firefox and Chromium, but not in WebKit.

[Michael Catanzaro]

So Simon, the bug does not occur on Mac? Interesting....

[Simon Fraser (smfr)]

I assumed this is GTK only because the description says "the problem happens only in webkit2gtk based browsers"

[Michael Catanzaro]

(In reply to Simon Fraser (smfr) from comment #3)
> I assumed this is GTK only because the description says "the problem happens
> only in webkit2gtk based browsers"

Yeah, but the reporter only compared WebKitGTK+ and Chromium; WebKitGTK+ is the only modern version of WebKit that's readily-available on Linux. This looks like it's probably a cross-platform WebCore issue, so to find out could you test the HTML example in Safari, please? Should be just a matter of clicking on the attachment: there should be horizontal scrollbars and no line wrapping in all three of the examples, but on GTK the second and third example have line wrapping and no scrollbars.

[holytrousers]

(In reply to Michael Catanzaro from comment #4)
> (In reply to Simon Fraser (smfr) from comment #3)
> > I assumed this is GTK only because the description says "the problem happens
> > only in webkit2gtk based browsers"
> 
> Yeah, but the reporter only compared WebKitGTK+ and Chromium; WebKitGTK+ is
> the only modern version of WebKit that's readily-available on Linux. This
> looks like it's probably a cross-platform WebCore issue, so to find out
> could you test the HTML example in Safari, please? Should be just a matter
> of clicking on the attachment: there should be horizontal scrollbars and no
> line wrapping in all three of the examples, but on GTK the second and third
> example have line wrapping and no scrollbars.
Hello Michael,
I don't have mac os, but have tested this on safari 5.1.7 for windows and the same problem occurs, i wouldn't know about safari on mac os though ! Here is a screenshot https://i.imgur.com/JD8ERnA.png

[Wenson Hsieh]

I can reproduce this using STP 47 on macOS Sierra — the text wraps in the contenteditable and textarea, but does not wrap in the non-editable div.

[Michael Catanzaro]

(In reply to holytrousers from comment #5)
> Hello Michael,
> I don't have mac os, but have tested this on safari 5.1.7 for windows and
> the same problem occurs, i wouldn't know about safari on mac os though !
> Here is a screenshot https://i.imgur.com/JD8ERnA.png

(You might want to uninstall that, as Safari 5 has not had security updates since 2012.)

[holytrousers]

(In reply to Michael Catanzaro from comment #7)
> (In reply to holytrousers from comment #5)
> > Hello Michael,
> > I don't have mac os, but have tested this on safari 5.1.7 for windows and
> > the same problem occurs, i wouldn't know about safari on mac os though !
> > Here is a screenshot https://i.imgur.com/JD8ERnA.png
> 
> (You might want to uninstall that, as Safari 5 has not had security updates
> since 2012.)

Thanks for the tip, i have both windows and safari only to test things out, i usually use linux and webkit2gtk. 
Changed the platform to all..

[zalan]

I wonder if it is some special (legacy?) behavior since the last (textarea) example is simple line layout based and it clearly wraps the lines the same way the normal line layout does. Will look into it.

[Ahmad Saleem]

Just to update, in attached test case, all browsers (Safari Technology Preview 172, Chrome Canary 116 and Firefox Nightly 116) behaves same. If it is platform specific, can we add 'PlatformOnly' tag or rename it to add [WebKitGTK] to clarify in future?

[holytrousers]

This bug has been fixed at some point.
Thanks everyone !