Created attachment 357429 [details] Test case Several tests started to fail for GTK+ port when we switched to always use complex text. See for example: https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/r239206%20(9103)/fast/css/getComputedStyle/computed-style-font-family-pretty-diff.html Note that the only difference is that the expected output doesn't have a space between "Firefox behavior." and "stopPropagation called." This is because the simple line layout code path is taken in TextIterator::handleTextNode(). When forcing complex text, that path is not taken and a space is added, which is the correct behavior I guess. I've created a simple test to check this, see the attached file.
Created attachment 357439 [details] Test case2 Apparently we are supposed to preserve the collapsed new line for out of flow elements (and floats too).
*** Bug 192851 has been marked as a duplicate of this bug. ***
Committed r239564: <https://trac.webkit.org/changeset/239564>
<rdar://problem/46987463>
I bet this wasn't meant to be closed.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5) > I bet this wasn't meant to be closed. Yeah, I was wondering about that too.
I think it's a bug in webkit-patch. I landed a gardening patch mentioning this bug in the changelog description (not in the title), and decided to close this. I'll try to remember to use --no-close option next time.
Test case 2 is broken on macOS 12.5.1 in Safari Technology Preview 152 as well, it does not move "here" to next line like other browsers (Chrome Canary 107 and Firefox Nightly 106). *** Safari 15.6.1 / STP 152 *** Pass if there's a whitespace here *** Chrome Canary 107 & Firefox Nightly 106 *** Pass if there's a whitespace here _________ Just wanted to share updated status. Thanks!