New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Fixed
Merged: issue 708159
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

[css-grid] When inputting to the textarea element which is a grid item, a layout collapses

Reported by yuhei.ya...@gmail.com, May 28 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce the problem:
1. Make a textarea element a grid item https://yuheiy.github.io/pub/textarea-in-grid.html
2. Input something to a textarea element

What is the expected behavior?

What went wrong?
A layout collapses

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 58.0.3029.110  Channel: stable
OS Version: OS X 10.12.5
Flash Version:
 
スクリーンショット 2017-05-28 13.43.42.png
11.0 KB View Download
Status: Available (was: Unconfirmed)

Comment 2 by phistuck@gmail.com, May 29 2017

Note - this does not reproduce on Windows.

Comment 3 by nainar@chromium.org, May 31 2017

Labels: Update-Quarterly

Comment 4 by r...@opera.com, May 31 2017

Cc: jfernan...@igalia.com r...@igalia.com
Components: -Blink>CSS Blink>Layout
Not able to reproduce on Linux either. Guessing this is Blink>Layout, though.

Comment 5 by r...@igalia.com, May 31 2017

Cc: svil...@igalia.com
Components: -Blink>Layout Blink>Layout>Grid
Mergedinto: 708159
Status: Duplicate (was: Available)
This seems pretty similar to #708159. It should be fixed in M59.

@yuhei.yasuda1003 could you check if you can reproduce it in Chrome 59 (or in Canary)? Thanks.
I reproduced on Chrome 58 and Canary 61.

Comment 7 by svil...@igalia.com, May 31 2017

It's a duplicate. I've just tried it on the master branch and it's working fine.

Comment 8 by r...@igalia.com, May 31 2017

Status: Available (was: Duplicate)
Yep sorry, I've just checked and I can reproduce on the last Canary (61.0.3115.0) in Mac.

I cannot reproduce in Linux though... :-(

Comment 9 by r...@igalia.com, May 31 2017

Summary: [css-grid] When inputting to the textarea element which is a grid item, a layout collapses (was: When inputting to the textarea element which is a grid item, a layout collapses)
BTW, it happens the same with an <input>.

Comment 10 by svil...@igalia.com, May 31 2017

yuhei.yasuda1003@gmail.com which OS are you using? Windows, Mac, Linux...?

Comment 11 by r...@igalia.com, May 31 2017

@svillar this is reproducible in master (r475889) in Mac very easily for both the <input> and <textarea>.
Actually for the <input> I just need to type one char and it already happens, for the area I need to type 2.

Comment 12 by r...@igalia.com, Jun 1 2017

After some tries I have a test that fails on Mac.
I'm attaching it, you have just to place it under "LayoutTests/fast/css-grid-layout/".
preferred-width-computed-after-layout-new.html
679 bytes View Download

Comment 13 by r...@igalia.com, Jun 1 2017

I've been taking a look and the issue seems similar to the one we have already investigated before.

As we know Mac can call ComputeIntrinsicLogicalWidths() after layout,
and that's causing that the item's overrides are reset and we lost the width of the <input>.

In a simple example with an <input> as grid item,
after LayoutGrid::UpdateBlockLayout() is called the following things happen:
1) We focus the <input> and LayoutGrid::ComputeIntrinsicLogicalWidths() is called.
   The size is still the right one.
   The overrides are already wrong, but probably a new relayout of the <input> isn't triggered yet.
2) Then we type a single character and LayoutGrid::ComputeIntrinsicLogicalWidths() is called again.
   At this point the size of the <input> goes nuts.

Comment 14 by r...@igalia.com, Jun 1 2017


And some more info, the method that is calling SetPreferredLogicalWidthsDirty() on LayoutGrid
is LayoutObject::InvalidateContainerPreferredLogicalWidths().

The layout tree is something like this:
    LayoutView 0x3e127d004010              	#document
      LayoutBlockFlow 0x3e127d018010       	HTML
        LayoutBlockFlow 0x3e127d018138     	BODY
          LayoutGrid 0x3e127d024010        	DIV style="display: grid;"
            LayoutTextControl 0x3e127d030010	INPUT
              LayoutBlockFlow 0x3e127d018260	DIV id="placeholder" style="display: block !important; text-overflow: clip;"
                LayoutText 0x3e127d040010  	#text "Type something here"
              LayoutBlockFlow 0x3e127d018388	DIV id="inner-editor" (editable)

LayoutObject::InvalidateContainerPreferredLogicalWidths() is called for #DIV id="placeholder"#
and the loop makes it keeps calling SetPreferredLogicalWidthsDirty() for their containers,
in this case the #INPUT# and then the grid container #DIV style="display: grid;"#.
This happens in Linux and Mac, so it's not platform specific.
So after we edit the input the grid container has been marked with SetPreferredLogicalWidthsDirty().

