cthomp: assigning to you based on reference in go/estark-on-leave.

This looks like an issue with CollectedCookiesView [1], not the security indicator, so adjusting components.

I'm also curious if this can happen with other WebModalDialogViews (this gets created through [2] and [3] -- what else is the same and could be long enough to trigger this on text scaling?). 

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/views/collected_cookies_views.h?dr=CSs&g=0&l=39
[2] https://cs.chromium.org/chromium/src/components/constrained_window/constrained_window_views.cc?l=186&gsn=ShowWebModalDialogViews
[3] https://cs.chromium.org/chromium/src/components/constrained_window/constrained_window_views.cc?l=220&gsn=CreateWebModalDialogViews

Removing myself as owner as I don't think I'm the right person to own this (since I think the cause is higher up the stack in views or components/constrainted_window.

+msw@ for more thoughts on whether this involves constrained_window.

It's hard to tell what's happening in that screenshot, is the dialog taller than the display?
I'm not working on ui surface issues like this currently, and I'm not sure who is.

Routing to dfried@ for secondary UI.

 Issue 901615  has been merged into this issue.

This is a dialog we're considering re-engineering (and have been for some time). Currently, the cookies dialog works as follows:
 1. Parented to the main browser window
 2. Clipped by the main browser window
 3. Modal to the current tab (current tab is frozen until it's closed)
 4. Only visible when the current tab is active
 5. Closes if the current tab navigates

The real problem is (2) above - because it's not a separate, free-floating window, if the browser window is too small to hold it, the bottom gets cut off. This should only be an issue when the browser is smaller than about 650 DIP tall in a maximized browser window.

So the solution for people whose dialog is cut off is to make the browser window larger. If they're operating on a screen that's less than 675 DIP tall, then there is a potential problem, but my understanding is that screens smaller than 1024x768 DIPs probably aren't high priority for us to support.

That said, if PM/UX decide it's worth pursuing, we could probably shave some height off of the window to make it work in maximized browser windows that are 600 DIP tall (but would require a redesign of the Cookies dialog, with less vertical whitespace).

The alternative would be to create a whole new modality for dialogs just for this one, which has all the properties of a web contents-modal dialog but can float outside the current browser window. This also still wouldn't fix the problem of too-small screens cutting off the bottom of the dialog, though.

One thing we *can't* do is just add a close button to the top, since cutting off the buttons at the bottom effectively still makes the dialog unusable, and it's not clear what the correct behavior on clicking [X] would even be.

I'm bouncing this back to PM for triage with this additional information. Hopefully we can make a decision about what avenue to pursue.