In Mozilla 'scrolling=no' or 'overflow:hidden' not only hides the scrollbars but also disables scrolling I would also expect overflow:hidden to hide scrollbars but still allow scrolling (by keyboard). I would expect to use scrolling=no if scrolling was to be completely disabled.? Is this correct? IE still allows scrolling even if scrollbars are hidden ( and so once did Mozilla) BTW Does XUL support scrollBy, ScrollTo, pageYOffset, etc. If not what methods/properties are available for programatically scrolling the contents of XUL iframes?

PS was advised to assign to danm@netscape.com but assignment was rejected

The CSS2 specification says for the overflow property: hidden This value indicates that the content is clipped and that no scrolling mechanism should be provided to view the content outside the clipping region; users will not have access to clipped content. The size and shape of the clipping region is specified by the 'clip' property. Note the "users will not have access to clipped content" part.... So it looks like we are doing the right thing here....

So I take it that under Mozilla it is not possible to have scripted page scrolling without scrollbars ? This seems a bit contradictory - ie autoscrolling pages where the scrollbars have to be displayed even though they have no use? I think under XUL I should be able to hide the scrollbars using XBL but then XUL seems to lack any scripting support for scrolling (scrollBy, scrollTo, pageYOffset, etc). This appears to be a shortcoming in XUL iframes?? Should I file a bug on it? PS

Marking INVALID.

*** Bug 85909 has been marked as a duplicate of this bug. ***

VERIFIED, although I think the DOM should allow for this, and I'll be working on that for DOM3CSS.

Reopening.

Taking.

We should do this per the latest revisions to CSS2.1, in particular: http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15 http://www.w3.org/TR/2003/WD-CSS21-20030915/visufx.html#overflow

David, those sections don't seem to clarify the issue from CSS2 much... in particular, the "users will not have access to clipped content" language remains in the description of overflow:hidden. The patch looks technically fine to me at first glance if we do want to allow keyboard scrolling in overflow:hidden elements.

Oops. That's a mistake.

The change in question is clear in http://www.w3.org/Style/Group/css2-src/diffs-rec/visufx.html#overflow -- "mechanism" was changed to "user interface".

Comment on attachment 130776 [details] [diff] [review] patch r+sr=bzbarsky, thoguh NS_STYLE_OVERFLOW_HIDDEN is now somewhat misleadningly named.... The link you point to is member-only, but I'm assuming that the CSS2.1 spec will be updated as you say (I'll add it to my list of last-call comments).

URL should have been http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/visufx.html#overflow

Checked in, 2003-09-16 15:09 -0700, but leaving open to fix names of constants...

So now the scrollbar is visible in the testcase - in other words it *is* given a "User interface". It's just slightly difficult to use because it overrides my drags after a short while, but to some extent that can be counteracted. Mighty weird. And definatly NOT how for instance Opera works: In Opera there is NO visible scrollbar, the content just scrolls on its own. (attachment 25609 [details])

I think this has caused a regression in some XUL I was using: <hbox pack="end" style="overflow: hidden;"> now doesn't align right like it used to.

Normally there's arbitrary content in the hbox.

OK, so I need to use -moz-hidden-unscrollable in 1.6a and hidden pre-1.6a? Will style="overflow: hidden; overflow: -moz-hidden-unscrollable;" work?

Yes, that would work, although really, I'd think in XUL you'd normally want to just leave 'overflow' at its default, 'visible'. Re comment 18: It looks like something strange is going on with IFRAMEs. I'll look into it...

Unfortunately overflow: visible; has the nasty (for me) effect of making the overflow visible...

Oh, and the new property is a bit wordy, how about -moz-crop instead?

Oh, and does overflow: hidden; make xul's <scrollbox> unnecessary?

comment 18 (regression specific to IFRAMEs) is now bug 220195

Also, the values for the property are all adjectives, not verbs. -moz-cropped or -moz-clipped might make sense (I prefer the latter), but both those terms have other meanings in CSS, so I think I'd rather leave it as is.

This also caused "regression" bug 219693, since our percentage height quirks don't work across scrollframes.

*** Bug 220607 has been marked as a duplicate of this bug. ***

Marking various regression bugs as blocking this bug.

This might have caused "regression" bug 220718, "mousewheel scrolls innerHTML when it should not".

this also seems to have caused that a cursor doesn't show up in the input field here: http://gemal.dk/test/mozbug.html in build 20030916-04 it works in build 20030917-04 it doesn't work should I open a new bug. Not 100% sure why this bug is still open

This bug is marked FIXED but it isn't ? The too technical lingo is a bit hard to read too. Should an element with overflow:hidden be scrollable with keyboard arrows/mouse or not ? Meaning: overflow:hidden does nothing more than just remove the scrollbars?

This changes the meaning of the constants for mOverflow (SCROLLBARS_NONE -> HIDDEN and HIDDEN -> CLIP) in the style struct while leaving them the same for scrollbar styles. This makes the changes in nsFrameFrame and nsGfxScrollFrame a little interesting, and I removed the comment in nsGfxScrollFrame that I think is wrong. I tested the testcases on this bug, bug 220195, and bug 234851 (all 16 combinations on the dynamic testcase).

Comment on attachment 155220 [details] [diff] [review] rename constants (checked in 2004-08-09 18:32 -0700) - // This isn't quite right. The scrollframe will still be scrollable using keys. - // This can happen when HTML or BODY has propagated this style to the viewport. I think this comment is still correct. Consider <html> <body style="overflow:-moz-hidden-unscrollable;"> ... </body> </html> We'll have created a scrollframe at the viewport, no scrollbars will be shown, but you can still scroll using keys (I suspect).

OK, I changed it to: // This isn't quite right (although the value is deprecated and not // very important). The scrollframe will still be scrollable using // keys.