Last Comment Bug 69355 - scrolling = no and overflow:hidden both prevent ANY scrolling
: scrolling = no and overflow:hidden both prevent ANY scrolling
Status: RESOLVED FIXED
[patch]
: css2
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla1.6alpha
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
: Hixie (not reading bugmail)
Mentors:
: 85909 220607 (view as bug list)
Depends on: 221140 259615
Blocks: 219693 220266 220667 220848
  Show dependency treegraph
 
Reported: 2001-02-19 09:51 PST by rvj
Modified: 2004-09-15 11:18 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
example of scrollbarless scrolling (1.18 KB, text/html)
2001-02-19 09:54 PST, rvj
no flags Details
patch (15.59 KB, patch)
2003-09-02 10:23 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Review
Simplified test case (729 bytes, application/vnd.mozilla.xul+xml)
2003-09-17 03:16 PDT, neil@parkwaycc.co.uk
no flags Details
rename constants (checked in 2004-08-09 18:32 -0700) (29.57 KB, patch)
2004-08-04 17:27 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Review

Description rvj 2001-02-19 09:51:24 PST
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?
Comment 1 rvj 2001-02-19 09:54:19 PST
Created attachment 25609 [details]
example of scrollbarless scrolling
Comment 2 rvj 2001-02-19 09:56:28 PST
PS was advised to assign to danm@netscape.com but assignment was rejected
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2001-02-19 13:41:54 PST
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....
Comment 4 rvj 2001-02-19 22:00:21 PST
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 
Comment 5 Keyser Sose 2001-04-02 17:56:43 PDT
Marking INVALID.
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2001-06-14 19:12:01 PDT
*** Bug 85909 has been marked as a duplicate of this bug. ***
Comment 7 Hixie (not reading bugmail) 2001-06-22 07:02:14 PDT
VERIFIED, although I think the DOM should allow for this, and I'll be working on
that for DOM3CSS.
Comment 8 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-02 10:09:42 PDT
Reopening.
Comment 9 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-02 10:10:05 PDT
Taking.
Comment 10 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-02 10:23:00 PDT
Created attachment 130776 [details] [diff] [review]
patch
Comment 11 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-16 12:37:36 PDT
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
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-09-16 13:10:12 PDT
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.
Comment 13 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-16 14:05:50 PDT
Oops.  That's a mistake.
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-16 14:13:51 PDT
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 15 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-09-16 14:53:55 PDT
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).
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-16 15:01:45 PDT
URL should have been
http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/visufx.html#overflow
Comment 17 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-16 16:59:54 PDT
Checked in, 2003-09-16 15:09 -0700, but leaving open to fix names of constants...
Comment 18 R.K.Aa. 2003-09-17 01:32:19 PDT
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])
Comment 19 neil@parkwaycc.co.uk 2003-09-17 03:04:27 PDT
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.
Comment 20 neil@parkwaycc.co.uk 2003-09-17 03:16:16 PDT
Created attachment 131591 [details]
Simplified test case

Normally there's arbitrary content in the hbox.
Comment 21 neil@parkwaycc.co.uk 2003-09-17 03:24:32 PDT
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?
Comment 22 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-17 10:58:10 PDT
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...
Comment 23 neil@parkwaycc.co.uk 2003-09-17 11:40:17 PDT
Unfortunately overflow: visible; has the nasty (for me) effect of making the
overflow visible...
Comment 24 neil@parkwaycc.co.uk 2003-09-17 11:41:46 PDT
Oh, and the new property is a bit wordy, how about -moz-crop instead?
Comment 25 neil@parkwaycc.co.uk 2003-09-18 07:51:11 PDT
Oh, and does overflow: hidden; make xul's <scrollbox> unnecessary?
Comment 26 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-24 17:05:37 PDT
comment 18 (regression specific to IFRAMEs) is now bug 220195
Comment 27 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-24 17:06:33 PDT
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.
Comment 28 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-28 11:24:26 PDT
This also caused "regression" bug 219693, since our percentage height quirks
don't work across scrollframes.
Comment 29 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-09-28 23:02:03 PDT
*** Bug 220607 has been marked as a duplicate of this bug. ***
Comment 30 Boris Zbarsky [:bz] (Out June 25-July 6) 2003-09-29 08:57:19 PDT
Marking various regression bugs as blocking this bug.
Comment 31 Jesse Ruderman 2003-09-29 21:38:46 PDT
This might have caused "regression" bug 220718, "mousewheel scrolls innerHTML
when it should not".
Comment 32 Henrik Gemal 2003-11-27 05:47:01 PST
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
Comment 33 Peter van der Woude [:Peter6] 2004-04-29 15:34:44 PDT
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?
Comment 34 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-04 17:27:30 PDT
Created attachment 155220 [details] [diff] [review]
rename constants (checked in 2004-08-09 18:32 -0700)

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 35 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-08-09 13:47:39 PDT
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).
Comment 36 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-08-09 18:25:59 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.