There may be a more general problem here where all Harmony dialogs' "content areas" need to get a scrollbar if their content exceeds the allocated height.

Some dialogs (e.g. JS alerts) are specced as being limited to a particular height, while others (like this one) are not, but even in the latter case, there will be instances where the screen resolution is low, or the window is placed low on the screen, or for some other reason the total window height gets clamped.  This implies we shouldn't just one-off fix this for "dialogs likely to be tall", we should fix it in a common way across all Harmony dialogs.

So, probably, all Harmony dialogs need a structure like:
[ Title area ]
[ Scroll view that parents all content ]
[ Bottom set of buttons ]

I thought DialogDelegate/DialogClientView/something already provided a structure like this, but it's been a long time since I've worked with them and I didn't see anything about scrolling in either one, so it's not immediately clear to me what we need to add where.

Allen, I'm kicking this to you to investigate, since it's more in the nature of "broader architecture/delegate question".

The CollectedCookiesDialog is a little more complicated than many of the other DialogDelegateView implementations. The main client area has several sections which interact; the upper tabbed area which has two listview/treeview "tabs" and associated buttons. The lower pane show the information. It is this lower section which should be scrolled independently rather than the whole top-level client area.

The solution would be to use a ScrollView class to wrap the lower pane into a scrollable area.

SGTM

I'm trying to figure out under what circumstances this will happen. The CookieInfoView() is sized to include all labels. As of right now, this is how it looks.

Deleted: CollectedCookiesViewMD.png 21.2 KB

	CollectedCookiesViewMD.png 21.2 KB View Download

It sounds from comment 2 like we're scoping this as being about this specific dialog, and while there may be a few other specific dialogs that also want to be scrollable, the solutions should be per-dialog and not global.

Given that, should this be duped against bug 610428, the general bug on this dialog?