Narrow Bisect info : 
https://chromium.googlesource.com/chromium/src/+log/c3a66160054fa86b6b46f374db0a4439ed868280..d31013d806afc0c5dce0c24e40c30f97a4adf972?pretty=fuller&n=10000

Suspecting : r 471337 ? from Narrow Bisect 

@glebl : Could you please look into this issue, if it's related to your change? if not could you please help us to reassign this issue to the right owner.

Thank you!

Adding release block label, please undo if not the case.

The bisect seems plausible. Please revert if you cannot fix it quickly. We have a 30-day SLA for P1 regressions on the paint team.

glebl has left Chrome. Floats strike again. Sending to Emil for next steps.

Able to reproduce the issue on windows 7 using chrome version 60.0.3112.24.
eae@ Could you please look into this issue as this is marked as stable blocker .

Thanks,

Still able to reproduce the issue on Win 7 using latest chrome version 61.0.3136.0

eae@ Please look into this as it is marked as stable blocker.

Thanks,

Turns out Glebs fix for double painting sometimes cause us to not paint at all. 
Before we revert the change would you mind taking a look Rob to see if there's an easy way to fix it?

Thank you.

Glebs patch: https://codereview.chromium.org/2875163002

Gentle ping to robhogan@.

 Issue 736829  has been merged into this issue.

We lack a good test for the original issue, though I have created one for the regression. Personally I haven't succeeded in reducing the original issue and have given up trying.

CL at https://chromium-review.googlesource.com/c/547055 which is certainly one way to fix the problem, though I believe it's more related to managing the ownership of paint when moving objects around the layout tree.

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

commit a171aaf13db9680bec6a33aa682bf4d54ab372d6
Author: Robert Hogan <robhogan@gmail.com>
Date: Thu Jun 29 20:46:08 2017

Don't try to determine a float's painter again if we've already done so.

We lack a good test from https://codereview.chromium.org/2875163002, and I have
not been able to reduce the repro at 717755 to create one. The test here covers
the regression in 731044.

One half of this CL is to revert the patch in https://codereview.chromium.org/2875163002.
The other change I'm making makes sense for what it is and also reduces the overall
work associated with SetShouldPaint. I do think the root cause is equally probably
somewhere in the mechanics of managing float ownership while moving children
around the layout tree so in the absence of a good original test case for
717755 this may be only a superficial fix rather than the root of the problem.

Bug:  731044 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I779e14da6c7fea524e6bf9582223ba25c2b5a308
Reviewed-on: https://chromium-review.googlesource.com/547055
Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483480}
[add] https://crrev.com/a171aaf13db9680bec6a33aa682bf4d54ab372d6/third_party/WebKit/LayoutTests/paint/float-painted-when-no-longer-self-painting-expected.html
[add] https://crrev.com/a171aaf13db9680bec6a33aa682bf4d54ab372d6/third_party/WebKit/LayoutTests/paint/float-painted-when-no-longer-self-painting.html
[modify] https://crrev.com/a171aaf13db9680bec6a33aa682bf4d54ab372d6/third_party/WebKit/Source/core/layout/FloatingObjects.cpp
[modify] https://crrev.com/a171aaf13db9680bec6a33aa682bf4d54ab372d6/third_party/WebKit/Source/core/layout/LayoutBlockFlow.cpp

Tested the issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.5 using chrome latest Canary M61-61.0.3150.0 by following steps mentioned in the original comment. Observed that menu icon is displaying as expected. Hence adding TE-Verified label.

Please view the attachment for more information.

Thank you!

Deleted: 731044.mp4 2.2 MB

	731044.mp4 2.2 MB View Download

robhogan@, Please mark it as 'Fixed' if there are no pending CLs.

Thank you!

robhogan@ Could you please update on comment #16.

Thank You!

[Auto-generated comment by a script] We noticed that this issue is targeted for M-60; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-60 label, otherwise remove Merge-TBD label. Thanks.

eae@ do you think this is safe to merge?  This looks like a change we want to take.

Discussed offline and this is too high risk for merging into M60.  Moving it to M61.

 Issue 754306  has been merged into this issue.

 Issue 755786  has been merged into this issue.

 Issue 756334  has been merged into this issue.