Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 700383 [css-grid] Grid layouts go mostly blank
Starred by 8 users Reported by e...@aneventapart.com, Mar 10 Back to list
Status: Fixed
Owner:
Closed: Mar 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Compat



Sign in to add a comment
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:55.0) Gecko/20100101 Firefox/55.0

Example URL:
http://meyerweb.com/

Steps to reproduce the problem:
1. Go to meyerweb.com in Chrome 57.
2. Watch the page lay out, then go almost entirely blank.
3. But not quite—there’s some generated content that gets rendered in the first post.  I can't drag-select it, but I don't know if that's due to this bug or for entirely different reasons.
4. If you resize the window, the page will be fully rendered as long as reflow has to happen.  Stop the resizing, whether by letting go of the drag handle or just not moving it, and after a second or so the page blanks again.

What is the expected behavior?
The page would not be mostly blank.

What went wrong?
Some sort of interaction with Grid and maybe my graphics card, at a first wild guess.  When I dealt with a similar problem in an earlier build, some people with the same OS as me didn't experience the problem, whereas others with different setups did experience it. (See https://twitter.com/meyerweb/status/828042499633590272 and the replies to it.)

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 57.0.2987.98 (64-bit)  Channel: stable
OS Version: OS X 10.11
Flash Version: Shockwave Flash 24.0 r0

Note that the entire page is laid out with Grid, so only a part of the Grid layout is being blanked.  It appears to be two of the grid items are blanked out.  I can inspect element, and doing so often causes the page to be re-rendered at first.  If often stays stable until I resize or scroll the page, at which point it re-blanks.

This problem DOES NOT occur in Canary 59.0.3037.0 (Official Build) canary (64-bit) on the same machine.  I searched both the open and closed issues for a bug describing this, but came up empty.

Also, sometimes the page un-blanks itself and seems fine thereafter.  I haven't been able to figure out a reproducible way of making this happen, however.

 
Sorry, a followup: many other mages on meyerweb.com have lesser versions of the same problem in Chrome 57.  Example: http://meyerweb.com/eric/css/ .  That whole page doesn't blank, but the title ("CSS Work") sometimes does if you hover the mouse over it.  Double-clicking on the page anywhere inside the main content area, or in the footer, causes both to go blank.  It's also often (maybe always) the case that the part of the page not visible on page load is blank by default, even though it's occupying space and can be inspected.
Er, many other other PAGES on meyerweb.  Not mages.  I have no wizards on the site (that I know of).
Cc: svil...@igalia.com jfernan...@igalia.com r...@igalia.com
Components: Blink>Layout>Grid
Summary: [css-grid] Grid layouts go mostly blank (was: Grid layouts go mostly blank)
Hi Eric, thanks for the report! Really strange issues.

Sorry but I cannot reproduce any of those issues either in Chrome 57 or 59 on Mac. Neither in Linux.

If someone is able to reproduce them and has the time to bisect, they could use the "bisect-builds.py" script:
https://www.chromium.org/developers/bisect-builds-py
That should provide a small range of commits to try to find what's going on.

Labels: Needs-Bisect Needs-TestConfirmation
I see this as well on the pages mentioned, or rather nearly the same issue - top part of page renders for me, but then it stops before the screen is filled. If I scroll down I see an entire page's worth of blankness and if I scroll all the way down and then scroll back up, the content that had been rendered is now blank as well. At one point, I did manage to see the rest of the page's content, but can't quite figure out what I did to manage that.

Page displays fine in the latest version of Firefox for me.

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

And in case it is a graphics card issue, running a MacBook Pro (Retina, 15-inch, Late 2013) with a NVIDIA GeForce GT 750M 2048 MB card.
Comment 7 Deleted
I’m also on a MacBook Pro, 15", but early 2013.  2.8 GHz Core i7, 16GB DDR3 RAM, NVIDIA GeForce GT 650M 1024 MB.  The problem is observed both on the laptop’s built-in display and an external Dell monitor.

gfxCardStatus.app claims the NVIDIA is used when I’m plugged into the external monitor, and the built-in Intel HD4000 is used when disconnected, although “About This Mac” just shows the GT 650M in use in both situations.  The problem appears in both situations, which would seem to do serious damage to the graphics-card theory, but I don’t know.  Maybe gfxCardStatus.app is incorrect, and it’s always the 650M.

