Note - this does not reproduce on Windows.

Not able to reproduce on Linux either. Guessing this is Blink>Layout, though.

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.

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

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... :-(

BTW, it happens the same with an <input>.

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

@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.

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/".

Deleted: preferred-width-computed-after-layout-new.html 679 bytes

preferred-width-computed-after-layout-new.html 679 bytes View Download

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.

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.

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

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

Deleted: weird input field.gif 386 KB

	weird input field.gif 386 KB View Download

 Issue 766764  has been merged into this issue.

 Issue 766742  has been merged into this issue.

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 

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

This issue should be FIXED now. 

 Issue 796328  has been merged into this issue.

 Issue 801781  has been merged into this issue.