RESOLVED FIXED Bug 77772
implement display: -webkit-inline-flex
https://bugs.webkit.org/show_bug.cgi?id=77772
Summary implement display: -webkit-inline-flex
Tony Chang
Reported 2012-02-03 13:34:50 PST
Currently this behaves the same as -webkit-flexbox, but should behave like inline-block.
Attachments
Patch (3.96 KB, patch)
2012-02-14 14:22 PST, Ojan Vafai
no flags
Patch (4.43 KB, patch)
2012-02-14 17:07 PST, Ojan Vafai
no flags
crash reduction 1 (541 bytes, text/html)
2012-08-07 11:48 PDT, Ojan Vafai
no flags
crash reduction 2 (476 bytes, text/html)
2012-08-07 11:48 PDT, Ojan Vafai
no flags
Patch (8.52 KB, patch)
2012-08-09 21:54 PDT, Tony Chang
no flags
Archive of layout-test-results from gce-cr-linux-06 (370.12 KB, application/zip)
2012-08-10 00:02 PDT, WebKit Review Bot
no flags
Patch for landing (9.22 KB, patch)
2012-08-10 00:42 PDT, Tony Chang
no flags
Ojan Vafai
Comment 1 2012-02-14 14:22:56 PST
Tony Chang
Comment 2 2012-02-14 14:40:16 PST
Comment on attachment 127043 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=127043&action=review > Source/WebCore/rendering/style/RenderStyle.h:1443 > + bool isDisplayInlineType(EDisplay display) const { return display == INLINE || isDisplayReplacedType(display); } Should the methods that take EDisplay be private?
Ojan Vafai
Comment 3 2012-02-14 17:07:21 PST
Dave Hyatt
Comment 4 2012-02-27 11:59:32 PST
Comment on attachment 127082 [details] Patch r=me
WebKit Review Bot
Comment 5 2012-02-27 12:33:44 PST
Comment on attachment 127082 [details] Patch Clearing flags on attachment: 127082 Committed r109014: <http://trac.webkit.org/changeset/109014>
WebKit Review Bot
Comment 6 2012-02-27 12:33:49 PST
All reviewed patches have been landed. Closing bug.
Ojan Vafai
Comment 7 2012-03-19 13:49:26 PDT
Rolled out due to causing crashes. Will commit later with fixes for the crashes.
Tony Chang
Comment 8 2012-08-07 00:25:41 PDT
I've started looking at this. For my own reference, the following bug has a test case with a crash. http://code.google.com/p/chromium/issues/detail?id=118662 I didn't get a crash in a release build and in debug, I'm hitting an assert. I'll see if the assert is related and try an ASAN build.
Tony Chang
Comment 9 2012-08-07 00:41:38 PDT
The debug assert seems real. I don't get it when I switch the test to use -webkit-inline-box. I'll investigate tomorrow.
Ojan Vafai
Comment 10 2012-08-07 11:48:00 PDT
Created attachment 156966 [details] crash reduction 1
Ojan Vafai
Comment 11 2012-08-07 11:48:18 PDT
Created attachment 156967 [details] crash reduction 2
Ojan Vafai
Comment 12 2012-08-07 11:54:45 PDT
I welcome a fresh set of eyes looking at this. Attached two reductions of the crash from crbug.com/118662. They get slightly different stacks. When I looked into this before, the issue was with the generated RenderInline container inside the block inside the flexbox. For deprecated flexboxes, the format block command looks for the next line-break and does the wrong thing, but doesn't seem to corrupt the tree. For new flexboxes, with the same rendertree (except for the flex container) it somehow corrupts the render tree. Here are some of my render tree dumps from the first crash reduction right before and in the middle of the formatBlock command. You can see that we end up with a different rendertree for the new flexboxes. I could never pinpoint why. FLEXBOX: RenderView 0x7fffeb723a98 #document 0x7ffff7efe600 RenderBlock 0x7ffff7ed2ef8 HTML 0x7fffeb718e00 RenderBody 0x7ffff7ed22b8 BODY 0x7fffeb718080 RenderBlock (anonymous) 0x7fffea446558 RenderText 0x7fffeab72d08 #text 0x7fffea44d2a0 "This test passes if it doesn't crash.\n\n" RenderBlock 0x7fffea446478 DIV 0x7fffeb718180 RenderInline 0x7fffea403378 A 0x7fffea4031b0 * RenderImage 0x7fffeb708558 IMG 0x7fffeb708000 RenderFlexibleBox 0x7fffea446c58 DIV 0x7fffe6f56780 STYLE=display: -webkit-inline-flexbox RenderBlock 0x7fffea446d38 PRE 0x7fffe6f56800 RenderInline (generated) 0x7fffea3f0528 RenderText 0x7fffea44a3d8 #text 0x7fffe6f66540 "AA؀" RenderText 0x7fffea44a338 #text 0x7fffe6f66540 "AA؀" RenderView 0x7fffeb723a98 #document 0x7ffff7efe600 RenderBlock 0x7ffff7ed2ef8 HTML 0x7fffeb718e00 RenderBody 0x7ffff7ed22b8 BODY 0x7fffeb718080 RenderBlock (anonymous) 0x7fffea446558 RenderText 0x7fffeab72d08 #text 0x7fffea44d2a0 "This test passes if it doesn't crash.\n\n" RenderBlock 0x7fffea446478 DIV 0x7fffeb718180 RenderBlock 0x7fffea446a98 H1 0x7fffeaaea600 RenderInline 0x7fffe6e0aa38 A 0x7fffe6e0aab0 RenderImage 0x7fffe6e01618 IMG 0x7fffe6e01540 RenderBlock (anonymous) 0x7fffea446b78 RenderInline 0x7fffea403378 A 0x7fffea4031b0 RenderFlexibleBox 0x7fffea446c58 DIV 0x7fffe6f56780 STYLE=display: -webkit-inline-flexbox RenderBlock 0x7fffea446d38 PRE 0x7fffe6f56800 * RenderText 0x7fffe6c872e8 #text 0x7fffe6f66ee0 "AA" RenderText 0x7fffea44a338 #text 0x7fffe6f66540 "؀" DEPRECATED: RenderView 0x7fffeb723a98 #document 0x7ffff7efe600 RenderBlock 0x7ffff7ed2ef8 HTML 0x7fffeb718e00 RenderBody 0x7ffff7ed22b8 BODY 0x7fffeb718700 RenderBlock (anonymous) 0x7ffff7ed2718 RenderText 0x7fffeab71c78 #text 0x7fffeb72cd20 "This test passes if it doesn't crash.\n\n" RenderBlock 0x7fffea3e6ef8 DIV 0x7fffeb718800 RenderInline 0x7fffea4032e8 A 0x7fffea403120 * RenderImage 0x7fffeb708318 IMG 0x7fffeb708180 RenderDeprecatedFlexibleBox 0x7fffea4641d8 DIV 0x7fffea46f580 STYLE=display: -webkit-inline-box RenderBlock 0x7fffea4642b8 PRE 0x7fffea46f600 RenderInline (generated) 0x7fffea465498 RenderText 0x7fffea4463d8 #text 0x7fffea46e150 "AA؀" RenderText 0x7fffea446338 #text 0x7fffea46e150 "AA؀" RenderView 0x7fffeb723a98 #document 0x7ffff7efe600 RenderBlock 0x7ffff7ed2ef8 HTML 0x7fffeb718e00 RenderBody 0x7ffff7ed22b8 BODY 0x7fffeb718700 RenderBlock (anonymous) 0x7ffff7ed2718 RenderText 0x7fffeab71c78 #text 0x7fffeb72cd20 "This test passes if it doesn't crash.\n\n" RenderBlock 0x7fffea3e6ef8 DIV 0x7fffeb718800 RenderBlock 0x7fffea464ef8 H1 0x7fffe740c000 RenderInline 0x7fffe723fd98 A 0x7fffe7248750 RenderImage 0x7fffea3f13d8 IMG 0x7fffea3f1300 RenderBlock (anonymous) 0x7fffea464018 RenderInline 0x7fffea4032e8 A 0x7fffea403120 RenderDeprecatedFlexibleBox 0x7fffea4641d8 DIV 0x7fffea46f580 STYLE=display: -webkit-inline-box RenderBlock 0x7fffea4642b8 PRE 0x7fffea46f600 RenderInline (generated) 0x7fffe7248ac8 RenderText 0x7fffe7256e78 #text 0x7fffea3f00e0 "AA" * RenderText 0x7fffea4463d8 #text 0x7fffea3f00e0 "AA" RenderText 0x7fffea446338 #text 0x7fffea46e150 "؀"
Tony Chang
Comment 13 2012-08-08 00:14:30 PDT
I'm still looking at this. Using crash2.html doesn't repro anymore, but crash1.html does. crash1.html hits the following: 0x00007ffff15af91a in WTF::StringImpl::operator[] (this=0x7fffe0c592d0, i=1) at ../../third_party/WebKit/Source/WTF/wtf/text/StringImpl.h:537 537 ASSERT(i < m_length); I'll look more tomorrow.
Tony Chang
Comment 14 2012-08-09 00:42:02 PDT
Using binary search, I've found that removing the call to child->setChildNeedsLayout(true) in RenderFlexibleBox::layoutAndPlaceChildren causes us to not crash, but fail lots of tests. I'm not sure why forcing a layout is causing us to crash. I'll look more tomorrow.
Tony Chang
Comment 15 2012-08-09 21:54:22 PDT
Build Bot
Comment 16 2012-08-09 22:31:19 PDT
Ojan Vafai
Comment 17 2012-08-09 23:54:20 PDT
Comment on attachment 157635 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157635&action=review Nice find! This might also be a significant perf improvement. > LayoutTests/css3/flexbox/inline-flex.html:1 > +<!DOCTYPE html> Nit: I'd prefer you just make this a regular check-layout.js test. You can use inline-blocks instead of text and assert the size/position of the inline flexbox. We should use reftests if we really have to test paint behavior or something like that. Up to you though. Not a big deal.
WebKit Review Bot
Comment 18 2012-08-10 00:02:31 PDT
Comment on attachment 157635 [details] Patch Attachment 157635 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13460839 New failing tests: http/tests/security/mixedContent/filesystem-url-in-iframe.html
WebKit Review Bot
Comment 19 2012-08-10 00:02:36 PDT
Created attachment 157648 [details] Archive of layout-test-results from gce-cr-linux-06 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: gce-cr-linux-06 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Tony Chang
Comment 20 2012-08-10 00:42:47 PDT
Created attachment 157656 [details] Patch for landing
WebKit Review Bot
Comment 21 2012-08-10 02:06:36 PDT
Comment on attachment 157656 [details] Patch for landing Clearing flags on attachment: 157656 Committed r125262: <http://trac.webkit.org/changeset/125262>
WebKit Review Bot
Comment 22 2012-08-10 02:06:41 PDT
All reviewed patches have been landed. Closing bug.
Zan Dobersek
Comment 23 2012-08-10 10:25:57 PDT
Comment on attachment 157656 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=157656&action=review > LayoutTests/css3/flexbox/inline-flex-crash2.html:8 > + layoutTestController.dumpAsText(); Is the use of window.layoutTestController instead of window.testRunner in some strange way intended? It's currently causing failures on non-Chromium ports (which, AFAIK, still exports window.layoutTestController).
Ojan Vafai
Comment 24 2012-08-10 10:28:36 PDT
Ryosuke, it appears we still expose layoutTestController from Chromium. :( (In reply to comment #23) > (From update of attachment 157656 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=157656&action=review > > > LayoutTests/css3/flexbox/inline-flex-crash2.html:8 > > + layoutTestController.dumpAsText(); > > Is the use of window.layoutTestController instead of window.testRunner in some strange way intended? It's currently causing failures on non-Chromium ports (which, AFAIK, still exports window.layoutTestController). Accidental.
Ryosuke Niwa
Comment 25 2012-08-10 10:50:14 PDT
(In reply to comment #24) > Ryosuke, it appears we still expose layoutTestController from Chromium. :( Yeah, we had to re-expose it until the security team makes the transition to use testRunner in various fuzzers they have :(
Xan Lopez
Comment 26 2012-08-10 11:12:04 PDT
This patch breaks my build: ../../Source/WebCore/rendering/style/RenderStyle.h:1743:79: error: ‘INLINE_FLEX’ was not declared in this scope I believe this is missing an #if ENABLE(CSS3_FLEXBOX) around the usage of INLINE_FLEX.
Ojan Vafai
Comment 27 2012-08-10 11:15:52 PDT
(In reply to comment #26) > This patch breaks my build: > > ../../Source/WebCore/rendering/style/RenderStyle.h:1743:79: error: ‘INLINE_FLEX’ was not declared in this scope > > I believe this is missing an #if ENABLE(CSS3_FLEXBOX) around the usage of INLINE_FLEX. We should remove the defines for flexbox. We had put them in because all the names were changing and we didn't want people to ship with the old names. At this point the spec is definitely stable and our implementation is as well. It should just be small bug fixes and cross-browser interoperability testing at this point.
Ojan Vafai
Comment 28 2012-08-10 11:16:18 PDT
(In reply to comment #27) > (In reply to comment #26) > > This patch breaks my build: > > > > ../../Source/WebCore/rendering/style/RenderStyle.h:1743:79: error: ‘INLINE_FLEX’ was not declared in this scope > > > > I believe this is missing an #if ENABLE(CSS3_FLEXBOX) around the usage of INLINE_FLEX. > > We should remove the defines for flexbox. We had put them in because all the names were changing and we didn't want people to ship with the old names. At this point the spec is definitely stable and our implementation is as well. It should just be small bug fixes and cross-browser interoperability testing at this point. In the meantime, I'll add in the #if to fix the build.
Ojan Vafai
Comment 29 2012-08-10 11:21:33 PDT
Note You need to log in before you can comment on or make changes to this bug.