Bug 192750

Summary: SLL: innerText should preserve leading whitespace when the out-of-flow (or float) element starts with collapsed new line(s).
Product: WebKit Reporter: Carlos Garcia Campos <cgarcia>
Component: Layout and RenderingAssignee: alan <zalan>
Status: REOPENED    
Severity: Normal CC: aboya, ahmad.saleem792, bfulgham, emilio, koivisto, mcatanzaro, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: BrowserCompat, Gtk, InRadar, LayoutTestFailure
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
URL: https://bugs.chromium.org/p/chromium/issues/detail?id=916540
See Also: https://bugs.webkit.org/show_bug.cgi?id=193628
Bug Depends on:    
Bug Blocks: 289597    
Attachments:
Description Flags
Test case
none
Test case2 none

Carlos Garcia Campos
Reported 2018-12-17 01:23:56 PST
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.
Attachments
Test case (495 bytes, text/html)
2018-12-17 01:23 PST, Carlos Garcia Campos 		no flags
Details
Test case2 (143 bytes, text/html)
2018-12-17 07:48 PST, alan 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
alan
Comment 1 2018-12-17 07:48:41 PST
Created attachment 357439 [details] Test case2 Apparently we are supposed to preserve the collapsed new line for out of flow elements (and floats too).
Carlos Garcia Campos
Comment 2 2018-12-19 06:55:33 PST
*** Bug 192851 has been marked as a duplicate of this bug. ***
Carlos Garcia Campos
Comment 3 2018-12-31 05:36:28 PST
Committed r239564: <https://trac.webkit.org/changeset/239564>
Radar WebKit Bug Importer
Comment 4 2018-12-31 05:39:13 PST
<rdar://problem/46987463>
Emilio Cobos Álvarez (:emilio)
Comment 5 2019-01-02 08:26:20 PST
I bet this wasn't meant to be closed.
alan
Comment 6 2019-01-02 08:30:06 PST
(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.
Carlos Garcia Campos
Comment 7 2019-01-02 23:46:30 PST
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.
Ahmad Saleem
Comment 8 2022-09-03 14:20:14 PDT
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!
Note You need to log in before you can comment on or make changes to this bug.