(In reply to Hiroyuki Ikezoe (:hiro) from comment #12) > (In reply to Botond Ballo [:botond] from comment #10) > > (In reply to Hiroyuki Ikezoe (:hiro) from comment #6) > > > Okay, in Fission we have APZCs (for iframes) which are not scrollable, thus we'd need to tweak [Axis::OverscrollBehaviorAllowsHandoff](https://searchfox.org/mozilla-central/rev/162a8620f126c27de70766808708696260f2256a/gfx/layers/apz/src/Axis.cpp#466) to allow scroll handoff in the case where the APZC is not scrollable. > > > > > > Note that [overscroll-behavior properties are only applied to scroll container](https://drafts.csswg.org/css-overscroll-1/#propdef-overscroll-behavior), so it's the right thing to do. > > > > I'm a bit confused by this. Since an iframe is a document, isn't its viewport always a scroll container, even if it has no scroll range? > > I am assuming the situation is only applicable to the top level document? I mean the `viewport` means the _visual_ viewport, isn't it? I don't think the distinction between visual and layout viewport is meaningful for iframes. (Though, to be honest, I'm also not sure if the spec has adopted the same usage of these terms as Gecko.) Anyways, my understanding is that a "scroll container" corresponds more or less to an `nsIScrollableFrame` in Gecko, and since all iframes have a root scroll frame, therefore all iframes have a scroll container. At the least this hould be the case for iframes whose <html> element has `overflow: scroll` or `overflow: hidden` in some direction (as in the page in comment 0, where the iframe has `overflow-y: scroll`). (The last paragraph of https://drafts.csswg.org/css-overflow-3/#overflow-propagation, which says: > If `visible` is applied to the viewport, it must be interpreted as `auto`. If `clip` is applied to the viewport, it must be interpreted as `hidden`. makes me think the iframe has a scroll container even in the `clip` and `visible` cases, though it's possible I'm missing something.) > I am not 100% sure but given that Chrome doesn't respect overscroll-behavior in the case in comment 0, it's reasonable and actually it would be intuitive for web developers I think. It may be helpful to understand the logic behind Chrome's behaviour, so it can help guide our behaviour here. (For example, is the logic that we should only apply `overscroll-behavior` to scroll containers which have an non-zero scroll range? That would settle the question of what to do with `overflow: hidden`.)
Bug 1724358 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #12) > (In reply to Botond Ballo [:botond] from comment #10) > > (In reply to Hiroyuki Ikezoe (:hiro) from comment #6) > > > Okay, in Fission we have APZCs (for iframes) which are not scrollable, thus we'd need to tweak [Axis::OverscrollBehaviorAllowsHandoff](https://searchfox.org/mozilla-central/rev/162a8620f126c27de70766808708696260f2256a/gfx/layers/apz/src/Axis.cpp#466) to allow scroll handoff in the case where the APZC is not scrollable. > > > > > > Note that [overscroll-behavior properties are only applied to scroll container](https://drafts.csswg.org/css-overscroll-1/#propdef-overscroll-behavior), so it's the right thing to do. > > > > I'm a bit confused by this. Since an iframe is a document, isn't its viewport always a scroll container, even if it has no scroll range? > > I am assuming the situation is only applicable to the top level document? I mean the `viewport` means the _visual_ viewport, isn't it? I don't think the distinction between visual and layout viewport is meaningful for iframes. (Though, to be honest, I'm also not sure if the spec has adopted the same usage of these terms as Gecko.) Anyways, my understanding is that a "scroll container" corresponds more or less to an `nsIScrollableFrame` in Gecko, and since all iframes have a root scroll frame, therefore all iframes have a scroll container. At the least this hould be the case for iframes whose <html> element has `overflow: scroll` or `overflow: hidden` in some direction (as in the page in comment 0, where the iframe has `overflow-y: scroll`). (The last paragraph of https://drafts.csswg.org/css-overflow-3/#overflow-propagation, which says: > If `visible` is applied to the viewport, it must be interpreted as `auto`. If `clip` is applied to the viewport, it must be interpreted as `hidden`. makes me think the iframe has a scroll container even in the `clip` and `visible` cases, though it's possible I'm missing something.) > I am not 100% sure but given that Chrome doesn't respect overscroll-behavior in the case in comment 0, it's reasonable and actually it would be intuitive for web developers I think. It may be helpful to understand the logic behind Chrome's behaviour, so it can help guide our behaviour here. (For example, is the logic that we should only apply `overscroll-behavior` to scroll containers which have a non-zero scroll range? That would settle the question of what to do with `overflow: hidden`.)