Does this happen on other OSes?

I am unable to test this on other OSes at the moment.

Thank you for providing more feedback. Assigning to requester "ccameron@chromium.org" for another review.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Adding Blink>Paint>Invalidation as a guess.

Almost certainly a cull rect or other bounding box issue. On linux it doesn't repro, suggesting an issue with the Mac input forms.

Able to reproduce only on Mac OS 10.11.3 using chrome stable M49-49.0.2623.87 and canary M51-51.0.2681.0. All Other OS is working fine.

Bisect Information:
===================
Good build: 45.0.2433.0 
Bad Build : 45.0.2435.0 

Change Log URL: https://chromium.googlesource.com/chromium/src/+log/73a93553ebc251a92e6de9d5fd90bd4640f1ed71..07d847b1c5451748f16f4e7973ce8ef9078d47a2

From the above change log suspecting below

Review URL: https://codereview.chromium.org/1174183003

wkorman@ - 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.

Thanks!

Bisect points to turning on Slimming Paint. Will look when I can or chrishtr@ can reassign.

Confirmed Mac Canary currently broken, Linux Stable/ToT is fine. Further investigation needed.

Probably the cull rect for the DrawingDisplayItems is wrong.

Can we have an update on this issue?

Test case without codepen.io involved attached. Further reduction to come. Cull rect for LayoutTextControl INPUT does not look immediately wrong.

new display item list: [{index: 0, client: "0x1b3fa9732ae0 LayoutView #document", type: "CachedDrawingDebugRedFill", cacheIsValid: true},
{index: 1, client: "0x2143e6c04018 LayoutView #document", type: "CachedDrawingDocumentBackground", cacheIsValid: true},
{index: 2, client: "0x2143e6c14108 LayoutBlockFlow HTML", type: "Subsequence", cacheIsValid: true},
{index: 3, client: "0x2143e6c18130 LayoutBlockFlow BODY", type: "DrawingBoxDecorationBackground", cacheIsValid: false},
{index: 4, client: "0x2143e6c18360 LayoutBlockFlow DIV class='panel panel-default'", type: "DrawingBoxDecorationBackground", rect: [-1.000000,0.000000,802.000000,59.640625], cacheIsValid: false},
{index: 5, client: "0x2143e6c18478 LayoutBlockFlow DIV id='headingOne' class='panel-heading'", type: "CachedDrawingBoxDecorationBackground", cacheIsValid: true},
{index: 6, client: "0x2143e6c34010 InlineTextBox 'Collapsible Group Item #1'", type: "CachedDrawingPaintPhaseForeground", cacheIsValid: true},
{index: 7, client: "0x2143e6c186a8 LayoutBlockFlow (relative positioned) DIV id='collapseOne' class='panel-collapse collapsing'", type: "ClipLayerForeground", clipRect: [1,38,798,19], cacheIsValid:
 false},
{index: 8, client: "0x2143e6c187c0 LayoutBlockFlow DIV class='panel-body'", type: "DrawingBoxDecorationBackground", rect: [1.000000,38.000000,798.000000,57.000000], cacheIsValid: false},
* {index: 9, client: "0x2143e6ca4018 LayoutTextControl INPUT", type: "DrawingBoxDecorationBackground", rect: [16.000000,54.000000,152.000000,26.000000], cacheIsValid: false},
{index: 10, client: "0x2143e6c186a8 LayoutBlockFlow (relative positioned) DIV id='collapseOne' class='panel-collapse collapsing'", type: "EndClipLayerForeground", cacheIsValid: false},
{index: 11, client: "0x2143e6c14108 LayoutBlockFlow HTML", type: "EndSubsequence", cacheIsValid: true}]

Deleted: half-rendered.html 1022 bytes

half-rendered.html 1022 bytes View Download

The clip rect on the containing div could however be involved:

{index: 7, client: "0x2143e6c186a8 LayoutBlockFlow (relative positioned) DIV id='collapseOne' class='panel-collapse collapsing'", type: "ClipLayerForeground", clipRect: [1,38,798,19], cacheIsValid:

Does not look clip related.

Test case essentially grows the height of the containing div with 'panel-default' class on it during transition. Some Mac-specific sizing, layout, or painting logic must be involved. I looked briefly at ThemeMac.mm and LayoutThemeMac.mm.

Spent some time working to further reduce test case but it will be time consuming due to bootstrap abstraction complexity.

We paint the text input field within painting the fragment for the expanding containing panel, in the layout tree post-click during expansion as:

LayoutBlockFlow (relative positioned) DIV id='collapseOne' class='panel-collapse collapsing'

This fragment's foregroundRect is typically something like:

[77099:1295:0504/164837:2518569611569332:ERROR:PaintLayer.cpp(1502)] fragment.foregroundRect="1.000000,38.000000 798.000000x17.203125"

We treat this rect as the cull rect / interest rect in ThemePainterMac::paintTextField:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/paint/ThemePainterMac.mm&q=themepaintermac&sq=package:chromium&type=cs&l=60

and we clip to it in LocalCurrentGraphicsContext:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/platform/mac/LocalCurrentGraphicsContext.mm&q=localcurr&sq=package:chromium&type=cs&l=55

With sample values as below, the clip rect is only about half as high as it should be to paint the full text input field.

[77099:1295:0504/164837:2518569611983363:ERROR:LocalCurrentGraphicsContext.mm(51)] Clipping to interest rect [interestRect="1,38 798x17", m_inflatedDirtyRect="14,52 156x30"].

We only paint the text input field once, and when we do we are clipping to this overly-small rect. Commenting out the clipping fixes the issue.

I'm not sure yet whether the fragment foreground rect is incorrect, or we should be re-painting the text input field more than once during the expansion, or something else.

Is it the displayitem for it marked as uncached?

Initially, when we first paint it:

{index: 9, client: "0x344d750a4018 LayoutTextControl INPUT", type: "DrawingBoxDecorationBackground", rect: [16.000000,54.000000,152.000000,26.000000], cacheIsValid: false},

Subsequently:

{index: 9, client: "0x344d750a4018 LayoutTextControl INPUT", type: "DrawingBoxDecorationBackground", rect: [16.000000,54.000000,152.000000,26.000000], cacheIsValid: true},

The caching did occur to me as culprit, I tried using DisplayItemCacheSkipper earlier within ThemePainterMac but perhaps need to do elsewhere or I borked the attempt somehow.

Potentially related bugs:

 http://crbug.com/605812 
 http://crbug.com/531974 

I think we'd need to fiddle the cache skipper logic here:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/paint/BoxPainter.cpp&q=boxpainter.cpp&sq=package:chromium&type=cs&l=77

Experimentally unconditionally disabling the cache in aforementioned BoxPainter line fixes both this issue and  http://crbug.com/531974 , but unsure what logic we'd use to determine basis for skipping. For further discussion.

IIRC we never finished implementing cache skipping correctly for Mac themes.

In this case, the dirty rect we're clipping to is not actually the interest rect of the graphics layer, but rather the clip inherited from an overflow clip ancestor.

Option 1: plumb the actual interest rect here and use the cache skipper to avoid caching these items.

Pro: should be totally correct
Con: have to do all the work of plumbing and correct skipping

Option 2: apply an arbitrary cap to the size of theme elements, and call it a day.

Pro: easy to do. Possibly allows us to delete the cache skipper class entirely, if we can get rid of the
other use case.
Con: truly huge (>>5000px tall/wide) text areas will not render correctly.

I vote for option 2. 

This bug and  bug 531974  seem also related to  bug 490725 . I'm looking into if they are really related and if we could have option 3: during paint invalidation, invalidate any display item that will apply changed ancestor overflow clip. The workaround for  bug 490725  forces paint invalidation rect recalc when ancestor overflow clip may change.

About DisplayItemCacheSkipper, I thought of changing ScopeRecorder to DisplayItemCacheSkipper because we don't actually use the scope ids for purposes other than disabling the cache.

 Issue 531974  has been merged into this issue.

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

commit ec218fb8a6013ab21b83590acf77530cbbce1097
Author: wkorman <wkorman@chromium.org>
Date: Mon May 09 23:19:15 2016

Clamp Mac theme painting to reasonable large bounds.

Previously we aimed to clip to the interest rect of the graphics layer in LocalCurrentGraphicsContext. However, in some cases the rect we clip to is the clip inherited from an overflow clip ancestor, which can lead to complexity w.r.t. caching.

Rather than reworking interest rect and cache skipping logic across the code base for Mac theme specific painting purposes, we choose to clamp Mac theme painting to a reasonable bounding size. This means huge elements requiring native element painting will no longer render correctly, but in such cases we may already have been performing poorly.

BUG= 592915 

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

[modify] https://crrev.com/ec218fb8a6013ab21b83590acf77530cbbce1097/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/ec218fb8a6013ab21b83590acf77530cbbce1097/third_party/WebKit/LayoutTests/fast/forms/huge-mac-input-clamped-height.html
[add] https://crrev.com/ec218fb8a6013ab21b83590acf77530cbbce1097/third_party/WebKit/LayoutTests/fast/forms/huge-mac-input-clamped-width.html
[modify] https://crrev.com/ec218fb8a6013ab21b83590acf77530cbbce1097/third_party/WebKit/Source/core/layout/LayoutThemeMac.mm
[modify] https://crrev.com/ec218fb8a6013ab21b83590acf77530cbbce1097/third_party/WebKit/Source/core/paint/ThemePainterMac.mm
[modify] https://crrev.com/ec218fb8a6013ab21b83590acf77530cbbce1097/third_party/WebKit/Source/platform/mac/LocalCurrentGraphicsContext.h
[modify] https://crrev.com/ec218fb8a6013ab21b83590acf77530cbbce1097/third_party/WebKit/Source/platform/mac/LocalCurrentGraphicsContext.mm

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

commit ba715e5a613904ee9ded33437e773270185550dc
Author: Rebaseline Bot <blink-rebaseline-bot@chromium.org>
Date: Tue May 10 00:48:26 2016

Auto-rebaseline for r392468

https://chromium.googlesource.com/chromium/src/+/ec218fb8a

BUG= 592915 
TBR=wkorman@chromium.org

Review URL: https://codereview.chromium.org/1963653004 .

Cr-Commit-Position: refs/heads/master@{#392497}

[modify] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/linux/fast/forms/huge-mac-input-clamped-height-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/linux/fast/forms/huge-mac-input-clamped-height-expected.txt
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/linux/fast/forms/huge-mac-input-clamped-width-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/linux/fast/forms/huge-mac-input-clamped-width-expected.txt
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/mac-mac10.9/fast/forms/huge-mac-input-clamped-height-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/mac-mac10.9/fast/forms/huge-mac-input-clamped-height-expected.txt
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/mac-mac10.9/fast/forms/huge-mac-input-clamped-width-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/mac/fast/forms/huge-mac-input-clamped-height-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/mac/fast/forms/huge-mac-input-clamped-height-expected.txt
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/mac/fast/forms/huge-mac-input-clamped-width-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/mac/fast/forms/huge-mac-input-clamped-width-expected.txt
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/win/fast/forms/huge-mac-input-clamped-height-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/win/fast/forms/huge-mac-input-clamped-height-expected.txt
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/win/fast/forms/huge-mac-input-clamped-width-expected.png
[add] https://crrev.com/ba715e5a613904ee9ded33437e773270185550dc/third_party/WebKit/LayoutTests/platform/win/fast/forms/huge-mac-input-clamped-width-expected.txt