|Summary:||Call FrameView::scheduleSelectionUpdate when selection needs repainting after layout instead of setting the RenderView dirty.|
|Component:||Layout and Rendering||Assignee:||zalan <zalan>|
|Severity:||Normal||CC:||bfulgham, commit-queue, darin, dbates, koivisto, simon.fraser, webkit-bug-importer, zalan|
|Version:||WebKit Nightly Build|
Description zalan 2017-10-22 19:43:59 PDT
In https://trac.webkit.org/r167845 (bug 132172), the renderView->setNeedsLayout() call was introduced to trigger selection update. However this is problematic in a couple of different ways. 1. marking the root renderer dirty does not trigger layout (this is very specific to the root, other renderers do trigger layout) -so this works as long as someone else schedules a layout. 2. when a subtree layout is already scheduled and we mark the root renderer dirty, the root gets stuck with the dirty flag (since the entry point for the subsequent layout is a descendant of the root and not the root itself). -this got revealed with bug 178621.
Comment 3 WebKit Commit Bot 2017-10-23 08:57:55 PDT
Comment on attachment 324539 [details] Patch Clearing flags on attachment: 324539 Committed r223835: <https://trac.webkit.org/changeset/223835>
Comment 4 WebKit Commit Bot 2017-10-23 08:57:56 PDT
All reviewed patches have been landed. Closing bug.
Comment 5 Simon Fraser (smfr) 2017-10-23 10:13:10 PDT
Comment on attachment 324539 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=324539&action=review > Source/WebCore/page/FrameView.cpp:3192 > + // However we can't tell at this point if the tree is stable yet, so let's just schedule a root only layout for now. "root only" sounds weird.