At this point, in Mac (and only in Mac) we get some calls to LayoutGrid::ComputeIntrinsicLogicalWidths(),
and the grid container is not marked for layout.
And that's what breaks things.

Status: Assigned (was: Available)
I'm taking a look
Here's a video of it happening for me in a grid layout in Chromium Version 60.0.3112.113:
https://youtu.be/8-OmQUv5S9c

Comment 17 Deleted

Comment 18 Deleted

Hacky Workaround in in Chromium Version 60.0.3112.113: 

In order to prevent this bug from manifesting on the (100% width) inputs in my grid, I had to add a 'focus' eventListener to each and every input containing the following re-render hack:

inputElement.style.opacity = ".99";
setTimeout(()=>{inputElement.style.opacity = "1";},1000);

Without this, the behavior was like this: https://youtu.be/8-OmQUv5S9c

Please make sure this bug is open and marked as "not fixed".

This is still happening on Chrome 61 Stable
https://github.com/rachelandrew/cssgrid-ama/issues/107?

Any clean non javascript workarounds? ei, ones that prevent 
LayoutGrid::ComputeIntrinsicLogicalWidths() from triggering.

This issue makes websites unusable... and has priority should be higher
weird input field.gif
386 KB View Download
 Issue 766764  has been merged into this issue.

Comment 22 by r...@igalia.com, Sep 20 2017

Cc: keerthan...@techmahindra.com
 Issue 766742  has been merged into this issue.
Owner: jfernan...@igalia.com
I'm working on this now.
This is the backtrace that led to the preferred widths computation, which eventually clear our internal data structures to deal with the grid area abstraction (overrideContianingBlockWidth)


#0  0x00007f20c15c6dab in blink::LayoutGrid::ComputeIntrinsicLogicalWidths(blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa30010, min_logical_width=..., max_logical_width=...)
    at ../../third_party/WebKit/Source/core/layout/LayoutGrid.cpp:521
#1  0x00007f20c14e8ff5 in blink::LayoutBlock::ComputePreferredLogicalWidths() (this=0xa39afa30010) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1390
#2  0x00007f20c154c738 in blink::LayoutBox::MinPreferredLogicalWidth() const (this=0xa39afa30010) at ../../third_party/WebKit/Source/core/layout/LayoutBox.cpp:1348
#3  0x00007f20c14e9735 in blink::LayoutBlock::ComputeChildPreferredLogicalWidths(blink::LayoutObject&, blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa24130, 
    child=..., min_preferred_logical_width=..., max_preferred_logical_width=...) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1571
#4  0x00007f20c14e84b2 in blink::LayoutBlock::ComputeBlockPreferredLogicalWidths(blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa24130, min_logical_width=..., max_logical_width=...)
    at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1491
#5  0x00007f20c14e7cd3 in blink::LayoutBlock::ComputeIntrinsicLogicalWidths(blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa24130, min_logical_width=..., max_logical_width=...)
    at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1350
#6  0x00007f20c14e8ff5 in blink::LayoutBlock::ComputePreferredLogicalWidths() (this=0xa39afa24130) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1390
#7  0x00007f20c154c738 in blink::LayoutBox::MinPreferredLogicalWidth() const (this=0xa39afa24130) at ../../third_party/WebKit/Source/core/layout/LayoutBox.cpp:1348
#8  0x00007f20c14e9735 in blink::LayoutBlock::ComputeChildPreferredLogicalWidths(blink::LayoutObject&, blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa24010, child=..., min_preferred_logical_width=..., max_preferred_logical_width=...) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1571
#9  0x00007f20c14e84b2 in blink::LayoutBlock::ComputeBlockPreferredLogicalWidths(blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa24010, min_logical_width=..., max_logical_width=...)
    at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1491
#10 0x00007f20c14e7cd3 in blink::LayoutBlock::ComputeIntrinsicLogicalWidths(blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa24010, min_logical_width=..., max_logical_width=...)
    at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1350
#11 0x00007f20c14e8ff5 in blink::LayoutBlock::ComputePreferredLogicalWidths() (this=0xa39afa24010) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1390
#12 0x00007f20c154c738 in blink::LayoutBox::MinPreferredLogicalWidth() const (this=0xa39afa24010) at ../../third_party/WebKit/Source/core/layout/LayoutBox.cpp:1348
#13 0x00007f20c14e9735 in blink::LayoutBlock::ComputeChildPreferredLogicalWidths(blink::LayoutObject&, blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa04010, child=..., min_preferred_logical_width=..., max_preferred_logical_width=...) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1571
#14 0x00007f20c14e84b2 in blink::LayoutBlock::ComputeBlockPreferredLogicalWidths(blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa04010, min_logical_width=..., max_logical_width=...)
    at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1491
