Steven would this belong in MD Settings? If not, any idea who should own this?

This is part of the system tray UI and unrelated to settings. -> tdanderson@ to triage

+xiyuan@, +oshima@, +jamescook@ - This looks like some weird interaction within views?

This could be due to any number of things:

* jdufault@'s recent work on the login/lock screens
* minch@'s recent work on the volume (but not brightness) slider
* alemate@'s new OOBE experience
* The MD-ification of the system menu and slider

The provided bisect range (m-55 to m-59/60) is far too large. Applying Needs-Bisect to request a revision-level bisect on the Chromium CL responsible (note that the offending CL is almost certainly in the Chromium, not Chromium OS, codebase).

Any webui should not be interacting with system tray. oobe/login/lock are a single views::WebView covering the entire screen.

I'll bet the "work area" for the screen is incorrect. No idea why that would happen, though.

I'm also unclear whether the status area (like the network icon and clock) should appear during these flows or not.

Re #6: I think that the status area should remain visible during these flows, as a user may wish to switch networks or enable an a11y feature.

I tried to revert my cl about the volume slider.
This bug can still repros with my CL reverted locally.
https://codereview.chromium.org/2812223005/

As we don not have bisect setup for chrome OS providing following info.Hope this is will be helpful.

Good:55.0.2883.105/8872.76.0
Bad:56.0.2924.121/9000.97.0

Note: Issue is also reproducible on 57.0.2987.154/9202.71.0 Beta and 58.0.3029.98/9334.64.0	Stable.

Thanks!

I will be OOO for the next ~2 weeks or so. Marking as Available in case anyone else has cycles to dig into this a bit more.

./tools/binary-bisect.py should work for ChromeOS.

Back into UI > Shell triage queue.

tdanderson@ have you had a chance to look at this?
/triage

Based on the large bisect range provided in #9, this regressed between revision #423769 (Oct 7 2016) and #433059 (Nov 18 2016). Skimming over the git revision log of chrome/browser/chromeos/login/ within this range, it looks as though jdufault@ is in the best position to suggest next steps here; I am not familiar with any of the login/lock type screens.

Based on the screenshots in #0 this could be a side effect of whenever the visuals of this screen were updated (perhaps due to a change in window bounds / positioning?)

As a side note, I can't reproduce this locally: with the command line flags --login-manager --login-screen=reset the sliders are not shown as clipped. This may be somehow device-specific.

<triage> Cannot reproduce on 72.0.3593.0, please reopen if seen again. </triage>