isn't this the fault of overlay scrolling?

fwiw: we've been kicking around the idea of making this a subpage rather than a dialog.  we just haven't pulled the trigger yet.  some technical limitations around clearing browser data have changed recently.

This is bad :-/ We were concerned that this could happen and designed the dialog height to accommodate exactly 4 and half checkboxes, so that it's very obvious that you need to scroll.

Apparently some element sizes have changed in the meantime in exactly the worst possible manner.

dbeam@, are you working on this? Or I can fix it and this time with a browsertest to catch the regression. IIRC that email thread did not end supportive towards a subpage, so I wouldn't wait for that.

msramek@: remember, this in on Mac where all scrollbars are less visible ("overlay scrolling").  you can still get to this content.

msramek@: one thing we haven't implemented yet is the subtle lines or shadows at the top and bottom of this dialog to understand there's more content when there's a shadow.  see paper-dialog-scrollable[1] for an example.  it's fairly subtle, though.  we could probably force overflow-y: scroll or something (that might make a scrollbar show at all times).

[1] https://elements.polymer-project.org/elements/paper-dialog-scrollable?view=demo:demo/index.html&active=paper-dialog-scrollable

Why not just go with the original plan of showing 4.5 checkboxes?

oh, sorry, I missed the "and half" part of "exactly 4 and half".

I'm fine with that for this case, but I'd like to be in a better position than "we have to make all our lists (which there are a bajillion of in settings) show part of an item".  that seems like a brittle and overly laborious solution.

dbeam@: Thanks for that link, I understand now. There should normally be a border appearing on the top and/or bottom to indicate whether we can scroll, but that's not applicable here since the scrolling area actually has full-width borders on both sides to separate the header and footer. The shadows sound like a good idea to deal with it.

In the meantime, I think a one-off solution is fine for this particular case - I agree that this doesn't scale, but CBD is really sensitive, especially with things like passwords below the fold.

shrike@: What do you think about forcing the visibility of the scrollbar on Mac? Would it look weird to a user who is used to overlay scrolling?

https://codereview.chromium.org/2403833002/ increases the height by 10px.

Deleted: dialog-before.png 40.8 KB

	dialog-before.png 40.8 KB View Download

Deleted: dialog-after.png 43.8 KB

	dialog-after.png 43.8 KB View Download

> shrike@: What do you think about forcing the visibility of the scrollbar on Mac? Would it look weird to a user who is used to overlay scrolling?

I think it would look like the dialog is broken, because when overlay scrollbars are the default they never appear all the time.

Ok, then let's just go with the height change for now.

msramek@: does overflow-y: scroll; even get respected when overlay scrolling is on?  (as in: by default on Mac OS X?)

dbeam@: No actually :-) Straightforwardly applying it on paper-dialog-scrollable or the body element inside it doesn't work.

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

commit ae25baeb7a5af9dad6ae2f8ad050d5564301d30d
Author: msramek <msramek@chromium.org>
Date: Tue Oct 11 10:28:46 2016

Slightly increase the size of the CBD dialog body to hint at scrolling

When opened in a small browser window, the CBD dialog is set to a size
in which 4 checkboxes are visible*, and the remaining 4 are below the
fold and need to be scrolled to.

[*]the label of the 5th is slightly visible if checked

