Just to clarify, this bug is about having scrollbars you can drag with your fingers to scroll the page? If so I think this is a WONTFIX.
If this bug is just about scroll indicators that show where you are on the page but that you can't actually drag, then yes, i think this is something we should add to the compositor as we want it on other platforms as well.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)
> If this bug is just about scroll indicators that show where you are on the
> page but that you can't actually drag, then yes, i think this is something
> we should add to the compositor as we want it on other platforms as well.
correct. we've had thin line scroll indicators for a while through the fennec front end code. When we turned apz on they went away. I think the front end would like the ability to style these if possible.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> I've noticed that in subframes (like scrollable divs) there are scrollbars.
> I'm not sure why they show up there but not in the main content.
Actually that's a bug, we turn the standard mouse scrollbars off in content when the user is interacting with touch. Back when we handled scrolling in the front end, we drew our own touch scroll indicators (a slim line on the right of the view representing position). Those stopped working once we switched to apz. We can probably get them going again by listening to scroll messages.
Widget scrollbars in subframes should also be hidden by the front end css changes we make. If they are showing up, we should file a bug on getting rid of them.

I don't think this blocks uplift. Also not sure we should block on this at all.
Do we want touch scrollbars in content? If so can we do this in front end or will we need to support this down in platform?

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #7)
> Note that bug 814435 is implementing scroll indicators for B2G and we should
> end up getting it for free in Metro too (whether we want it or not)
That's sounds great, although, I'm wondering what these look like. Is there any way to control the styling?

In theory the new approach that I'm using on that bug should allow styling via CSS in "the usual manner". Right now with those patches though I'm not seeing any scrollbars on Metro. Trying to figure out what's going on.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9)
> In theory the new approach that I'm using on that bug should allow styling
> via CSS in "the usual manner". Right now with those patches though I'm not
> seeing any scrollbars on Metro. Trying to figure out what's going on.
We deliberately hide the scrollbars on Metro while in "imprecise" (touch) input mode: bug 934811.

Created attachment 8348136[details][diff][review]
WIP
FWIW this is what I had a week ago when I last looked at this bug. I copied the scrollbar styling from B2G and put them in cursor.css so that they would only get applied in imprecise mode. However the problem I was seeing was that when switching between precise and imprecise mode the scrollbars wouldn't always update correctly. I often had to wait for the scrollbars to fade out and only after they reappeared would be they be correct. I added the green background-color on the body to verify that cursor.css was getting picked up correctly (it was) but it's just the scrollbar styles that seem to not get updated.
This seems like mostly front-end work at this point, and I'm going to be busy with B2G work so somebody else should probably pick this up.