What’s the first build with Grid turned on?  I can try bisecting but don’t know how far back to go.
Just as a follow-up, weird thing I just noticed - bug renders differently on retina display vs. external monitor. On the external monitor (standard lcd, running 1920x1200), no mouse hover has effect (only scrolling), but on retina screen (2880 x 1800), as soon as I hover over something or try and select it, that's when it disappears.
I don't have a Mac, so I was using a VNC session on a desktop Mac Pro with card "Dual AMD FirePro D300-2GB VRAM".

The first revision Grid Layout was enabled is: r433853
https://chromium.googlesource.com/chromium/src/+/79bd413143afe5ad68104a3c99b9c04f64fc25ac

Dunno if you can reproduce it in Chrome 58 or not:
https://www.google.com/chrome/browser/beta.html
I downloaded the beta but as far as I can tell it’s still Chrome 57.  I launched it off the disk image and it reported 57, and being up to date.

I tried bisecting and it kept giving me builds that apparently didn’t recognize grid at all, since when I inspected the 'body' element it didn’t show me any 'display' values at all except for the one assigned by Chrome's user agent styles.  Can I beg a fully-formed Unix command to copy from here and paste into Terminal?
Regarding bisect you could use the following command:
tools/bisect-builds.py -a mac64 -g 455660 -b 433853 --use-local-cache -- --no-first-run --user-data-dir=/tmp http://meyerweb.com/

r455660 (good) should be 59.0.3037.0 and r433853 (bad) the first one that enabled Grid Layout by default.
I ran a bisect, but literally no examples of page-blanking were observed (i.e., I hit "g" after every quit).  At the end, I got:

You are probably looking for a change made after 433855 (known bad), but no later than 433863 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/0cab87a48e26580170d502dc54a195cecd5cf1ca..c37cee81d6fd96e5ac04933ec06c163ca9d7686f

…but since I didn’t see any of the Chromium builds it handed me do the page-blanking, I don’t know how much that result can be trusted.

I’m running a new bisect where I swapped the -g and -b values, just to see if it comes up with anything different.
No luck there either.  I couldn’t get any of the bisect downloads to show the problem.  Which Chromium build corresponds to the Chrome 57 release, and how to I get that?  Because if the Chromium build has no bug whereas the Chrome release does, that would be very much worth knowing.
57.0.2987.0 was r444632.

Then it went to the stable branch so I'm not sure if it's possible to download it with bisect-builds.

Hm.  I can’t figure out how to download a specific build anyway, so I guess that doesn’t help.  If you can give me a URL/Terminal command to grab a specific build that corresponds as closely as possible to C57, I’m happy to download and test.  Otherwise I’m at a loss.
Ran 'bisect-builds.py -a mac64 -b 444632 -g 446632 --use-local-cache -- --no-first-run --user-data-dir=/tmp http://meyerweb.com/' and couldn’t get a single one of them to show the problem.  I’m starting to think the problem lies in Chrome branch, not Chromium.  Once Chrome 58 is available as a beta, I’ll download and see what happens.
Cc: cbiesin...@chromium.org e...@chromium.org
If the problem is actually only on Chrome and not in Chromium I don't know how to help, sorry. :-(

Adding other people in CC just in case they can share any tip about this.
I’m still getting “Version 57.0.2987.98 beta (64-bit)” from https://www.google.com/chrome/browser/beta.html, so testing 58 is on hold.
Check the similar  issue 340138 : maybe something from that old thread could be helpful. And the usual things to try: a new chrome user profile with no extensions, reset chrome://flags to default, enable/disable GPU acceleration in settings.

>I can’t figure out how to download a specific build anyway

