Update:
Bisect info:

Change Log :https://chromium.googlesource.com/chromium/src/+log/da4aabbfc7beda8b1470d38509aa68fdacd7f2d4..c7aca3f876f0496447922f0f0ef6cbae2b9e9af5

Suspect:r 599434 or r 599439

@Lukasz Anforowicz :Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.


Note:

1.Unable to provide 'per-revision' bisect as it shows "We don't have enough builds to bisect" error message.
2.Tried on other machines but still getting the same error again.
3.Hence provided suspect through 'Chromium bisect'.
4.Issue is also seen on latest canary #72.0.3583.0.

Thank you..!

I can repro on a Mac on 72.0.3583.0.

I cannot repro on:
- Win on 72.0.3583.0
- Linux ToT at r600517

I looked at some other CLs in the range given in #c1 above, but I am not able to find a CL that seems reasonable to blame:
- r599459 (Refactor direct composition swap chain and visual logic) is Win-only
- r599435 (Fix scaling bug with OfflineContentProvider thumbnails in DHv2) is Android-only

Maybe this one?:
- r599439 ([Fullscreen Control Host] Post-MacViews cleanups for FullscreenControlHost)

yuweih@, could you PTAL and check if r599439 might be responsible?

Looks like I can't repro it on 72.0.3584.0 dev build.

Deleted: failed_to_repro.mov 21.5 MB

failed_to_repro.mov 21.5 MB Download

Looks like I can't repro it on 72.0.3583.0 canary either so I'm not sure if it is dependent on the user configuration or something..

r599439 just removes dead code from the codebase so I don't feel like it causes the regression.

FWIW, I can still repro on 72.0.3584.0 canary on Mac.  Removing and readding the extension doesn't help.

I wonder what is different between my machine and the one used in #c5.

I guess, I'll try doing a manual/local-build bisect...

malaykeshav@, can you PTAL?  I've manually bisected this bug to r599423 (Enable UsePaintRecordForImageSkia for Chrome OS).

Note that I've run the bisect on Mac.  I couldn't repro the bug on Windows and/or Linux (see #c2).  I don't know whether the bug repros on ChromeOS.

FWIW, I see that the blamed CL has been already merged to M-71.  Ooops...  Adding govind@ for visibility.

PS. My apologies for slow triage here (I partly blame build speed on Mac / lack of revision-targeting bisect tools for Mac, but I also could have prioritized this bug higher... :-/).

The blamed CL has not been merged to M71. Sorry for the confusion but the CL merged to M71 is Chrome OS only. [1]

I am not familiar with Mac, can someone experienced in Mac views point me to the code responsible for the rendering of that icon with count?

1-[https://chromium-review.googlesource.com/c/chromium/src/+/1281237/2/ui/gfx/switches.cc]

@spqchan
Would you be the right person to ask about the difference between Mac and the other platforms?

This is happening on Chrome OS too.
Both Mac and Chrome OS have GPU rasterization enabled for the browser UI.

Is the change need to be reverted from M71? If yes, pls request a merge to M71 for revert ASAP.

+ellyjones@, PTAL comment #10. Thank you.

#12 Reverting it is not feasible as it is critical to the UI.

Ok, then pls provide safe fix and then request a merge to M71 after canary baking.

+ccameron who has more knowledge on text rendering.
Can you shed some light on why text rendering might be wrong in this case?

Some context:
1) On some scalefactors 1 to 1.25, the text is visible as expected. But as the scale factor increases, the text disappears entirely. This suggests an issue that might be related to clipping or text eliding. 

2) We recently changed the way vector images and other CanvasImageSource[1] images are implemented. The icon that has the bug here is a CanvasImageSource which is generated by combining a bitmap (Extension icon) and putting a rounded rect with text ontop of it[2]. We used to store this image as an SkBitmap, but now we store them as PaintRecord and let cc handle the rasterization. Can this change have any effect in the way the text is rendered for an icon?


