Bug 52360 - No line break at zero-width spaces (ZWSP) if ZWSP is placed between tags
Summary: No line break at zero-width spaces (ZWSP) if ZWSP is placed between tags
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-13 00:57 PST by hikingfan
Modified: 2022-09-11 14:30 PDT (History)
10 users (show)

See Also:


Attachments
A small page that reproduces the bug (1.31 KB, text/html)
2011-01-13 00:58 PST, hikingfan
no flags Details
Patch (4.22 KB, patch)
2011-02-07 20:33 PST, Emil A Eklund
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description hikingfan 2011-01-13 00:57:47 PST
Overview:
WebKit doesn't seem to break lines at text nodes with only ZWSPs surrounded by inline elements.

Steps to reproduce:
1. Create a div element (specify a width if you want)
2. Create two spans that will each fit in the div, but not next to each other and contain no spaces.
3. Separate these spans with a ZWSP (​)

Actual result:
No line-break is inserted, they appear in the same line. The text runs out of the box.

Expected result:
The two spans appear in separate lines.

Build Date & Platform:
08 January 2011, Mac OS X 10.6.6

Additional Information:
See the attachment for a small page reproducing the bug.
Comment 1 hikingfan 2011-01-13 00:58:32 PST
Created attachment 78782 [details]
A small page that reproduces the bug
Comment 2 Emil A Eklund 2011-02-07 20:33:52 PST
Created attachment 81573 [details]
Patch
Comment 3 Eric Seidel (no email) 2011-02-07 23:26:31 PST
Looks reasonable to me.
Comment 4 Eric Seidel (no email) 2011-02-07 23:26:57 PST
What do other browsers do?  what spec covers this?  Please mention such in the ChangeLog.  Otherwise this looks ready to land.
Comment 5 mitz 2011-02-07 23:34:00 PST
Regardless of whether this is a desirable change, you can’t patch findNextLineBreak() and not make the corresponding change to RenderText::trimmedPrefWidths() or you’d incorrect min preferred widths.
Comment 6 Emil A Eklund 2011-02-17 15:02:30 PST
This isn't covered by any of the html specifications as far as I can tell. It is seems inconsistent to have different line breaking behavior in text and between inline elements though.

Both Gecko and IE wrap inline elements on zwsp.

mitz: Thanks for pointing that out, I was unsure whether I should change that and erred (incorrectly) on the side of caution. Are there any other things I need to look out for?
Comment 7 Emil A Eklund 2011-02-17 15:03:06 PST
Comment on attachment 81573 [details]
Patch

Marking patch as obsolete, will upload a new one addressing mitz's comments.
Comment 8 Tom Humphrey 2011-09-23 07:33:08 PDT
As well as zero-width spaces, maybe also consider splitting on other space types (hair, thin, em, en). 

Although the html 4 spec only recognises ZWSP as white-space (see http://www.w3.org/TR/html401/struct/text.html#h-9.1 ), handling the other types of space similarly seems harmless and would match the behaviour of Firefox and IE and would also make for consistency between the handling of space between inline elements and text (text already breaks on all of these).
Comment 9 Ahmad Saleem 2022-09-10 15:30:04 PDT
This patch has not landed while trying to search for bug ID on GitHub Webkit but this is not reproducible bug and does not cause the text to go outside of container and all browsers (Safari 15.6.1, Safari Technology Preview 153, Chrome Canary 107 and Firefox Nightly 106) render this same and does not lead the text going outside of div container.

Is the patch still needed or HTML5 Parser updates eliminated this bug? Appreciate if someone can comment and update the status accordingly. Thanks!
Comment 10 Alexey Proskuryakov 2022-09-11 13:20:56 PDT
Marking as resolved, as this doesn't reproduce any more.
Comment 11 zalan 2022-09-11 14:30:28 PDT
This is an IFC progression. Content still fails with legacy line layout.