Right now, css-overflow-3 section 2.2 says a scroll container's end-side padding is "optionally" scrollable:

The scrollable overflow region is the union of: [...] Optionally, additional padding on the end-edge sides, corresponding to the end-side padding of the scroll container"
https://www.w3.org/TR/css-overflow-3/#scrollable

We don't include this padding, but Chrome does (though only in the block axis).

https://github.com/w3c/csswg-drafts/issues/129 is resolved on coming up with something more concrete for this, spec-wise.

In the meantime, I'm filing this as a placeholder bug to implement this once we've got something to implement. Note that we do run into interop/webcompat issues due to this behavior difference, as documented in discussion/webcompat-see-also-links on https://bugzilla.mozilla.org/show_bug.cgi?id=748518 (which will hopefully become addressed when this is specced & implemented here).

Actually, per https://github.com/w3c/csswg-drafts/issues/3665 , it seems like CSSWG is going to resolve to always include block-end and inline-end padding, specifically for grid and flex containers.

Daniel, do you know what the status is for containers other than grid/flex?

I think https://github.com/w3c/csswg-drafts/issues/129#issuecomment-417525242 is still the latest info from the CSSWG on plans for non-grid/flex containers:

the align-content and justify-content properties will now have this side-effect: any non-normal value will cause the padding to be honored
[...]
this issue remains open to see what we can do to fix this in the default case (which is constrained by Web-compat). I suspect we might be able to make it work in the block axis, but not the inline one.

I'm planning to use this bug to add block-end padding to block frame because bug 748518 becomes a collection of duplicate bugs, and some of the bugs may need extra handling such as bug 1696885 (bottom padding missing on <textarea>).

For webcompat, we only add block container's inline padding to its inline
lines, but not its block lines.

Since we've already included the necessary padding in either axis in
scrolled inner frame's overflow area, we have to delete the code in
ReflowScrolledFrame() which inflates the inner frame's overflow area
again with its padding [1]. It's undesired now because it recomputes
mHelper.mScrolledFrame's overflow areas by using
nsLayoutUtils::UnionChildOverflow(), which ignores special overflow area
the block frame may compute. We should just use the correct overflow
area returned via aMetrics->mOverflowAreas.

[1] I think this is needed for <textarea> and <input> that have
overflow-clip-box:content-box in their inline-axis in forms.css, in
order to add inline padding to avoid clip the content.

Depends on D108890

A quick summarize on what we need to do in order to be compatible with blink and webit regarding the end padding in scrollable block frames

According this table and wpt test overflow-padding.html, we need to consider the following when computing a block frame's overflow area:

1. always add block container's block-end padding. That is, add block-end padding for both inline lines and block lines (fixed in Part 1)
2. add block container's inline-end padding only for inline lines, but not block lines. (fixed in Part 2)

Comment on attachment 9210867 [details]
Bug 1527949 Part 2 - Include the block container's inline-end padding for inline lines when computing its overflow area.

Revision D109424 was moved to bug 1700858. Setting attachment 9210867 [details] to obsolete.

Morph this bug again for making block-end padding scrollable. See Bug 1700858 for inline-end padding.

https://hg.mozilla.org/mozilla-central/rev/119e56b961ab