Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) Reporter
	Description • 11 years ago

During the big move to APZC the scrollbars have been kept in the layout/ code as layers on top of the original scrollbars. Sadly this does not fit very well with zoomed content.

Also in order to have a floating keyboard the scrollbars needs to understand the overscrolled amount in order to not be drawn under the keyboard.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 1 • 10 years ago

I don't think this is a hard dependency for bug 970093, but it might be a good one to do. The only set of scrollbars that we care about given the current approach for bug 970093 are the root-level scrollbars for the content process; all the other scrollbars will stay the way they are. We could in theory adjust the root-level scrollbars to fit the shrunken composition bounds the same way we account for the async transform, at [1]. That would be a relatively small change although kind of hacky. Doing that would have one issue, which is that when the content process is not scrollable by default, we won't even have any scrollbars for it, even if the keyboard comes up and "makes it scrollable". I don't think most users will care about this so we might be able to get by without it, but yeah in the long term the correct fix is probably to move the scrollbars into the compositor.

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/composite/AsyncCompositionManager.cpp?rev=0ba56b8f5946#785

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 2 • 9 years ago

At some point we decided not to do this. Having layout be able to style the scrollbars is one of the key features that would be lost by doing this. The current approach works well enough and if we need to fix the outstanding issue where scrollbars appearing/disappearing can be delayed, we can do that by having the layers always be in the layer tree and do the opacity animation in the compositor.