Use https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html
And https://omahaproxy.appspot.com to find build number from a version string.
I tried the recommendations in comment 7 on that post (https://bugs.chromium.org/p/chromium/issues/detail?id=340138#c7) and saw no change.  I’ll try the un-extended profile test next.
Found it.  It’s the Window Resizer extension.  I can’t believe I failed to try an un-extended profile.  I am very sorry to have wasted people’s time with this.
It also seems to be happening if you have LastPass installed. I was also seeing the issue and disabling Window Resizer did not fix the issue for me. I removed everything, and then started re-enabling.

Commenting in case this is useful to others although it seems to be an issue with extensions.
Owner: r...@igalia.com
Status: Assigned
I installed the Google translation plugin, select a text and then disappear(Mac Chrome 57).

Test URL: http://meyerweb.com/eric/css/


2017-03-14 09-50-42.mp4
3.7 MB View Download
Labels: Needs-Triage-M57
Labels: -Needs-TestConfirmation -Needs-Bisect -OS-Mac OS-All

Ok, so I managed to reproduce it reliably on Linux installing the Google Translate extension.
And the issue happens not only in M57, but also in M59 and in master.

And now I've a backtrace, as I guess suspecting the problem is with the Grids painting code:
[44:44:0314/125505.515595:FATAL:LayoutGrid.cpp(2072)] Check failed: !m_grid.needsItemsPlacement(). 
#0 0x7f86054a11ab base::debug::StackTrace::StackTrace()
#1 0x7f860549f83c base::debug::StackTrace::StackTrace()
#2 0x7f860550dd2f logging::LogMessage::~LogMessage()
#3 0x7f85eba93489 blink::LayoutGrid::paintChildren()
#4 0x7f85ebd89a84 blink::BlockPainter::paintContents()
#5 0x7f85ebd898a4 blink::BlockPainter::paintObject()
#6 0x7f85eb9d9ec5 blink::LayoutBlock::paintObject()
#7 0x7f85ebd889f7 blink::BlockPainter::paint()
#8 0x7f85eb9d9e45 blink::LayoutBlock::paint()
#9 0x7f85ebd88f8a blink::BlockPainter::paintChild()
#10 0x7f85ebd88edb blink::BlockPainter::paintChildren()
#11 0x7f85eb9d9e85 blink::LayoutBlock::paintChildren()
#12 0x7f85ebd89a84 blink::BlockPainter::paintContents()
#13 0x7f85ebd87f33 blink::BlockFlowPainter::paintContents()
#14 0x7f85ebd89853 blink::BlockPainter::paintObject()
#15 0x7f85eb9d9ec5 blink::LayoutBlock::paintObject()
#16 0x7f85ebd889f7 blink::BlockPainter::paint()
#17 0x7f85eb9d9e45 blink::LayoutBlock::paint()
#18 0x7f85ebdff299 blink::PaintLayerPainter::paintFragmentWithPhase()
#19 0x7f85ebdff4c1 blink::PaintLayerPainter::paintForegroundForFragmentsWithPhase()
#20 0x7f85ebdfdcdd blink::PaintLayerPainter::paintForegroundForFragments()
#21 0x7f85ebdfcad6 blink::PaintLayerPainter::paintLayerContents()
#22 0x7f85ebdfb4cf blink::PaintLayerPainter::paintLayerContentsCompositingAllPhases()
#23 0x7f85ebdfaa3e blink::PaintLayerPainter::paint()
#24 0x7f85ebdfd90e blink::PaintLayerPainter::paintChildren()
#25 0x7f85ebdfcb3e blink::PaintLayerPainter::paintLayerContents()
#26 0x7f85ebb8788c blink::CompositedLayerMapping::doPaintTask()
#27 0x7f85ebb88cff blink::CompositedLayerMapping::paintContents()
#28 0x7f85f5436111 blink::GraphicsLayer::paintWithoutCommit()
#29 0x7f85f5435cef blink::GraphicsLayer::paint()
#30 0x7f85eb4891dd blink::FrameView::paintGraphicsLayerRecursively()
#31 0x7f85eb48929b blink::FrameView::paintGraphicsLayerRecursively()
#32 0x7f85eb48929b blink::FrameView::paintGraphicsLayerRecursively()
#33 0x7f85eb48929b blink::FrameView::paintGraphicsLayerRecursively()
#34 0x7f85eb48929b blink::FrameView::paintGraphicsLayerRecursively()
#35 0x7f85eb4883ae blink::FrameView::paintTree()
#36 0x7f85eb48688e blink::FrameView::updateLifecyclePhasesInternal()
#37 0x7f85eb486052 blink::FrameView::updateAllLifecyclePhases()
#38 0x7f85ebd489ab blink::PageAnimator::updateAllLifecyclePhases()
#39 0x7f85f4ceb195 blink::PageWidgetDelegate::updateAllLifecyclePhases()
#40 0x7f85f4df8504 blink::WebViewImpl::updateAllLifecyclePhases()
#41 0x7f85f4deea41 blink::WebViewFrameWidget::updateAllLifecyclePhases()
#42 0x7f85ffe569db content::RenderWidget::UpdateVisualState()
#43 0x7f85ffc90e7a content::RenderWidgetCompositor::UpdateLayerTreeHost()
#44 0x7f85fba6ffad cc::LayerTreeHost::RequestMainFrameUpdate()
#45 0x7f85fbb3a1b2 cc::ProxyMain::BeginMainFrame()
#46 0x7f85fbb37a4c _ZN4base8internal13FunctorTraitsIMN2cc9ProxyMainEFvSt10unique_ptrINS2_28BeginMainFrameAndCommitStateESt14default_deleteIS5_EEEvE6InvokeIRKNS_7WeakPtrIS3_EEJS8_EEEvSA_OT_DpOT0_
#47 0x7f85fbb3790f _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN2cc9ProxyMainEFvSt10unique_ptrINS4_28BeginMainFrameAndCommitStateESt14default_deleteIS7_EEERKNS_7WeakPtrIS5_EEJSA_EEEvOT_OT0_DpOT1_
#48 0x7f85fbb37878 _ZN4base8internal7InvokerINS0_9BindStateIMN2cc9ProxyMainEFvSt10unique_ptrINS3_28BeginMainFrameAndCommitStateESt14default_deleteIS6_EEEJNS_7WeakPtrIS4_EENS0_13PassedWrapperIS9_EEEEEFvvEE7RunImplIRKSB_RKSt5tupleIJSD_SF_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#49 0x7f85fbb3778c _ZN4base8internal7InvokerINS0_9BindStateIMN2cc9ProxyMainEFvSt10unique_ptrINS3_28BeginMainFrameAndCommitStateESt14default_deleteIS6_EEEJNS_7WeakPtrIS4_EENS0_13PassedWrapperIS9_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#50 0x7f86054a7151 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv
#51 0x7f86054a69ce base::debug::TaskAnnotator::RunTask()
#52 0x7f85f56e2986 blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#53 0x7f85f56dfa7d blink::scheduler::TaskQueueManager::DoWork()
#54 0x7f85f56eaeb4 _ZN4base8internal13FunctorTraitsIMN5blink9scheduler16TaskQueueManagerEFvbEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKbEEEvS6_OT_DpOT0_
#55 0x7f85f56eadbf _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler16TaskQueueManagerEFvbERKNS_7WeakPtrIS6_EEJRKbEEEvOT_OT0_DpOT1_
#56 0x7f85f56ead33 _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvbEJNS_7WeakPtrIS5_EEbEEEFvvEE7RunImplIRKS7_RKSt5tupleIJS9_bEEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#57 0x7f85f56eac4c _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvbEJNS_7WeakPtrIS5_EEbEEEFvvEE3RunEPNS0_13BindStateBaseE
#58 0x7f86054a7151 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv
#59 0x7f86054a69ce base::debug::TaskAnnotator::RunTask()
#60 0x7f8605536d6d base::MessageLoop::RunTask()
#61 0x7f8605537004 base::MessageLoop::DeferOrRunPendingTask()

Attaching a very simple test case to reproduce the issue.

Steps to reproduce:
* Launch Chrome with Google Translate extension.
* Double click on "publication" word (Google Translate icon appears).
* Then click on a different word and it'll crash.

reduced-test-case-bug-700383.html
359 bytes View Download
Ok, so now I'm able to reproduce this without extensions at all.
It's a crash when you remove a positioned grid item.

The call to LayoutGrid::removeChild() marks the grid as dirty,
so when the repaint is done we got a crash.
crash-removing-positioned-grid-item.html
271 bytes View Download
Project Member Comment 31 by bugdroid1@chromium.org, Mar 15
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eb7634d5a91a495af9495164ffb2e5f1f91f7e09

commit eb7634d5a91a495af9495164ffb2e5f1f91f7e09
Author: rego <rego@igalia.com>
Date: Wed Mar 15 12:45:53 2017

[css-grid] Fix crash removing positioned grid item

When we add or remove a positioned item we don't need to mark
the grid as dirty, because positioned items do not affect the layout
of the grid at all.

This was causing a crash when a positioned item was removed
after a layout. As after the positioned item was removed,
the method LayoutGrid::layoutBlock() was not called,
so when the grid was repainted we got a crash.

BUG= 700383 
TEST=fast/css-grid-layout/grid-crash-remove-positioned-item.html

Review-Url: https://codereview.chromium.org/2748983003
Cr-Commit-Position: refs/heads/master@{#457061}

[add] https://crrev.com/eb7634d5a91a495af9495164ffb2e5f1f91f7e09/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-crash-remove-positioned-item-expected.txt
[add] https://crrev.com/eb7634d5a91a495af9495164ffb2e5f1f91f7e09/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-crash-remove-positioned-item.html
[modify] https://crrev.com/eb7634d5a91a495af9495164ffb2e5f1f91f7e09/third_party/WebKit/Source/core/layout/LayoutGrid.cpp

Labels: Merge-Request-58 Merge-Request-57
Status: Fixed
So this is fixed with the Google Translate extension.
I was taking a look to the Window Resize one, and that's also adding a positioned element on the body, so it might be the same issue.

Now this should be merged into M57 and M58 if possible.
Project Member Comment 33 by sheriffbot@chromium.org, Mar 15
Labels: -Merge-Request-57 Hotlist-Merge-Review Merge-Review-57
This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Per bug description this doesn't seem like an M57 regression. And M57 for Desktop is already in Stable and bar for taking any merges is VERY high. CL listed #31 is not yet made it to Canary. This will have to wait for M58. Please let me know if there is any concern here.


Ok, I don't know how this usually works I was just asking. Thanks for the info.

Just to clarify the issue, if you use a grid container on the body element
and you use some extension that adds/removes a positioned element on the page
your page will have problems for painting itself.

Probably that's not enough to making the cut for stable M57.
But I hope it can make it to M58.

Labels: -Merge-Review-57 Merge-Rejected-57
Rejecting merge to M57 based on comment #34 and after checking with eae@.
Project Member Comment 37 by sheriffbot@chromium.org, Mar 16
Labels: -Merge-Request-58 Hotlist-Merge-Approved Merge-Approved-58
Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 38 by bugdroid1@chromium.org, Mar 16
Labels: -merge-approved-58 merge-merged-3029
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f8c01b50cd38042bddf578f5539726cf57812447

commit f8c01b50cd38042bddf578f5539726cf57812447
Author: Manuel Rego Casasnovas <rego@igalia.com>
Date: Thu Mar 16 15:10:06 2017

[css-grid] Fix crash removing positioned grid item

When we add or remove a positioned item we don't need to mark
the grid as dirty, because positioned items do not affect the layout
of the grid at all.

This was causing a crash when a positioned item was removed
after a layout. As after the positioned item was removed,
the method LayoutGrid::layoutBlock() was not called,
so when the grid was repainted we got a crash.

BUG= 700383 
TEST=fast/css-grid-layout/grid-crash-remove-positioned-item.html

Review-Url: https://codereview.chromium.org/2748983003
Cr-Commit-Position: refs/heads/master@{#457061}
(cherry picked from commit eb7634d5a91a495af9495164ffb2e5f1f91f7e09)

Review-Url: https://codereview.chromium.org/2751303003 .
Cr-Commit-Position: refs/branch-heads/3029@{#240}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[add] https://crrev.com/f8c01b50cd38042bddf578f5539726cf57812447/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-crash-remove-positioned-item-expected.txt
[add] https://crrev.com/f8c01b50cd38042bddf578f5539726cf57812447/third_party/WebKit/LayoutTests/fast/css-grid-layout/grid-crash-remove-positioned-item.html
[modify] https://crrev.com/f8c01b50cd38042bddf578f5539726cf57812447/third_party/WebKit/Source/core/layout/LayoutGrid.cpp

Cc: brajkumar@chromium.org
 Issue 702427  has been merged into this issue.
Cc: kavvaru@chromium.org
Labels: Needs-Feedback
Tested the issue on Windows 7, Ubuntu 14.04 and Mac 10.12.3 using chrome version 58.0.3029.33 with the below steps

1. As per the comment #30 opened the crash-removing-positioned-grid-item.html 
2. Observed the "item" is displayed and not seen any crash
Please find the attached screen cast for the same.

But on reported version 57.0.2987.98 the "item" is displayed only after opening the dev tools.

rego@ could you please check and confirm if anything missed here.Please confirm the expected behaviour to verify the issue.

Thanks,
700383.mp4
422 KB View Download
Labels: -Needs-Feedback
Hi @kavvaru, if you're testing on a release build that's the expected behavior.
In M57 the item is not painted on the first load. In the fixed versions it should be painted.

If you use a debug build in M57 you should get a crash.

Thanks for testing it!
Labels: TE-Verified-M58 TE-Verified-58.0.3029.33
Thanks for the quick update.
Adding TE-Verified labels as per comment #41.

Cc: gov...@chromium.org pbomm...@chromium.org
 Issue 705214  has been merged into this issue.
 Issue 707269  has been merged into this issue.
Sign in to add a comment