This worked correcting in Chrome 63.

Confirmed. Bisect pending/

Bisects to a big range on linux. Might be a smaller range on other platforms. https://chromium.googlesource.com/chromium/src/+log/ef2eab41718963ccfa224ea291f8bbf48ea62ffe..dc7f3672754f4c758eab130200ef15ef3cef668b

Most likely candidate, since it deals with transparency, is: "cc: Implement alpha folding during serialization."
https://chromium.googlesource.com/chromium/src/+/92f669180c3fa4c7190817870ead6155e12fcc78

Definitely not that one. The code it touched only affects paint serialization for OOP Raster which is disabled by default.

There's nothing in the bisect that I did that screen out as the cause. I'll try a bisect on Mac.

If it's helpful, we also have users of ours that have reported the issue on Windows 10: 
Version 64.0.3282.119 (Official Build) (64-bit)

Narrower range on Mac: https://chromium.googlesource.com/chromium/src/+log/6f3478dfd7d29b9872871718bd08493ed0c8bc8e..6abc3144bdeabb9d6d965896f530d12e8c0481c4
Thats 517594 to 517612

Linux was 517597 to 517832.

The Skia roll seems the most likely candidate at this point (and it's in both bisects).
https://chromium.googlesource.com/chromium/src/+/6abc3144bdeabb9d6d965896f530d12e8c0481c4

dan@ Thanks for the issue.

Able to reproduce this issue on Mac OS 10.12.6, Windows 10 on the latest Stable 64.0.3282.140 and Canary 66.0.3336.0 by following the steps mentioned in the original comment.
Unable to reproduce this issue on Ubuntu 14.04 and 17.10 at our end.

Bisect Information:
====================
Good Build : 64.0.3271.0 (Revision - 517250)
Bad Build  : 64.0.3272.0 (Revision - 517671)

On executing the per-revision bisect script, below is the changelog URL.

Changelog URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/c22227095c899aed65e70000d4c23370b06f69c1..6abc3144bdeabb9d6d965896f530d12e8c0481c4

From the above Changelog URL, suspecting the below change for this issue.
Reviewed-on: https://chromium-review.googlesource.com/777760

Adding ReleaseBlock-Stable as this is a recent Regression. Please feel free to remove the same if this is not applicable.

Thanks...

susanjunia.boorgula@, never assign bugs to an auto deps roller. That is a bot that cannot process bugs. Always mark such as Untriaged and pass to the team responsible for the auto roller.

Assigning this issue to file reviewer from the CL: https://chromium-review.googlesource.com/777760.

@brianosman: Could you please take a look at this issue and also help us in assigning this issue to appropriate owner if this is not related to your change.

Thanks!!

@fmalita: Here's the bug with the malformed (2B x 45) image

Also: FWIW, the CL that exposed this bug was https://skia-review.googlesource.com/c/skia/+/73200, but the change in behavior within Skia just calls more attention to the fact that the input is bogus. (ie we should not revert the Skia change).

Able to reproduce the issue on Chrome 64.0.3282.144/10176.68.0 -Peppy

Sorry, how is the input bogus? Claiming a size without the data?

The Skia change introduced some inconsistency between CPU/GPU handling of empty shaders, but the root cause is Blink instantiating a humongous picture shader (MAX_INT X 45).

@schenney the background tile size is pixel-snapped and collapses to 0 x 45 @90%, which is then used in some computations and yields a [-nan x 100] picture shader tile, sanitized to [MAX_INT, 100] at raster time.

I will add a check to catch the empty bg image tile case, but I'm not sure the pixel snapping behavior is correct - you may want to look into that.

I'm completely removing as much pixel snapping for backgrounds as I can, and certainly any late snapping. It's proving tricky though.

Feel free to patch up the existing code.

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

commit 29b1d41472649f7d60ab0de918ae8ab88259544c
Author: Florin Malita <fmalita@chromium.org>
Date: Tue Feb 06 00:16:18 2018

Skip backgrounds when the computed tile size is empty

The computed background geometry tile size may end up empty due to
pixel-snapping.  In that case, all derived calculations are invalid and
we should not attempt to draw the background.

R=schenney@chromium.org
BUG= 808065 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: If14ea82ca158318374296184a8f44856c19dcb64
Reviewed-on: https://chromium-review.googlesource.com/902148
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534545}
[add] https://crrev.com/29b1d41472649f7d60ab0de918ae8ab88259544c/third_party/WebKit/LayoutTests/fast/backgrounds/tiny-tile-zoomed-expected.html
[add] https://crrev.com/29b1d41472649f7d60ab0de918ae8ab88259544c/third_party/WebKit/LayoutTests/fast/backgrounds/tiny-tile-zoomed.html
[modify] https://crrev.com/29b1d41472649f7d60ab0de918ae8ab88259544c/third_party/WebKit/Source/platform/graphics/Image.cpp

fmalita@/schenney@, could someone please comment on severity of this bug (how wide spread?) for M64 stable rollout? Also wondering, this fix can wait till M65 reaches stable?

Thank you!

Note that we are failing to render the background in all cases (before breakage/after the "fix" too), and the Skia change just made this failure more obvious against light backgrounds by drawing a black box.

