(In reply to Boris Chiou [:boris] from comment #1) > Explanation from hiro: in my understanding generating nsIScrollableFrame matches scroll container in the spec, so for overflow-x:clip;overflow-y:scroll will generate it, but yeah, in such cases we don't return null for x-axis timeline, that's what I meant. Note: it's impossible to have a scroller with `overflow-x:clip;overflow-y:scroll`. In this case, `overflow-y:scroll` will be converted into `overflow-y:hidden`, based on the spec [1] ([gecko code](https://searchfox.org/mozilla-central/rev/c12a59323ee46b29b90c9917a3a7a70ea714ffec/servo/components/style/style_adjuster.rs#415-432)): > as specified, except with visible/clip computing to auto/hidden (respectively) if one of overflow-x or overflow-y is neither visible nor clip Besides, if the scroller is not a scroll container, we don't create the scroll frame because we check `IsScrollableOverflow()` when building a scroll frame in `nsCSSFrameConstructor`. So I think our current code should be OK. The only exception is the root scroll frame. It seem we generate the root scroll frame always, so setting `overflow:clip` for html element still generate the root scroll frame. Therefore, this bug doesn't have to do anything on Gecko. Perhaps adding a test is enough. [1] https://drafts.csswg.org/css-overflow-3/#scroll-container
Bug 1746094 Comment 2 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 Boris Chiou [:boris] from comment #1) > Explanation from hiro: in my understanding generating nsIScrollableFrame matches scroll container in the spec, so for overflow-x:clip;overflow-y:scroll will generate it, but yeah, in such cases we don't return null for x-axis timeline, that's what I meant. Note: it's impossible to have a scroller with `overflow-x:clip;overflow-y:scroll`. In this case, `overflow-y:clip` will be converted into `overflow-y:hidden`, based on the spec [1] ([gecko code](https://searchfox.org/mozilla-central/rev/c12a59323ee46b29b90c9917a3a7a70ea714ffec/servo/components/style/style_adjuster.rs#415-432)): > as specified, except with visible/clip computing to auto/hidden (respectively) if one of overflow-x or overflow-y is neither visible nor clip Besides, if the scroller is not a scroll container, we don't create the scroll frame because we check `IsScrollableOverflow()` when building a scroll frame in `nsCSSFrameConstructor`. So I think our current code should be OK. The only exception is the root scroll frame. It seem we generate the root scroll frame always, so setting `overflow:clip` for html element still generate the root scroll frame. Therefore, this bug doesn't have to do anything on Gecko. Perhaps adding a test is enough. [1] https://drafts.csswg.org/css-overflow-3/#scroll-container