Bug 1724358 Comment 12 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 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 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.

Some additional background what I've naively understood are; if iframe's document element has 'overflow: clip` it's not a scroll container since the clipped area can't be reachable at all. Also I did intentionally ignore `overflow: hidden` cases here, actually the overflowed area can be reachable by JS APIs, but I assume most of web developers don't differentiate overflow:hidden and overflow:clip so probably it doesn't much matter at this moment.  To be exact, we should respect overscroll-behavior properties in `overflow:hidden` cases, but I haven't checked the behavior in the cases yet.
(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 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.

Some additional background what I've naively understood are; if iframe's document element has `overflow: clip` it's not a scroll container since the clipped area can't be reachable at all. Also I did intentionally ignore `overflow: hidden` cases here, actually the overflowed area can be reachable by JS APIs, but I assume most of web developers don't differentiate overflow:hidden and overflow:clip so probably it doesn't much matter at this moment.  To be exact, we should respect overscroll-behavior properties in `overflow:hidden` cases, but I haven't checked the behavior in the cases yet.

Back to Bug 1724358 Comment 12