Closed Bug 549446 Opened 16 years ago Closed 8 years ago

Possibility to hide browser's scrollbars

Categories

(Core :: Layout, enhancement)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: Felipe, Unassigned)

References

(Blocks 1 open bug)

Details

Per limi's suggestion, it would be nice to have the option to hide the scrollbars for users of small screens, such as netbooks and touchscreen devices, or even when running the browser in a small window. I don't know if there's already a method in place to do this. There's overflow: -moz-scrollbars-none, but this disables the scrolling too. I believe that the scrolling/scrollbars makes assumptions about each other, so I don't know how feasible would be to do this, but I'm creating this bug to check.
We'd still want to render indicators when you move the page (or even all the time) similar to how Safari on the iPhone does it.
Hmm. Shouldn't overflow:hidden make things scrollable? It doesn't seem to over here... If not, how does it differ from OVERFLOW_CLIP? Do we just need a -moz overflow value for "hide the scrollbars but allow scrolling"?
overflow:hidden elements are scrollable via script but not via the UI (e.g., keys) --- I don't think we could make keys or mouse-scroll scroll overflow:hidden elements without regressing the Web. I think we need a new overflow value here which behaves just like overflow:auto UI-wise except that scrollbars are always hidden.
This would require changes to nsGfxScrollFrame, but is probably not hard to do. It could be implemented by adding an attribute to iframe/browser elements and reading it from HandleScrollPref in nsGfxScrollFrame. We'd need a new value in nsIScrollable.
This could also be useful in full-screen mode.
Yes, this should apply in fullscreen mode too.
I think the scroll bar should be smaller or transparent or both until hovered over. Firefox 4's focus is on regaining vertical space. The biggest space loss vertically, the scroll bar is still there.
(In reply to comment #6) > Yes, this should apply in fullscreen mode too. My plan for fullscreen mode is that the scrollbar will just be hidden by default by setting overflow:hidden on the root element in a UA style sheet, but authors can turn it on via CSS if they want to. Fennec has special UI for scrolling that uses a temporary scroll indicator. Do we just want to make that available for desktop Firefox builds?
(In reply to comment #8) > My plan for fullscreen mode is that the scrollbar will just be hidden by > default by setting overflow:hidden on the root element in a UA style sheet, > but authors can turn it on via CSS if they want to. what about the problem that overflow:hidden elements are not scrollable through UI? > Fennec has special UI for scrolling that uses a temporary scroll indicator. > Do we just want to make that available for desktop Firefox builds? Yeah, how is this set-up for Fennec? what would I need to do to make this available for Firefox builds?
If we could centralise the code across build platforms (mobile and desktop), that seems like it'd be the best option in the long run.
(In reply to comment #9) > (In reply to comment #8) > > My plan for fullscreen mode is that the scrollbar will just be hidden by > > default by setting overflow:hidden on the root element in a UA style sheet, > > but authors can turn it on via CSS if they want to. > > what about the problem that overflow:hidden elements are not scrollable > through UI? Ah sorry, my explanation was incomplete. The UA rule is set up so that if a particular element like a video or canvas is made fullscreen, we hide the scrollbar, but if the document itself is made fullscreen (which includes all manual activation of fullscreen via F11), we do not hide the scrollbar. If you want the fullscreen scrollbar (when not hidden) to be displayed differently, via a temporary indicator, we can still do that, on top of the previous paragraph. > > Fennec has special UI for scrolling that uses a temporary scroll indicator. > > Do we just want to make that available for desktop Firefox builds? > > Yeah, how is this set-up for Fennec? what would I need to do to make this > available for Firefox builds? Ask stechz :-)
> Yeah, how is this set-up for Fennec? what would I need to do to make this > available for Firefox builds? Vivien wrote the scrollbar code, CCing him. We have a lot of custom scrolling code. In particular, all of our scrolling goes through an object that handles scrolling the browser element and a couple of scrollboxes. For scrollbars, we update a transform on a very simple element whenever a scroll occurs. See: http://mxr.mozilla.org/mozilla-central/source/mobile/chrome/content/browser.js#1384 We determine what to scroll based on the position of the touch (or mouse), going outwards if that scrollable area cannot be further scrolled in that direction. I'm not sure if there's much value yet in unifying our code here, as our scrollbar UI is still evolving. If we go this route, I'd suggest something lower level that suits a wide variety of uses.
> Yeah, how is this set-up for Fennec? what would I need to do to make this > available for Firefox builds? Fennec has 2 differents ways to handle scrollbars: * Scrollbar for the main contentarea, the one that display the web page. This one are just elements positioned dynamically while moving with a MozTransform as stechz points out in the previous comment. * Chrome scrolbars, the scrollbars of the main interface. Those one are real scrollbars, sharing the code of nsGfxScrollFrame but using a custom style describe here: http://mxr.mozilla.org/mozilla-central/source/mobile/chrome/content/content.css#60 Basically the scrollbars are set to display: block with an opacity of 0 and when panning happens we set the "panning" attribute to true which makes the scrollars visible (http://mxr.mozilla.org/mozilla-central/source/mobile/chrome/content/content.css#101) Those has also a special code path to live above the content: - http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#1980 - http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#2057
Basically what needs to happen to turn off scrollbars for just the root content scrollable, something would need to call presShell::SetIgnoreViewportScrolling(true) [1] for content's root presshell, and then we would need to ensure that PAINT_DOCUMENT_RELATIVE was *not* passed to nsLayoutUtils::PaintFrame(). (Only drawWindow() does that currently.) This is pretty hand-wavy, and I'm sure lots of stuff would break, but hopefully this helps. [1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsIPresShell.h#1113 [2] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#1491
Want to draw fresh attention to this issue. Scrollbar hiding is a popular feature of webkit, and its absence in Mozilla is unnecessary – pointlessly adding to the headache of making performance websites cross-platform. Please, for the love of God, fix this.
A website can trivially turn off scrollbars by just styling "html { overflow: hidden; }", no? This bug is about letting the _user_ turn off scrollbars on websites.
Why is there so much resistance to this design bug and applies to both xul:iframe and html:iframe elements. ??? There is a need to suppress iframe scrollbars but still allow scrolling on touch screen devices (UI) as is apparent in Firefox for Android. It looks like there 3 possible approaches a) a new iframe attribute eg scrollbars="no" b) use an iframe style property to hide the scrollbars but allow scrolling eg overflow:-moz-scrollbars-none c) provide a pseudo style selector eg iframe:scrollbar {display:none} Please fix !
BTW With the implementation of bug #943249 it is now virtually impossible to provide a simple method of suppressing scrollbars without complex document processing ... which is particularly annoying as the scrolling="no" attribute does not work for xul:iframe elements It just seems impossible to implement touch screen interfaces without window based scrolling behaviour being inherited Any body know of any workarounds ????? Thanks
Romain, this is a perennial, would you ask the product team to have a look and prioritize or wontfix?
Severity: normal → enhancement
Flags: needinfo?(rtestard)
Given comment 18 and the fact this is not a product priority at the moment I'm won't fixing it.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(rtestard)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.