When interacting with scrollable views using the mouse it is more intuitive to have a visible scrollbar present. Using the click-and-drag gesture seems odd, especially if you are switching between the desktop and metro interfaces. Note the metro UI does something similar for the tile interface - when mouse input is detected, a scroll bar is displayed at the bottom of the screen. When touch input is detected, the scroll bar fades out. We have access to native widgets for this if we want to use them. The same scroll bars you see in the current desktop build are rendered using the native widget library. CC'ing yuan and jwilde in case they've already come up with a solution for this and can add to the bug.

The existing scrolling code currently displays scrollbars by displaying xul:box elements, calculating the page scale, and then appropriately applying CSS transforms to the box elements. To implement this, I'm assuming we'd add xul:scrollbar elements to the window and then have the existing scrollbar code also update them. We'd use the MozPrecisePointer and MozImprecisePointer events to selectively hide the touch and mouse scrollbars. I'm wondering, though, if we could change up some of the browser XBL bindings and simplify all of this.

Here's ie's scrollbar for reference. It's a floating bar that hovers over content with transparency in the track. The style matches native widgets generally.

Turns out that we probably won't need to add another scrollbar component. The existing xul:box scrollbars appear to have been added to account for the scrolling that happened with the sidebar panels. The sidebars needed to be fluidly integrated with the existing scrolling paths. Since we don't have those scrollbars, we should be able to remove a bunch of CSS that was hiding those scrollbars by default, remove the custom xul:box scrollbars, and somehow restyle the scrollbars depending whether or not we're currently using the mouse.

http://mxr.mozilla.org/projects-central/source/elm/browser/metro/theme/content.css Not sure how we can swap the namespace based styles out on the fly. Johnathan, any ideas? We can access these style props programatically if we have to.

Strategy #1: We could have something like InputSourceHelper available from content so that there's a "touch" class attached to all of the scrollbars when touch input is used. Then, we can get rid of the custom scrollbars displayed in chrome and just use the native anonymous scrollbars. The one issue with this strategy is that anonymous scrollbars in content currently can't have CSS transitions or transparent backgrounds. However, there was a lot of work to deal with that over in bug 636564 that we could possibly use. Strategy #2: Add standard xul scrollbars in chrome, tag them into the main dragger (like with the current touch scrollbars), and just display then when we're using precise input. While it's probably a faster solution to implement over the near term, I'm not recommending this strategy because it'll make sites with `overflow:auto` blocks in the middle of the page (e.g. GitHub, Etherpad, Google Docs) really hard to use.

Where do the "native anonymous scrollbars" come from? Are they part of the xul:box elements?

