|Summary:||REGRESSION (r167845): ASSERT(!m_renderView.needsLayout()) in svg/custom/bug79798.html|
|Product:||WebKit||Reporter:||Tim Horton <thorton>|
|Component:||Tools / Tests||Assignee:||Andy Estes <aestes>|
|Severity:||Normal||CC:||aestes, ap, commit-queue, darin, dbates, fred.wang, msaboff, rniwa, ryanhaddad, simon.fraser, tonikitoo|
|Version:||528+ (Nightly build)|
Description Tim Horton 2014-04-28 12:51:45 PDT
The following layout test is failing on all Mac WebKit2 bots: svg/custom/bug79798.html Probable cause: http://trac.webkit.org/changeset/167845 causes us to finish layout with dirty layout, somehow. It seems to involve doing a subtree layout of a subframe (the <object>?) but having dirtied layout on the main frame (during deletion-within-selection), or some such (haven't debugged extensively). No idea why it would only happen in WebKit2.
Comment 1 Tim Horton 2014-04-28 12:52:56 PDT
I'm tempted to skip the test instead of rolling out because the user facing
Comment 2 Tim Horton 2014-04-28 12:53:38 PDT
(In reply to comment #1) > I'm tempted to skip the test instead of rolling out because the user facing impact of the original bug is so much worse, but we've done so much work to flush out all of the ASSERT(!needsLayout) issues that it would be sad to reintroduce one.
Comment 3 Tim Horton 2014-04-28 12:57:57 PDT
http://trac.webkit.org/changeset/167898 skips it for WebKit2 (still no idea why it is specific to those bots, but at least this means the test is still covered somewhere)
Comment 5 Daniel Bates 2017-05-08 18:20:59 PDT
I just hit this assertion failure in RenderLayerCompositor::requiresCompositingForScrollableFrame() using a debug build of WebKit r216439 on <https://www.icloud.com> by performing the following: 1. Visit <https://www.icloud.com>. 2. Type 'a' in the password field. 3. Press the delete key on the keyboard. Then the WebProcess crashes because of the assertion failure.
Comment 6 Daniel Bates 2017-05-08 18:21:48 PDT
Created attachment 309454 [details] Stacktrace Stacktrace after following the reproduction steps in comment #5.
Comment 7 Simon Fraser (smfr) 2017-05-08 18:53:24 PDT
I think Andy was going to fix this (or did recently).
Comment 9 Alexey Proskuryakov 2017-05-10 15:53:29 PDT
Comment on attachment 309641 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=309641&action=review > LayoutTests/platform/wk2/TestExpectations:-196 > -webkit.org/b/132297 svg/custom/bug79798.html [ Skip ] There is one more expectation for this: LayoutTests/platform/ios-wk2/TestExpectations:272:webkit.org/b/132297 [ Debug ] svg/custom/bug79798.html [ Skip ] LayoutTests/platform/wk2/TestExpectations:196:webkit.org/b/132297 svg/custom/bug79798.html [ Skip ]
Comment 11 Andy Estes 2017-05-10 16:02:06 PDT
(In reply to Alexey Proskuryakov from comment #9) > Comment on attachment 309641 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=309641&action=review > > > LayoutTests/platform/wk2/TestExpectations:-196 > > -webkit.org/b/132297 svg/custom/bug79798.html [ Skip ] > > There is one more expectation for this: > > LayoutTests/platform/ios-wk2/TestExpectations:272:webkit.org/b/132297 [ > Debug ] svg/custom/bug79798.html [ Skip ] If iOS was hitting this assertion, then this patch probably won't fix it, since iOS sets ScrollableInnerFrameTrigger. Let's see what EWS says.
Comment 12 WebKit Commit Bot 2017-05-10 17:33:36 PDT
Comment on attachment 309652 [details] Patch Clearing flags on attachment: 309652 Committed r216643: <http://trac.webkit.org/changeset/216643>
Comment 13 WebKit Commit Bot 2017-05-10 17:33:38 PDT
All reviewed patches have been landed. Closing bug.