The issue is also restricted to GPU rasterization and background images that get scaled to < 1px in one dimension under zoom.

So I'm inclined to label it as medium severity, and not push the fix to stable.

OTOH I wouldn't be shocked if repeating 1px backgrounds turn out to be some common CSS technique, and the patch is trivial and safe to merge.  I'll leave it to schenney@ to decide if we should merge, and how far back.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; 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-64 label, otherwise remove Merge-TBD label. Thanks.

Per conversation offline, we're planning to merge this to M65+.

Sounds like we're going to re-spin M64 this week also, so let's try to push it there too.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Can you please comment on why this is an urgent bug that needs to be fixed in M64? What are the implications if we wait until M65? 

Can you please comment on how safe this merge is overall? Reproducing this easily, and if the merge is extremely safe and no chances of introducing new regressions, then we can merge. 

I don't think the bug is critical enough to warrant an M64 re-spin on its own, but we should consider merging because a) the fix is simple/safe and b) IIUC we are about to update M64 anyway.

The merge is trivial, and extremely low-risk (continuing the draw in this case could never produce good results):

@@ -128,6 +128,9 @@
                                 const FloatSize& scaled_tile_size,
                                 SkBlendMode op,
                                 const FloatSize& repeat_spacing) {
+  if (scaled_tile_size.IsEmpty())
+    return;
+
   FloatSize intrinsic_tile_size(Size());
   if (HasRelativeSize()) {
     intrinsic_tile_size.SetWidth(scaled_tile_size.Width());

Per #33 and convo with fmalita@, the fix is very safe and tested in canary. Since it's RBS and with a trivial fix, approving for M64 merge. Branch:3282

Also approving merge to M65 branch 3325 based on comment #34. 

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

commit edc4cbc214a1e7fd403f5cafbf0c669ca68e87f1
Author: Florin Malita <fmalita@chromium.org>
Date: Tue Feb 06 19:55:19 2018

Skip backgrounds when the computed tile size is empty

The computed background geometry tile size may end up empty due to
pixel-snapping.  In that case, all derived calculations are invalid and
we should not attempt to draw the background.

R=schenney@chromium.org
TBR=
BUG= 808065 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: If14ea82ca158318374296184a8f44856c19dcb64
Reviewed-on: https://chromium-review.googlesource.com/902148
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#534545}(cherry picked from commit 29b1d41472649f7d60ab0de918ae8ab88259544c)
Reviewed-on: https://chromium-review.googlesource.com/905342
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#654}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[add] https://crrev.com/edc4cbc214a1e7fd403f5cafbf0c669ca68e87f1/third_party/WebKit/LayoutTests/fast/backgrounds/tiny-tile-zoomed-expected.html
[add] https://crrev.com/edc4cbc214a1e7fd403f5cafbf0c669ca68e87f1/third_party/WebKit/LayoutTests/fast/backgrounds/tiny-tile-zoomed.html
[modify] https://crrev.com/edc4cbc214a1e7fd403f5cafbf0c669ca68e87f1/third_party/WebKit/Source/platform/graphics/Image.cpp

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

commit 449dc9f5f690e26bc3e9e0530312051e2e129a4d
Author: Florin Malita <fmalita@chromium.org>
Date: Tue Feb 06 19:57:25 2018

Skip backgrounds when the computed tile size is empty

The computed background geometry tile size may end up empty due to
pixel-snapping.  In that case, all derived calculations are invalid and
we should not attempt to draw the background.

R=​schenney@chromium.org
BUG= 808065 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: If14ea82ca158318374296184a8f44856c19dcb64
Reviewed-on: https://chromium-review.googlesource.com/902148
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#534545}(cherry picked from commit 29b1d41472649f7d60ab0de918ae8ab88259544c)
Reviewed-on: https://chromium-review.googlesource.com/905362
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#349}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[add] https://crrev.com/449dc9f5f690e26bc3e9e0530312051e2e129a4d/third_party/WebKit/LayoutTests/fast/backgrounds/tiny-tile-zoomed-expected.html
[add] https://crrev.com/449dc9f5f690e26bc3e9e0530312051e2e129a4d/third_party/WebKit/LayoutTests/fast/backgrounds/tiny-tile-zoomed.html
[modify] https://crrev.com/449dc9f5f690e26bc3e9e0530312051e2e129a4d/third_party/WebKit/Source/platform/graphics/Image.cpp

Tested this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Chrome Build 64.0.3282.167 by following the below steps.

On loading the given html file and Zoom out to 90%, cannot observe any black bar and can see the text without any issues.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 808065-CL.webm 1.4 MB

	808065-CL.webm 1.4 MB View Download

Tested this issue on Windows 7, Mac 10.12.6 & Debian Rodate using chrome beta-65.0.3325.73 as per the steps mentioned in C#0.
No black patch observed after zoom out & zoom in for the loaded html file & text displayed clearly without any issue.

Please find the attached screencast for reference.As it is working as intended on beta adding TE Verified labels for the same.

Thanks..!

Deleted: 808065.mp4 824 KB

	808065.mp4 824 KB View Download