1 - [https://cs.chromium.org/chromium/src/ui/gfx/image/canvas_image_source.h?type=cs&g=0&l=25]
2 - [https://cs.chromium.org/chromium/src/chrome/browser/ui/extensions/icon_with_badge_image_source.h]

I have a hunch this may be related to OOP-R and images. +Khushal...

What happens if you disable "Out of process rasterization" in about:flags?

Definitely not related to OOP raster, since this is in UI. We haven't turned OOP raster on for UI on any platform.

UiGpuRasterization has been enabled on chromeos (crrev.com/c/1270215) Not sure how/if it's related though.

#22 
UiGpuRasterization is different from OOP raster from what I understand.

Disabling UiGpuRasterization has no effect on the bug. I can still repro.

Found the bug. The size that needs to be set on the RecordPaintCanvas is the pixel size. However, the size that is currently set is the DIP size. This results in anything out of bounds, like the icon text in this bug, to be clipped. 

Sending in a patch to set the correct pixel size

 Issue 895571  has been merged into this issue.

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

commit 4b414bd7617c09120faf6371c481e083eedcbef2
Author: Malay Keshav <malaykeshav@chromium.org>
Date: Wed Oct 24 22:01:36 2018

[RBS] Set the correct pixel size on RecordPaintCanvas for CanvasImageSource

When initializing a RecordPaintCanvas, the size set should be in pixels.
Right now we are setting the DIP size which is resulting in PaintOps
that are outside the clip bounds to be rejected all together.

This patch also adds a DCHECK to ensure that the clip bounds set on the
canvas matches the expected pixel size of the rasterized image.

Bug:  896203 
Change-Id: I10cf95bc656950c217d3ae464f277a0cb7140063
Component: CanvasImageSource
Reviewed-on: https://chromium-review.googlesource.com/c/1296687
Commit-Queue: Malay Keshav <malaykeshav@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602477}
[modify] https://crrev.com/4b414bd7617c09120faf6371c481e083eedcbef2/ui/gfx/image/canvas_image_source.cc

Pls update bug with canary result tomorrow. 

Also provide merge safety details. Thank you.

Update : 
Retested above issue on  Mac(10.13.1 , 10.13.6 , 10.14.1)  OS using latest Canary #72.0.3591.0 and issue is fixed,Entries/counts at extension's bottom are seen at extension's bottom.

Kindly review the attached screen-cast.
Thank you

Deleted: Canarybehaviourentries#72.0.3591.0.mov 8.2 MB

	Canarybehaviourentries#72.0.3591.0.mov 8.2 MB View Download

#30 This only effects Chrome OS for M71 and is safe to merge.

This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

kbleicher@ (Chrome OS M71 TPM) to do merge review as change effects Chrome OS only per comment #32.

Per #c31 (from shruti.jadhav@), #c2 and #c6 (from lukasza@) the bug also happened on Mac and was fixed on Mac.  Therefore the fix/merge has to affect not only Chrome OS but also Mac.

In fact, it is not clear to me why changes in ui/gfx/image/canvas_image_source.cc would only affect Mac and/or CrOS, but wouldn't affect Windows or Linux.  AFAICT ui/gfx/BUILD.gn includes image/canvas_image_source.cc everywhere except iOS.  I wonder if the bug might also repro on a high-DPI Windows device.

The bug was most likely in win and Linux as well for M72.

However on M71, this only effects Chrome OS as this bug is a result of some feature only enabled on chrome os for M71.

Approving merge to M71 branch 3578 based on comments #32, #35 and #36. Pls merge ASAP. Thank you.

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

commit fd47f329fe335046fcf28660866a8ca4ff2328dc
Author: Malay Keshav <malaykeshav@chromium.org>
Date: Fri Oct 26 20:21:14 2018

[m 71]Set the correct pixel size on RecordPaintCanvas for CanvasImageSource

When initializing a RecordPaintCanvas, the size set should be in pixels.
Right now we are setting the DIP size which is resulting in PaintOps
that are outside the clip bounds to be rejected all together.

This patch also adds a DCHECK to ensure that the clip bounds set on the
canvas matches the expected pixel size of the rasterized image.

Bug:  896203 
Change-Id: I10cf95bc656950c217d3ae464f277a0cb7140063
Component: CanvasImageSource
Reviewed-on: https://chromium-review.googlesource.com/c/1296687
Commit-Queue: Malay Keshav <malaykeshav@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#602477}(cherry picked from commit 4b414bd7617c09120faf6371c481e083eedcbef2)
Reviewed-on: https://chromium-review.googlesource.com/c/1302953
Reviewed-by: Malay Keshav <malaykeshav@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#350}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/fd47f329fe335046fcf28660866a8ca4ff2328dc/ui/gfx/image/canvas_image_source.cc

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

Commit: fd47f329fe335046fcf28660866a8ca4ff2328dc
Author: malaykeshav@chromium.org
Commiter: malaykeshav@chromium.org
Date: 2018-10-26 20:21:14 +0000 UTC

[m 71]Set the correct pixel size on RecordPaintCanvas for CanvasImageSource

When initializing a RecordPaintCanvas, the size set should be in pixels.
Right now we are setting the DIP size which is resulting in PaintOps
that are outside the clip bounds to be rejected all together.

This patch also adds a DCHECK to ensure that the clip bounds set on the
canvas matches the expected pixel size of the rasterized image.

Bug:  896203 
Change-Id: I10cf95bc656950c217d3ae464f277a0cb7140063
Component: CanvasImageSource
Reviewed-on: https://chromium-review.googlesource.com/c/1296687
Commit-Queue: Malay Keshav <malaykeshav@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#602477}(cherry picked from commit 4b414bd7617c09120faf6371c481e083eedcbef2)
Reviewed-on: https://chromium-review.googlesource.com/c/1302953
Reviewed-by: Malay Keshav <malaykeshav@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#350}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

 Issue 899561  has been merged into this issue.

Update : 
Retested above issue on  Mac(10.13.1 , 10.13.6 , 10.14.1)  OS using  Beta #71.0.3578.30 and issue is fixed,Entries/counts at extension's bottom are seen at extension's bottom.

Kindly review the attached screen-cast.
Thank you

Deleted: Beta71.0.3578.30.mov 13.9 MB

	Beta71.0.3578.30.mov 13.9 MB View Download

#41 This did not effect Mac on M71. Only Chrome OS.
Please verify for Chrome OS.

Checked on latest M-71 71.0.3578.31/11151.18.0 beta-channel Kip device and issue is working fine .
Attaching screen cast for reference

Thanks..!!

Deleted: On71.0.3578.31.mp4 16.5 MB

On71.0.3578.31.mp4 16.5 MB Download

 Issue 900769  has been merged into this issue.

Testing adding label `TE-Verified-71.0.3578.30`

Apologies for the noise, re-adding labels that got removed