RESOLVED FIXED 138167
display: table-cell; bug when resizing window
https://bugs.webkit.org/show_bug.cgi?id=138167
Summary display: table-cell; bug when resizing window
Chris Rebert
Reported 2014-10-28 23:16:01 PDT
Created attachment 240594 [details] Relevant screenshots; (C) is the problem Original Bootstrap bug: https://github.com/twbs/bootstrap/issues/9774 To repro: 1. Open http://jsbin.com/laracu/2 in Safari. 2. Ensure that the window is fairly wide, such that the nav menu displays horizontally (screenshot A). If not, resize the window to be wider and reload the webpage. 2. Resize the window to be narrower, until the nav menu starts displaying vertically (screenshot B). 3. Resize the window to be wider, until the nav menu stops displaying vertically. 4. Observe that the nav menu hasn't returned to its original, expected appearance (screenshot A; i.e. one row of evenly spaced items), but instead displays as two rows, the first having 4 items and the second having two items (screenshot C). Happens on Safari version 8.0 (10600.1.25) on OS X Yosemite. (Incidentally, OS X 10.10 isn't available as an option in the "OS" field of this Bugzilla for some reason.) Chrome and Safari render the nav menu correctly in these circumstances. Chrome used to also exhibit this same bug, but has since fixed it. Possibly related to https://bugs.webkit.org/show_bug.cgi?id=113839 and/or https://bugs.webkit.org/show_bug.cgi?id=53166
Attachments
Relevant screenshots; (C) is the problem (22.03 KB, application/pdf)
2014-10-28 23:16 PDT, Chris Rebert
no flags
Copy of JS Bin example (4.33 KB, text/html)
2015-05-06 19:52 PDT, Chris Rebert
no flags
Test reduction (326 bytes, text/html)
2015-10-06 13:17 PDT, zalan
no flags
Patch (280.07 KB, patch)
2015-10-08 16:10 PDT, zalan
no flags
Archive of layout-test-results from ews101 for mac-mavericks (651.90 KB, application/zip)
2015-10-08 17:00 PDT, Build Bot
no flags
Archive of layout-test-results from ews107 for mac-mavericks-wk2 (711.66 KB, application/zip)
2015-10-08 17:08 PDT, Build Bot
no flags
Patch (281.04 KB, patch)
2015-10-08 20:29 PDT, zalan
no flags
Patch (281.04 KB, patch)
2015-10-08 22:14 PDT, zalan
no flags
Patch (280.86 KB, patch)
2015-10-09 20:34 PDT, zalan
no flags
Chris Rebert
Comment 1 2014-11-14 12:21:51 PST
Argh! It seems my PDF attachment was truncated so there's only the final page, although that's fortunately the most important one.
Chris Rebert
Comment 2 2014-11-14 12:25:59 PST
Also, typo in my description. Correction: "Chrome and **Firefox** render the nav menu correctly"
Chris Rebert
Comment 3 2014-11-14 14:11:13 PST
Have also filed this as <rdar://problem/18987206>
Chris Rebert
Comment 4 2015-05-06 19:52:56 PDT
Created attachment 252557 [details] Copy of JS Bin example
zalan
Comment 5 2015-10-06 13:17:43 PDT
Created attachment 262543 [details] Test reduction
Chris Rebert
Comment 6 2015-10-06 16:34:24 PDT
zalan
Comment 7 2015-10-07 20:34:04 PDT
This seems to be a insertion issue. When the content is sized back to form a table again, we end up with multiple table renderers and the content gets distributed "somewhat randomly". We start with a (generated) table renderer and multiple table cells. As the content gets squeezed we switch over to individual block renderers by destroying the table cells. However we keep the generated table renderer around. (R)elative/A(B)solute/Fi(X)ed/Stick(Y) positioned, (O)verflow clipping, (A)nonymous, (G)enerated, (F)loating, has(L)ayer, (C)omposited, (D)irty layout, Dirty (S)tyle ---G-L- D-* RenderView (0.00, 0.00) (773.00, 609.00) renderer->(0x1186e7a80) -----L- D- HTML RenderBlock (0.00, 0.00) (773.00, 609.00) renderer->(0x11e36be60) node->(0x11e369c98) ------- D- BODY RenderBody (8.00, 8.00) (757.00, 593.00) renderer->(0x11e36bf18) node->(0x11e369e38) ------- -- DIV RenderBlock (0.00, 0.00) (757.00, 18.00) renderer->(0x11e36b678) node->(0x11e369ea0) ------- -- SimpleLineLayout (1 lines, 1 runs) (0x11e316b70) ------- -- line 0 run(0, 1) (0.00, 0.00) (8.00, 18.00) "1" ------- -- #text RenderText renderer->(0x11e31e240) node->(0x11e3f70a0) length->(1) "1" ------- -- DIV RenderBlock (0.00, 18.00) (757.00, 18.00) renderer->(0x11e36b730) node->(0x11e369f08) ------- -- SimpleLineLayout (1 lines, 1 runs) (0x11e316bb8) ------- -- line 0 run(0, 1) (0.00, 0.00) (8.00, 18.00) "2" ------- -- #text RenderText renderer->(0x11e31e2a0) node->(0x11e380c30) length->(1) "2" ---G--- -- RenderTable (0.00, 36.00) (0.00, 0.00) renderer->(0x11e2bee18) ---G--- -- RenderTableSection (0.00, 0.00) (0.00, 0.00) renderer->(0x11e2b15c8) ---G--- -- RenderTableRow (0.00, 0.00) (0.00, 0.00) renderer->(0x11e3092f8) ------- -- DIV RenderBlock (0.00, 36.00) (757.00, 18.00) renderer->(0x11e36b7e8) node->(0x11e369f70) ------- -- SimpleLineLayout (1 lines, 1 runs) (0x11e316210) ------- -- line 0 run(0, 1) (0.00, 0.00) (8.00, 18.00) "3" ------- -- #text RenderText renderer->(0x11e31e300) node->(0x11e380cd0) length->(1) "3" When we size the content back and the divs become RenderCells again, the first insertion (for content "1") creates a generated table, while the subsequent insertions find the originally generated table renderer and they all get added there. (R)elative/A(B)solute/Fi(X)ed/Stick(Y) positioned, (O)verflow clipping, (A)nonymous, (G)enerated, (F)loating, has(L)ayer, (C)omposited, (D)irty layout, Dirty (S)tyle ---G-L- D-* RenderView (0.00, 0.00) (825.00, 609.00) renderer->(0x1186e7a80) -----L- D- HTML RenderBlock (0.00, 0.00) (825.00, 609.00) renderer->(0x11e36b678) node->(0x117341ea0) ------- D- BODY RenderBody (8.00, 8.00) (809.00, 593.00) renderer->(0x11e36b730) node->(0x1173417b8) ---G--- -- RenderTable (0.00, 0.00) (8.00, 18.00) renderer->(0x11e2be8f8) ---G--- -- RenderTableSection (0.00, 0.00) (8.00, 18.00) renderer->(0x11e2b1000) ---G--- -- RenderTableRow (0.00, 0.00) (8.00, 18.00) renderer->(0x11e32d000) ------- -- DIV RenderTableCell (0.00, 0.00) (8.00, 18.00) renderer->(0x11e30d000) node->(0x117341820) ------- -- SimpleLineLayout (1 lines, 1 runs) (0x118757378) ------- -- line 0 run(0, 1) (0.00, 0.00) (8.00, 18.00) "1" ------- -- #text RenderText renderer->(0x11e31e060) node->(0x1173f21e0) length->(1) "1" ---G--- -- RenderTable (0.00, 18.00) (16.00, 18.00) renderer->(0x11e2be520) ---G--- -- RenderTableSection (0.00, 0.00) (16.00, 18.00) renderer->(0x11e2d9cb8) ---G--- -- RenderTableRow (0.00, 0.00) (16.00, 18.00) renderer->(0x11e304260) ------- -- DIV RenderTableCell (0.00, 0.00) (8.00, 18.00) renderer->(0x11e30d0c8) node->(0x117341888) ------- -- SimpleLineLayout (1 lines, 1 runs) (0x1187573c0) ------- -- line 0 run(0, 1) (0.00, 0.00) (8.00, 18.00) "2" ------- -- #text RenderText renderer->(0x11e31e0c0) node->(0x1173f2d70) length->(1) "2" ------- -- DIV RenderTableCell (8.00, 0.00) (8.00, 18.00) renderer->(0x11e30d190) node->(0x1173418f0) ------- -- SimpleLineLayout (1 lines, 1 runs) (0x11e323b10) ------- -- line 0 run(0, 1) (0.00, 0.00) (8.00, 18.00) "3" ------- -- #text RenderText renderer->(0x11e31e600) node->(0x11e380140) length->(1) "3" So we end up with 2 generated table renderers -> content gets wrapped.
zalan
Comment 8 2015-10-07 21:32:42 PDT
related to bug 52123
zalan
Comment 9 2015-10-08 09:31:18 PDT
Removing all the anonymous table renderers fixes this issue.
zalan
Comment 10 2015-10-08 16:10:07 PDT
Build Bot
Comment 11 2015-10-08 17:00:50 PDT
Comment on attachment 262726 [details] Patch Attachment 262726 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/259150 New failing tests: editing/execCommand/crash-137961.html
Build Bot
Comment 12 2015-10-08 17:00:55 PDT
Created attachment 262728 [details] Archive of layout-test-results from ews101 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-mavericks Platform: Mac OS X 10.9.5
Build Bot
Comment 13 2015-10-08 17:08:45 PDT
Comment on attachment 262726 [details] Patch Attachment 262726 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/259159 New failing tests: editing/execCommand/crash-137961.html
Build Bot
Comment 14 2015-10-08 17:08:50 PDT
Created attachment 262730 [details] Archive of layout-test-results from ews107 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
zalan
Comment 15 2015-10-08 20:29:48 PDT
zalan
Comment 16 2015-10-08 22:14:53 PDT
zalan
Comment 17 2015-10-09 20:34:27 PDT
Dave Hyatt
Comment 18 2015-10-12 14:37:33 PDT
Comment on attachment 262815 [details] Patch r=me
WebKit Commit Bot
Comment 19 2015-10-12 15:33:38 PDT
Comment on attachment 262815 [details] Patch Clearing flags on attachment: 262815 Committed r190893: <http://trac.webkit.org/changeset/190893>
WebKit Commit Bot
Comment 20 2015-10-12 15:33:44 PDT
All reviewed patches have been landed. Closing bug.
Chris Rebert
Comment 21 2015-10-12 15:41:57 PDT
Yay! Thanks y'all!
Brent Fulgham
Comment 22 2015-10-12 17:55:41 PDT
These new tests need Windows-specific baselines!
Alexey Proskuryakov
Comment 23 2015-10-12 22:14:32 PDT
And iOS too!
Brent Fulgham
Comment 24 2015-10-13 10:45:40 PDT
(In reply to comment #22) > These new tests need Windows-specific baselines! Zalan committed these (for Windows) in <https://trac.webkit.org/changeset/190915>.
Alexey Proskuryakov
Comment 25 2022-06-09 11:38:20 PDT
*** Bug 113839 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.