Unable to reproduce the issue on Win-10 using chrome reported version #69.0.3463.0 and latest canary #69.0.3466.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to url: https://codesandbox.io/s/7ky8ovrrm1.
2. Resized the window.
3. Observed that background color displayed fine when resizing the window as expected.

banoushirosaki@ - Could you please check this issue on latest canary #69.0.3466.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Also please help us by providing a screen cast if possible for better understanding of the issue.

Thanks...!!

Deleted: 854783.mp4 3.7 MB

	854783.mp4 3.7 MB View Download

You have to resize the result element of codesandbox, but it'd do the same with the window resize if you used columns on a website instead of a sandbox,
in my video you can see the background color of the items on the first column stops at a certain width, while the text still moves

Deleted: 2018-06-21_21-40-59.mp4 460 KB

	2018-06-21_21-40-59.mp4 460 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce. Do you have any experimental features turned on?

The bug happen on both normal and canary, i'm not using any experimental features.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Any idea what might be going on here mstensho?

I can reproduce this (Mac). Attaching non-interactive test.

Some sort of invalidation issue.

Deleted: tc.html 459 bytes

tc.html 459 bytes View Download

I'd like some input from the paint team (before I spend too much time on my own in code I'm unfamiliar with). I observe that the box is repainted, but we seem to be stuck with and old clip rectangle or something. Maybe it's the flow thread (anonymous parent of the two DIVs) that doesn't get properly updated, but I don't know where to look.

I think the direct reason is the incorrect FragmentClip of the first fragment. The following is part of the dump of paint record with paint logging (--vmodule=*/paint/*=3,*/graphics/*=3):

            {
              "method": "clipRect",
              "params": {
                "rect": {
                  "left": -999992,
                  "top": -999950,
                  "right": 58,   <--- Should be 258
                  "bottom": 550
                },
                "SkRegion::Op": "kIntersect_Op",
                "softClipEdgeStyle": true
              }
            },
            {
              "method": "drawRect",
              "params": {
                "rect": {
                  "left": 8,
                  "top": 50,
                  "right": 258,
                  "bottom": 550
                },
                "paint": {
                  "textSize": 12,
                  "textScaleX": 1,
                  "textSkewX": 0,
                  "color": "#FF0000FF",
                  ....
                }
              }
            },
            {
              "method": "restore"
            },

The clip tree is:
 Clip tree:
root 0x1319ffc44e10 {"localTransformSpace":"0x1319ffca8650","rect":"InfiniteIntRect"}
  OverflowClip (LayoutView #document) 0x1319ffc44f10 {"parent":"0x1319ffc44e10","localTransformSpace":"0x1319ffca8b50","rect":"0,0 800x600","rectExcludingOverlayScrollbars":"0,0 800x600"}
    FragmentClip (LayoutMultiColumnFlowThread (anonymous)) 0x1319ffc45010 {"parent":"0x1319ffc44f10","localTransformSpace":"0x1319ffca8b50","rect":"-999992,-999950 1.00005e+06x1.0005e+06"}
    FragmentClip (LayoutMultiColumnFlowThread (anonymous)) 0x1319ffc45110 {"parent":"0x1319ffc44f10","changed":true,"localTransformSpace":"0x1319ffca8b50","rect":"258,50 1e+06x999500"}

Still trying to find out the reason of the incorrect FragmentClip.

I added SetSubtreeNeedsPaintPropertyUpdate() in LocalFrameView::PrePaint() before PrePaintTreeWalk().WalkTree(), and the bug disappeared. So the bug should be an under-invalidation of paint properties of the LayoutMultiColumnFlowThread when something that will affect FragmentClip changes (when we should call SetNeedsPaintPropertyUpdate).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0e3be792c60251e6d90a6995b9f66460f61ea0ce

commit 0e3be792c60251e6d90a6995b9f66460f61ea0ce
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Tue Jul 03 21:48:11 2018

[PE] Detect fragment clip change

Bug:  854783 
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I7ae7d241596f8eedce26ff43b2ee9ff584b911ff
Reviewed-on: https://chromium-review.googlesource.com/1123108
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#572365}
[modify] https://crrev.com/0e3be792c60251e6d90a6995b9f66460f61ea0ce/third_party/blink/renderer/core/paint/paint_property_tree_builder.cc
[modify] https://crrev.com/0e3be792c60251e6d90a6995b9f66460f61ea0ce/third_party/blink/renderer/core/paint/paint_property_tree_builder_test.cc
[modify] https://crrev.com/0e3be792c60251e6d90a6995b9f66460f61ea0ce/third_party/blink/renderer/core/paint/paint_property_tree_builder_test.h
[modify] https://crrev.com/0e3be792c60251e6d90a6995b9f66460f61ea0ce/third_party/blink/renderer/core/paint/paint_property_tree_update_tests.cc

The NextAction date has arrived: 2018-07-10