Closed
Bug 775718
Opened 12 years ago
Closed 12 years ago
Story - Full scrollbars when using a mouse
Categories
(Tracking Graveyard :: Metro Operations, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: jimm, Assigned: rsilveira)
References
Details
(Whiteboard: [parity-ie] feature=story u=metro_firefox_user c=content_features p=8 status=verified)
Attachments
(3 files)
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.
Comment 1•12 years ago
|
||
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.
Reporter | ||
Comment 2•12 years ago
|
||
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.
Updated•12 years ago
|
Assignee: nobody → jonathan
Status: NEW → ASSIGNED
Comment 3•12 years ago
|
||
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.
Reporter | ||
Comment 5•12 years ago
|
||
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.
Comment 6•12 years ago
|
||
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.
Reporter | ||
Comment 7•12 years ago
|
||
Where do the "native anonymous scrollbars" come from? Are they part of the xul:box elements?
Comment 8•12 years ago
|
||
(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.
Reporter | ||
Comment 9•12 years ago
|
||
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?
Comment 10•12 years ago
|
||
(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.
Reporter | ||
Comment 11•12 years ago
|
||
(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?
Comment 12•12 years ago
|
||
(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?
Reporter | ||
Comment 13•12 years ago
|
||
(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.
Comment 14•12 years ago
|
||
(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.
Comment 15•12 years ago
|
||
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.
Assignee: hello → nobody
Status: ASSIGNED → NEW
Updated•12 years ago
|
Whiteboard: [metro-beta]
Reporter | ||
Updated•12 years ago
|
Product: Firefox → Firefox for Metro
Updated•12 years ago
|
Whiteboard: [metro-beta] → [metro-mvp]
Updated•12 years ago
|
Component: General → Input
Keywords: feature
Hardware: x86_64 → All
Summary: When interacting with the mouse, metrofx should display a mouse scrollbar on scrollable views → Display a mouse scrollbar on scrollable views when interacting with mouse
Updated•12 years ago
|
Whiteboard: [metro-mvp] → [metro-mvp] [LOE:1]
Updated•12 years ago
|
Priority: P2 → --
Comment 17•12 years ago
|
||
Updated•12 years ago
|
Blocks: 831565
Summary: Display a mouse scrollbar on scrollable views when interacting with mouse → Story - Full scrollbars when using a mouse
Whiteboard: [metro-mvp] [LOE:1] → feature=story u=metro_firefox_user c=content_features [metro-mvp] [LOE:1]
Updated•12 years ago
|
Priority: -- → P2
Updated•12 years ago
|
Updated•12 years ago
|
Priority: P2 → P3
Updated•12 years ago
|
Whiteboard: feature=story u=metro_firefox_user c=content_features p=0 → feature=story u=metro_firefox_user c=content_features p=0 status=backlog
Updated•12 years ago
|
Blocks: metrov1backlog
Whiteboard: feature=story u=metro_firefox_user c=content_features p=0 status=backlog → feature=story u=metro_firefox_user c=content_features p=0
Updated•12 years ago
|
Reporter | ||
Updated•12 years ago
|
Depends on: metro-omtc
Updated•12 years ago
|
Component: Input → Metro Operations
Product: Firefox for Metro → Tracking
Version: Trunk → ---
Comment 19•12 years ago
|
||
Matt can you provide a point value for this story?
Comment 20•12 years ago
|
||
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.
Whiteboard: feature=story u=metro_firefox_user c=content_features p=0 → feature=story u=metro_firefox_user c=content_features p=8
Reporter | ||
Updated•12 years ago
|
No longer depends on: metro-omtc
Updated•12 years ago
|
Priority: P3 → P4
Updated•12 years ago
|
Updated•12 years ago
|
Priority: P4 → P3
Comment 23•12 years ago
|
||
This would help with community testing efforts by making it easier to use Metro without touch hardware. Marking qawanted + dogfood.
Updated•12 years ago
|
Assignee: nobody → rsilveira
Status: NEW → ASSIGNED
QA Contact: jbecerra
Assignee | ||
Comment 24•12 years ago
|
||
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.
Attachment #757753 -
Flags: review?(mbrubeck)
Comment 25•12 years ago
|
||
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.
Attachment #757753 -
Flags: review?(mbrubeck) → review+
Comment 26•12 years ago
|
||
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?
Comment 27•12 years ago
|
||
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.
See Also: → 636564
Reporter | ||
Comment 28•12 years ago
|
||
(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.
Assignee | ||
Comment 29•12 years ago
|
||
(: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.
Assignee | ||
Comment 30•12 years ago
|
||
Comment 31•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 32•11 years ago
|
||
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?
Status: RESOLVED → VERIFIED
Flags: needinfo?(mmucci)
Flags: needinfo?(asa)
Whiteboard: [parity-ie] feature=story u=metro_firefox_user c=content_features p=8 → [parity-ie] feature=story u=metro_firefox_user c=content_features p=8 status=verified
Comment 33•11 years ago
|
||
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
Updated•11 years ago
|
Updated•11 years ago
|
Flags: needinfo?(mmucci)
Flags: needinfo?(asa)
Comment 34•11 years ago
|
||
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.
Updated•10 years ago
|
OS: Windows 8 Metro → Windows 8.1
Updated•6 years ago
|
Product: Tracking → Tracking Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•