CHECK failure: root_.GetDocument().View()->IsInPerformLayout() in SubtreeLayoutScope.cpp |
|||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5146733477888000 Fuzzer: ifratric-browserfuzzer-v3 Job Type: mac_asan_chrome Platform Id: mac Crash Type: CHECK failure Crash Address: Crash State: root_.GetDocument().View()->IsInPerformLayout() in SubtreeLayoutScope.cpp blink::SubtreeLayoutScope::SubtreeLayoutScope blink::LayoutFlexibleBox::UpdateBlockLayout Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=480563:480597 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5146733477888000 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Oct 12 2017
I still can't reproduce this, since I'm, on Linux, but I think I understand what's going on. We're calculating preferred min/max widths all the way from the root, and all of a sudden, the grid code starts laying out. I think I should be able to write a unit test that causes the CHECK failure, even on Linux.
,
Oct 12 2017
Yes, I can reproduce it with this, when adding it to Source/core/exported/WebViewTest.cpp:
TEST_P(WebViewTest, PreferredSizeWithGrid) {
// This is mainly to check that it doesn't crash.
WebViewImpl* web_view = web_view_helper_.Initialize();
WebURL base_url = URLTestHelpers::ToKURL("http://example.com/");
FrameTestHelpers::LoadHTMLString(web_view->MainFrameImpl(),
R"HTML(<!DOCTYPE html>
<style>
html { writing-mode: vertical-rl; }
html, body, div { width: 5%; }
</style>
<div style="display: inline-grid;">
<select></select>
</div>
)HTML",
base_url);
web_view->ContentsPreferredMinimumSize();
}
,
Oct 17 2017
Slightly simplified/different test:
TEST_P(WebViewTest, PreferredSizeWithGrid) {
WebViewImpl* web_view = web_view_helper_.Initialize();
WebURL base_url = URLTestHelpers::ToKURL("http://example.com/");
FrameTestHelpers::LoadHTMLString(web_view->MainFrameImpl(),
R"HTML(<!DOCTYPE html>
<style>
html { writing-mode:vertical-rl; }
</style>
<div style="width:100px;">
<div style="display:grid; width:100%;">
<select></select>
</div>
</div>
)HTML",
base_url);
// FIXME: While the main purpose of this test is to make sure that it doesn't
// crash, it would be nice to check the result from
// ContentsPreferredMinimumSize() as well.
web_view->ContentsPreferredMinimumSize();
}
It would be nice to replace the SELECT element with something more generic, and also get rid of percentage logical height and writing mode, but I haven't managed to do that.
In any case, performing layout to calculate the preferred logical width is risky business (for one, we have incomplete or no LayoutState). Grid does this. Maybe the problem is that nothing should be marked for layout when calculating the preferred logical widths here.
,
Oct 17 2017
,
Oct 17 2017
I still need to look into the details of the issue, but I think it's pretty related to issue #727076 and #708159 It seems that Chrome is under "preferred size mode" when it runs under Mac platform. This implies async calls from the WebContent process to the Render process to request the preferred size. Since this is an async call, it may happen that preferred width is dirty at that time, so it triggers the intrinsic size computation logic. In some cases, like it happens with grid layout, we need to laid out the grid items to properly compute the grid's intrinsic size. My theory is that this is the root cause of this issue. BTW, all these issues can be easily reproducible in linux by enabling the preferred size mode, just adding the following lines: diff --git a/content/browser/web_contents/web_contents_view_aura.cc b/content/browser/web_contents/web_contents_view_aura.cc index 4742a43..4c19cf8 100644 --- a/content/browser/web_contents/web_contents_view_aura.cc +++ b/content/browser/web_contents/web_contents_view_aura.cc @@ -881,6 +881,7 @@ void WebContentsViewAura::SetPageTitle(const base::string16& title) { } void WebContentsViewAura::RenderViewCreated(RenderViewHost* host) { + host->EnablePreferredSizeMode(); }
,
Oct 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4d12111d13eab4eaf1ea56c594aa3223e9092b19 commit 4d12111d13eab4eaf1ea56c594aa3223e9092b19 Author: Javier Fernandez <jfernandez@igalia.com> Date: Wed Oct 25 14:38:19 2017 [css-grid] Avoid clearing the overrideContainingBlockWidth if possible Since the intrinsic width computation uses the same logic than the track sizing algorithm we are clearing the overrideContainingBlockWidth of some grid items that are required to laid out them properly. It's very uncommon that any intrinsic size computation isn't performed as part of a layout process. However, in the Mac platform we enable the PreferredSizeMode so that the WebContent process launches messages to the render process asking for the current preferred size. Additionally, in some cases like the one described in the bug this patch tries to solve, a style change causes a preferred width invalidation. This implies that any request for the preferred width will trigger the preferred size computation logic. The problem is that, as mentioned before, this happens out of any layout process. Finally, even though preferred size invalidation implies that the affected box is marked as needing layout with the kMarkContainerChain enabled, this is not happening for the case described in the bug. The Grid container is not marked for layout because the Grid Item is an 'input' element, rendered by a LayoutTextControl which happens to be an ObjectRelayoutBoundary. One possible alternative approach for this issue would be to exclude grid items as possible ObjectRelayoutBoundary, like it happens with Flexible Box items or TableParts. However, I think it's better to avoid as much as possible to clear the overrideContainingBlockWidth to reduce the friction between the intrinsic size computation and the layout logics. Bug: 727076 , 773988 Change-Id: Ibe4c927f5101b7ceced433084ea81aa2cafdc4a2 Reviewed-on: https://chromium-review.googlesource.com/702437 Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Reviewed-by: Manuel Rego Casasnovas <rego@igalia.com> Reviewed-by: Sergio Villar <svillar@igalia.com> Cr-Commit-Position: refs/heads/master@{#511451} [modify] https://crrev.com/4d12111d13eab4eaf1ea56c594aa3223e9092b19/third_party/WebKit/LayoutTests/fast/css-grid-layout/preferred-width-computed-after-layout.html [modify] https://crrev.com/4d12111d13eab4eaf1ea56c594aa3223e9092b19/third_party/WebKit/Source/core/exported/WebViewTest.cpp [modify] https://crrev.com/4d12111d13eab4eaf1ea56c594aa3223e9092b19/third_party/WebKit/Source/core/layout/GridTrackSizingAlgorithm.cpp [modify] https://crrev.com/4d12111d13eab4eaf1ea56c594aa3223e9092b19/third_party/WebKit/Source/core/layout/GridTrackSizingAlgorithm.h [modify] https://crrev.com/4d12111d13eab4eaf1ea56c594aa3223e9092b19/third_party/WebKit/Source/core/layout/LayoutGrid.cpp
,
Oct 25 2017
This issue should be FIXED now.
,
Oct 26 2017
ClusterFuzz has detected this issue as fixed in range 511436:511477. Detailed report: https://clusterfuzz.com/testcase?key=5146733477888000 Fuzzer: ifratric-browserfuzzer-v3 Job Type: mac_asan_chrome Platform Id: mac Crash Type: CHECK failure Crash Address: Crash State: root_.GetDocument().View()->IsInPerformLayout() in SubtreeLayoutScope.cpp blink::SubtreeLayoutScope::SubtreeLayoutScope blink::LayoutFlexibleBox::UpdateBlockLayout Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=480563:480597 Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=511436:511477 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5146733477888000 See https://github.com/google/clusterfuzz-tools for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
Oct 26 2017
ClusterFuzz testcase 5146733477888000 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pnangunoori@chromium.org
, Oct 12 2017Components: Blink>Layout
Labels: M-62 Test-Predator-Wrong
Owner: msten...@opera.com
Status: Assigned (was: Untriaged)