While the scrollbar is usually visible, this is not the case on Mac
(where it's only visible while scrolling is in progress). Other visual
cues for scrolling are not applicable - the top and bottom border of
paper-dialog-scrollable are not visible because the dialog body has its
own borders, and shadows are not yet implemented.

As discussed in the linked bug, until a general solution is applied to
all such MD scrolling dialogs, we need a one-off solution for this case
as it's particularly sensitive. This CL increases the size of the dialog
body to hold 4.5 checkboxes, so the need to scroll is obvious. Note that
this was also the original design; this CL fixes a regression.

BUG= 652027 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/ae25baeb7a5af9dad6ae2f8ad050d5564301d30d/chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html

i don't think this approach ^ will be feasible for arbitrary length lists with arbitrary sized entries.

i also don't think the dialog looks good (in general) right now, so I've filed  bug 654812 

As I mentioned in #8, this approach is not at all intended to work for arbitrary cases. It's just supposed to decrease the chance of people accidentally deleting their passwords in this particular situation. That is absolutely necessary to fix right now, regardless of whether we have a more general solution planned.

Since this landed shortly after the 55 branchpoint, I'd like to ask for merge. I was just waiting for it to pass through Canary; it's just a local CSS change, so there are no side effects.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

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

commit 1d67536fa92ec902dc3cbc715abce8306f2e8f3d
Author: Martin Sramek <msramek@chromium.org>
Date: Mon Oct 17 15:33:05 2016

Slightly increase the size of the CBD dialog body to hint at scrolling

When opened in a small browser window, the CBD dialog is set to a size
in which 4 checkboxes are visible*, and the remaining 4 are below the
fold and need to be scrolled to.

[*]the label of the 5th is slightly visible if checked

While the scrollbar is usually visible, this is not the case on Mac
(where it's only visible while scrolling is in progress). Other visual
cues for scrolling are not applicable - the top and bottom border of
paper-dialog-scrollable are not visible because the dialog body has its
own borders, and shadows are not yet implemented.

As discussed in the linked bug, until a general solution is applied to
all such MD scrolling dialogs, we need a one-off solution for this case
as it's particularly sensitive. This CL increases the size of the dialog
body to hold 4.5 checkboxes, so the need to scroll is obvious. Note that
this was also the original design; this CL fixes a regression.

BUG= 652027 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2403833002
Cr-Commit-Position: refs/heads/master@{#424400}
(cherry picked from commit ae25baeb7a5af9dad6ae2f8ad050d5564301d30d)

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

Cr-Commit-Position: refs/branch-heads/2883@{#150}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/1d67536fa92ec902dc3cbc715abce8306f2e8f3d/chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html

fyi: md-settings is not released yet so there's no reason for merges

Tested the same on mac 10.11.6 chrome version 55.0.2883.18 - Clicking on clear browsing data - Dialog appears with 4.5 checkboxes as shown in the screenshot

Fix works as expected

Deleted: Screen Shot 2016-10-18 at 12.15.47 PM.png 192 KB

	Screen Shot 2016-10-18 at 12.15.47 PM.png 192 KB View Download

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

commit 1d67536fa92ec902dc3cbc715abce8306f2e8f3d
Author: Martin Sramek <msramek@chromium.org>
Date: Mon Oct 17 15:33:05 2016

Slightly increase the size of the CBD dialog body to hint at scrolling

When opened in a small browser window, the CBD dialog is set to a size
in which 4 checkboxes are visible*, and the remaining 4 are below the
fold and need to be scrolled to.

[*]the label of the 5th is slightly visible if checked

While the scrollbar is usually visible, this is not the case on Mac
(where it's only visible while scrolling is in progress). Other visual
cues for scrolling are not applicable - the top and bottom border of
paper-dialog-scrollable are not visible because the dialog body has its
own borders, and shadows are not yet implemented.

As discussed in the linked bug, until a general solution is applied to
all such MD scrolling dialogs, we need a one-off solution for this case
as it's particularly sensitive. This CL increases the size of the dialog
body to hold 4.5 checkboxes, so the need to scroll is obvious. Note that
this was also the original design; this CL fixes a regression.

BUG= 652027 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2403833002
Cr-Commit-Position: refs/heads/master@{#424400}
(cherry picked from commit ae25baeb7a5af9dad6ae2f8ad050d5564301d30d)

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

Cr-Commit-Position: refs/branch-heads/2883@{#150}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/1d67536fa92ec902dc3cbc715abce8306f2e8f3d/chrome/browser/resources/settings/clear_browsing_data_dialog/clear_browsing_data_dialog.html

[Automated comment] removing mislabelled merge-merged-2840