#15 0x00007f20c14e7cd3 in blink::LayoutBlock::ComputeIntrinsicLogicalWidths(blink::LayoutUnit&, blink::LayoutUnit&) const (this=0xa39afa04010, min_logical_width=..., max_logical_width=...)
    at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1350
#16 0x00007f20c14e8ff5 in blink::LayoutBlock::ComputePreferredLogicalWidths() (this=0xa39afa04010) at ../../third_party/WebKit/Source/core/layout/LayoutBlock.cpp:1390
#17 0x00007f20c154c738 in blink::LayoutBox::MinPreferredLogicalWidth() const (this=0xa39afa04010) at ../../third_party/WebKit/Source/core/layout/LayoutBox.cpp:1348
#18 0x00007f20c0c23499 in blink::LayoutBoxItem::MinPreferredLogicalWidth() const (this=0x7ffcc3d1d988) at ../../third_party/WebKit/Source/core/layout/api/LayoutBoxItem.h:47
#19 0x00007f20c0c1c2c2 in blink::WebViewImpl::ContentsPreferredMinimumSize() (this=0x3824ae6c4010) at ../../third_party/WebKit/Source/core/exported/WebViewImpl.cpp:3077
#20 0x00007f20cf8cabb6 in content::RenderViewImpl::CheckPreferredSize() (this=0x1db47a98a720) at ../../content/renderer/render_view_impl.cc:1844
#21 0x00007f20cf8dcf4d in base::internal::FunctorTraits<void (content::RenderViewImpl::*)(), void>::Invoke<content::RenderViewImpl*>(void (content::RenderViewImpl::*)(), content::RenderViewImpl*&&) (method=(void (content::RenderViewImpl::*)(content::RenderViewImpl * const)) 0x7f20cf8cab60 <content::RenderViewImpl::CheckPreferredSize()>, receiver_ptr=<unknown type in /home/javi/devel/Chromium/src/out/Debug/./libcontent.so, CU 0xe134b35, DIE 0xe1d5728>) at ../../base/bind_internal.h:194
#22 0x00007f20cf8dce94 in base::internal::InvokeHelper<false, void>::MakeItSo<void (content::RenderViewImpl::* const&)(), content::RenderViewImpl*>(void (content::RenderViewImpl::* const&)(), content::RenderViewImpl*&&) (functor=@0x1db47a56a350: (void (content::RenderViewImpl::*)(content::RenderViewImpl * const)) 0x7f20cf8cab60 <content::RenderViewImpl::CheckPreferredSize()>, args=<unknown type in /home/javi/devel/Chromium/src/out/Debug/./libcontent.so, CU 0xe134b35, DIE 0xe1d56a1>) at ../../base/bind_internal.h:277
#23 0x00007f20cf8dce45 in base::internal::Invoker<base::internal::BindState<void (content::RenderViewImpl::*)(), base::internal::UnretainedWrapper<content::RenderViewImpl> >, void ()>::RunImpl<void (content::RenderViewImpl::* const&)(), std::__1::tuple<base::internal::UnretainedWrapper<content::RenderViewImpl> > const&, 0ul>(void (content::RenderViewImpl::* const&)(), std::__1::tuple<base::internal::UnretainedWrapper<content::RenderViewImpl> > const&, std::__1::integer_sequence<unsigned long, 0ul>) (functor=@0x1db47a56a350: (void (content::RenderViewImpl::*)(content::RenderViewImpl * const)) 0x7f20cf8cab60 <content::RenderViewImpl::CheckPreferredSize()>, bound=...) at ../../base/bind_internal.h:349
#24 0x00007f20cf8dcd8c in base::internal::Invoker<base::internal::BindState<void (content::RenderViewImpl::*)(), base::internal::UnretainedWrapper<content::RenderViewImpl> >, void ()>::Run(base::internal::BindStateBase*) (base=0x1db47a56a330) at ../../base/bind_internal.h:331
#25 0x00007f20d5527a4d in base::RepeatingCallback<void ()>::Run() const & (this=0x7ffcc3d1dba8) at ../../base/callback.h:92

I think I've found out the root cause of this issue and I've got a promising fix already, https://crrev.com/c/702437 
Project Member

Comment 26 by bugdroid1@chromium.org, 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

Status: Fixed (was: Assigned)
This issue should be FIXED now. 

Comment 28 by r...@igalia.com, Dec 19 2017

 Issue 796328  has been merged into this issue.

Comment 29 by r...@igalia.com, Jan 15 2018

 Issue 801781  has been merged into this issue.

Sign in to add a comment