(In reply to Jim Mathies [:jimm] from comment #7) > Where do the "native anonymous scrollbars" come from? Are they part of the > xul:box elements? Specifically, the ones that get injected in HTML content via nsHTMLScrollFrame. The ones associated with xul:box and nsXULScrollFrame with are fine, though. CSS transitions and transparent backgrounds worked on them in some of my early patches for scrollbars.

Do we have those currently in content or did the fennec folks figure out some way to get the custom ones inject in there? Or do we just not have scrollbars in content currently?

(In reply to Jim Mathies [:jimm] from comment #9) > Do we have those currently in content or did the fennec folks figure out > some way to get the custom ones inject in there? Or do we just not have > scrollbars in content currently? Currently, we don't have scrollbars in HTML content. The touch scrollbars are xul:box elements in chrome. They're resized with width/height in response to content height and shifted with CSS transforms. All of the logic for this is in main dragger in browser.js.

(In reply to Jonathan Wilde [:jwilde] from comment #10) > (In reply to Jim Mathies [:jimm] from comment #9) > > Do we have those currently in content or did the fennec folks figure out > > some way to get the custom ones inject in there? Or do we just not have > > scrollbars in content currently? > > Currently, we don't have scrollbars in HTML content. > > The touch scrollbars are xul:box elements in chrome. They're resized with > width/height in response to content height and shifted with CSS transforms. > All of the logic for this is in main dragger in browser.js. Ah, so from your two strategies - #1 involves turning on the anonymous scroll bars (which can't be styled without bug 636564 getting fixed) for content. Can we keep the custom scroll bar for the main view or do we need to turn them on for everything?

(In reply to Jim Mathies [:jimm] from comment #11) > (In reply to Jonathan Wilde [:jwilde] from comment #10) > > (In reply to Jim Mathies [:jimm] from comment #9) > > > Do we have those currently in content or did the fennec folks figure out > > > some way to get the custom ones inject in there? Or do we just not have > > > scrollbars in content currently? > > > > Currently, we don't have scrollbars in HTML content. > > > > The touch scrollbars are xul:box elements in chrome. They're resized with > > width/height in response to content height and shifted with CSS transforms. > > All of the logic for this is in main dragger in browser.js. > > Ah, so from your two strategies - #1 involves turning on the anonymous > scroll bars (which can't be styled without bug 636564 getting fixed) for > content. Can we keep the custom scroll bar for the main view or do we need > to turn them on for everything? Yup. We can keep the existing custom ones in chrome for touch input and then just enable native mouse scrollbars iff the user is using a mouse with a little message passing and XBL. Arguably, this is better than enabling them everywhere, because iirc we don't 100% support touch scrolling on internal scrolling blocks in HTML atm. Or am I wrong about this?

(In reply to Jonathan Wilde [:jwilde] from comment #12) > Yup. We can keep the existing custom ones in chrome for touch input and then > just enable native mouse scrollbars iff the user is using a mouse with a > little message passing and XBL. > > Arguably, this is better than enabling them everywhere, because iirc we > don't 100% support touch scrolling on internal scrolling blocks in HTML atm. > Or am I wrong about this? If we ditched the custom scroller would apis in interfaces like nsIDOMWindowUtils then know about our root scroll frame and deal with it appropriately? I get the impression nsIDOMWindowUtils knows nothing about our custom scroller because I see us adjusting coordinates manually in ui code ralted to scoll position. I'm not 100% sure I understand how scrolling normally works though.

(In reply to Jim Mathies [:jimm] from comment #13) > (In reply to Jonathan Wilde [:jwilde] from comment #12) > > Yup. We can keep the existing custom ones in chrome for touch input and then > > just enable native mouse scrollbars iff the user is using a mouse with a > > little message passing and XBL. > > > > Arguably, this is better than enabling them everywhere, because iirc we > > don't 100% support touch scrolling on internal scrolling blocks in HTML atm. > > Or am I wrong about this? > > If we ditched the custom scroller would apis in interfaces like > nsIDOMWindowUtils then know about our root scroll frame and deal with it > appropriately? Yes. > I get the impression nsIDOMWindowUtils knows nothing about > our custom scroller because I see us adjusting coordinates manually in ui > code ralted to scoll position. I'm not 100% sure I understand how scrolling > normally works though. That's correct. The custom touch scroller actually takes advantage of the fact it doesn't get shown when the user isn't explicitly panning. It doesn't try to sync up until you actually start dragging.

This bug potentially should be merged with bug 777610. That bug contains a starting point for supporting this and touch scrollbars as separate styles of the same native scrollbars, along with tasks that need to be completed prior to landing.

Matt can you provide a point value for this story?

Conservatively estimating 8 points because of unknowns; fortunately it looks like the platform dependency bug 636564 is making progress so we should have better knowledge soon.

This would help with community testing efforts by making it easier to use Metro without touch hardware. Marking qawanted + dogfood.

Fixed by setting CSS overflow property to scroll when input is mouse. Works on start screen and content pages. Some notes: - I tried fading the scroll bars, but couldn't because of bug 77790. - I'm uncomfortable with the way I added the margin to #start-scrollbox (the calc() call), but didn't want to mess with too many other things. - I didn't add the scroll bars to the start page on snapped view, it's changing design and right now there is no need to scroll.

Comment on attachment 757753 [details] [diff] [review] Patch v1 Review of attachment 757753 [details] [diff] [review]: ----------------------------------------------------------------- Well, that was simpler than I thought. I think it needs some polish (e.g. the vertical scrollbar runs into the "New Tab" overlay button), but let's land the basics and iterate from there.

Comment on attachment 757753 [details] [diff] [review] Patch v1 Review of attachment 757753 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/metro/theme/content.css @@ -14,5 @@ > > -/* Style the scrollbars */ > -html xul|scrollbar { > - display: none; > -} Maybe we can keep these rules around but move them to base/content/cursor.css?

By the way, I think in the long term we want scrollbars that hover over the content and are mostly transparent, as in "native" Metro apps. This would lets us avoid reflowing when switching input types. Perhaps the work in bug 636564 would be useful for this.

(In reply to Matt Brubeck (:mbrubeck) from comment #27) > By the way, I think in the long term we want scrollbars that hover over the > content and are mostly transparent, as in "native" Metro apps. This would > lets us avoid reflowing when switching input types. Perhaps the work in bug > 636564 would be useful for this. I think that was the goal for v1, hence why we blocked on that osx scrollbar work. We might want to run this past Asa to see how he feels about it.

(:mbrubeck) from comment #27) > By the way, I think in the long term we want scrollbars that hover over the > content and are mostly transparent, as in "native" Metro apps. This would > lets us avoid reflowing when switching input types. Perhaps the work in bug > 636564 would be useful for this. As per IRC talk, opened Bug 879565 to track making the scrollbars more metro-y. I'll land this patch so that it's at least more usable with a mouse.

Tested on 2013-06-14 using the latest nightly. - I used the story in comment #17 to verify this story. I tried several scenarios, scrolling using the mouse and scrollbar, using the touch surface of the mouse I have to scroll, scrolling by dragging on the touch screen, dismissing the scrollbar by tapping on the content area, showing the scroll bar by moving again the mouse, dismissing the scrollbar by swiping up to bring up the navigation bar. All of this seems consistent. I have to questions: - Should the scrollbar be dismissed by bringing up the options flyout? - Should anything be done about the interaction that occurs when the scrollbar is small enough, due to a long page, that it fits within the "big +" overlay on the right hand side of the page, which makes the scrollbar unreachable once you depress the mouse button?

Tested this for iteration 9. It works for me for latest nightly from ftp://ftp.mozilla.org/pub/firefox/nightly/2013-07-01-mozilla-central-debug

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:26.0) Gecko/20100101 Firefox/26.0 Build ID: 20130812030209 Built from http://hg.mozilla.org/mozilla-central/rev/87c1796bc46c WFM Tested on windows 8 using latest nightly for iteration-11. Followed steps provided in user story and got expected result.