If it's a cordova app, is the webview rendering in software mode?

I'm not aware of the concept of "software mode".  How do I tell?

I assume same content in chrome is fine?

This content normally runs (correctly) as an extension for desktop Chrome.

On Android, the content requires access to APIs provided by Cordova plugins, so I don't know of any way to run it in Chrome for Android.

You are probably more familiar with the page content than me. Do you see expected dom mutation in devtools if after you that last tap?

There are some logs, warnings and one 404 I see in console tab.

> If it's a cordova app, is the webview rendering in software mode?

It's not software.

Hmm.  It looks like the CSS is stuck at "display:none" until after the screen rotate event.  I don't understand why this would happen.  (It doesn't happen on desktop.)

Feels like a bug in blink then. Rotation just causes a resize, which of course causes a re-layout and invalidates everything.

What's supposed to cause the display to change? I can set a breakpoint for uproxy-action-dialog on attribute modification, and saw js setting display to '' (ie removing it?) as part of rotation. What's supposed to be triggering those js calls normally though?

It's inside of Polymer, so I'm not sure how it actually happens.  The furthest I've really traced is to "_this.$.dialog.open()" on line 13193 of top/fmdppp.../generic_ui/polymer/vulcanized.static.js.  Everything beyond that is Polymer magic.

Oh, actually devtools gives you the js stack when the break point triggers. Buttom of the stack is atEndOfMicrotask polymer.js:8123 (or an async task posted from it), which is kinda useless for me to figure out "what's supposed to call this".

Anyway, looks like there is some more debugging to be done from devtools first. Could very well be a js bug I guess. If you still think this is a browser bug, then at least investigation should allow you to produce a smaller repro case for blink people to look at? Hopefully it that will reproduce on chrome on android as well.

Gonna unassign myself for now

I'm back on bug triage duty. Did polymer folks end up help out here? Is this bug still relevant? If not, can I close it?

And I got rotated to triage duty again. Guess no one cares about this anymore

Sorry for the delay in replying. This issue does still affect us. We're currently working around it with the following:

// Force a repaint every 300 ms.
// Extremely hacky workaround for  https://crbug.com/612836 
setInterval(function() {
  window.top.dispatchEvent(new Event('resize'));
}, 300);

My more urgent priority at the moment is debugging why animations are so janky on Android, but if it would still be helpful, I can try to work up a more minimal repro when I get a chance.

I guess this should go to polymer component then? I expect polymer folks will want a minimal repro, probably preferrably one that also works on chrome, so like a jsfiddle or a html file to load

(I assume that's the right component..)

Not sure if related, but the comments section of http://stackoverflow.com/a/3485654 has quite the long list of other people reporting that WebKit is failing to issue repaints properly, and without Polymer implicated in any of those.

Not Infra..just updated the labels.

I see two hints here. One is Comment #7 about "display: none" staying longer than it should, and the other is Polymer magic (Comment #9).

CCing Polymer engineer for possible insights.

I don't think this is related other repaint problems we've been having. Those are all related to paint invalidations being wrong for various reasons. There's no evidence that we're getting any CSS update at all here.

We really need a reduction that doesn't involve installing an APK.

This bug seems to have fallen through the cracks and is being reported as stale-triage. 

bemasc@, are you able to make a reduced webpage that we can look at where we don't need to install an apk or be whitelisted for an app?

Closing as the reporter is not responding.