Closed Bug 62536 Opened 24 years ago Closed 18 years ago

function/property to get scroll position of elements

Categories

(Core :: DOM: Core & HTML, enhancement, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: wo, Unassigned)

References

Details

(Whiteboard: (py8ieh: use these dfns for ui2))

Attachments

(13 files, 4 obsolete files)

Implement scrollTop/Left and scrollHeight/Width -- div only
5.67 KB, patch
Details | Diff | Splinter Review
WIP for implementing element.scroll*, element.client*, element.scrollIntoView()
14.03 KB, patch
Details | Diff | Splinter Review
Better apporach...
27.55 KB, patch
Details | Diff | Splinter Review
Does everything except for onscroll.
27.87 KB, patch
peterv
: review+
jband_mozilla
: superreview+
Details | Diff | Splinter Review
scrollHeight/Width not functioning.
514 bytes, text/html
Details
Fixes all reported problems.
7.18 KB, patch
attinasi
: superreview+
Details | Diff | Splinter Review
Minor mods to the presshell changes to avoid unnecessary scrolling when a scrollable frame is scrolled into view
5.68 KB, patch
john
: review+
Details | Diff | Splinter Review
scrollIntoView as well as list all the scroll properties for different overflow values
2.89 KB, text/html
Details
scrollHeight still does not work as expected
556 bytes, text/html
Details
Fix element.scrollHieght and .scrollWidth when the element doesn't have scrollbars, map them to .offset*
1.46 KB, patch
bzbarsky
: review+
shaver
: superreview+
Details | Diff | Splinter Review
ScrollLeft and scrollTop values on element are changing
3.31 KB, text/html
Details
Implementation test case/challenge
13.50 KB, text/html
Details
zip of offsetHeight testcase
1.40 KB, application/octet-stream
Details 
Currently there is no way to find out the scroll position of an element with 
overflow:scroll.

<div id="example" style="height:100px; overflow:scroll">
  blabla...
</div>

It would be very helpful to have something like window.scrollY or 
window.pageYOffset for elements as well. In Internet Explorer, this is 
element.scrollTop (and element.scrollLeft).
This is a necessary feature if you want to script elements with
  style="overflow: auto;"
or 
  style="overflow: scroll;"
Note that in IE 
  scrollTop
respectively
  scrollLeft
can be read and set to scroll the element which is also highly desirable.
Status: UNCONFIRMED → NEW
Depends on: 35011
Ever confirmed: true
This bug has been marked "future" because the original netscape engineer
workingon this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work in
some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
OS: Windows 98 → All
Hardware: PC → All
Summary: [feature] function/property to get scroll position of elements → [RFE] function/property to get scroll position of elements
Target Milestone: --- → Future
Keywords: dom2
Component: DOM Level 2 → DOM Style
Taking QA Contact on all open or unverified DOM Style bugs...
QA Contact: vidur → ian
This feature is something that essential to using Gecko to create applications 
so it should have a higher priority and at least be fixed for the 1.0 realease.

Needed properties/methods/events:

scrollTop
scrollLeft
scrollHeight
scrollWidth
clientHeight
clientWidth
onscroll (event)
scrollIntoView([bTop])

See MSDN for detailed description.

A long news group message covering these issues can be found at
news:9d4bp9$7381@secnews.netscape.com
ping... Just wondering if this is being worked on these days...

This is related bug: Bug #72747
I should have something working very soon, just a little more patience, thanks :-)
jst, I attached the previous patch for reference only. I'd like you to take a
look at it and tell me if it's the right way to implement it. It is currently
only on div elements to minimize conflict risks. I have also not diff'ed the
interfaces.
It implements scrollHeight/Width and scrollLeft/Top.
I'll talk with joki about onscroll, since I need to crush an infinite loop
problem first.
ScrollIntoView should be easy to add later.
*** Bug 95094 has been marked as a duplicate of this bug. ***
*** Bug 102649 has been marked as a duplicate of this bug. ***
*** Bug 104245 has been marked as a duplicate of this bug. ***
jst, is it possible to do in 0.9.6?
Sure, Fabian already did the hard work here, I'll just massage this into the
generic code and make the interface changes and we should be all done.
Whiteboard: [HAVE PARTIAL FIX]
Target Milestone: Future → mozilla0.9.6
I ran into problems when implementing the onscroll event... it was behaving
microsoft-ish, i.e. it fired when I didn't want it to.
I based my implementation on the patch in bug 52599, but it needs a lot of
polish, and there is an infinite loop risk that we need to take care of
Anyone care to whip up some trivial testcases for all this new properties and
methods? I have most of them working in my tree now.
Fabian, yes, getting onscroll right is non-trivial.
yo, patch sounds very good. Why implement clientWidth/Height if it does nothing
though? Note that I tried to look at the MSDN document but I can't for the life
of me understand what they mean.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/off2000/html/rerefClientHeightProperty.asp
WIP, my friend, it will be implemented :-)

New patch coming up that moves the JS specific handling of the optional argument
into the scriptable helper which lets us leave the content code independent of
JS API calls. The new patch also doesn't increase the size of the tearoff that
implements nsIDOMNSHTMLElement.
Comment on attachment 53856 [details] [diff] [review]
Does everything except for onscroll.

r=peterv
Attachment #53856 - Flags: review+
Comment on attachment 53856 [details] [diff] [review]
Does everything except for onscroll.

sr=jband
Attachment #53856 - Flags: superreview+
Patch checked in, AFAIK all that is left is to support onscroll for elements,
reassigning to the event system for adding that support. From the DOM point of
view everything that has to do with onscroll should work, we just need to fire
the events when things are scrolled.
Assignee: jst → joki
Status: ASSIGNED → NEW
Component: DOM Style → DOM Events
QA Contact: ian → vladimire
Whiteboard: [HAVE PARTIAL FIX]
Bug 35011 actually covers the remaining element.onscroll, so I'm marking this fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Seems like scrollHeight/clientHeight is not functioning?
And also isn't bug 85213 a dupe of this one?
Argh, I forgot to make sure we're flusing reflow (and content) before getting
the frame/view info, patch coming up.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 54436 [details] [diff] [review]
FlushPendingNotifications() before asking for frame/view info

r=fabian
Attachment #54436 - Flags: review+
*** Bug 85213 has been marked as a duplicate of this bug. ***
jst is it possible to checkin the patch to flush pending modifications? also I
can confirm that erik's testcase doesn't work and in fact scrollIntoView doesn't
seem to work at all for me. But maybe I'm missing something.
Taking this back until I can get the mentioned problems sorted out. Joki, I'll
pass this back to you once I'm done, if that's not ok with you then take this
bug back...
Assignee: joki → jst
Status: REOPENED → NEW
Attachment #57204 - Attachment is obsolete: true
Mark, Fabian, reviews?
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Comment on attachment 57210 [details] [diff] [review]
Fixes all reported problems.

r=fabian for the content/ changes. Not qualified to review the layout/ changes,
sorry.
Comment on attachment 57210 [details] [diff] [review]
Fixes all reported problems.

sr=attinasi
Attachment #57210 - Flags: superreview+
Comment on attachment 58200 [details] [diff] [review]
Minor mods to the presshell changes to avoid unnecessary scrolling when a scrollable frame is scrolled into view

r=jkeiser
Attachment #58200 - Flags: review+
Fix checked in, the only thing that's left now is to make element.onscroll (and
window.onscroll) fire when scrolling.

Reassigning to joki.
Assignee: jst → joki
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → mozilla0.9.7
overflow: scroll works fine
overflow: auto does not work. The element might be under the scroll bar.
   1. Change overflow to auto
   2. Click "Go To Next Link" until the status says link8.
   3. Notice that link8 is placed under the horizontal scrollbar
overflow: hidden DOES NOT WORK AT ALL
Attachment #54680 - Attachment is obsolete: true
Huh, are you saying you want element.scrollIntoView() to scroll an element
that's outside the visible view in an element that has overflow: hidden; ? That
doesn't seem to make any sense to me. If you're saying overflow: hidden; you
don't get scrollbars, scrolling such a view is not an option, IMHO.
Yes. That is exactly what I am saying.

The scrollbars are only a GUI component that allows the user to scroll the view 
manually. It should not change the behavior of the view. The scroll model 
should not take the overflow property into account.

This feature is essiential for people creating their own scrollbars using 
XML/CSS/DOM.


I've updated the test case and notice how scrollWidth, scrollHeight, 
clientWidth and clientHeight return 0 when overflow is set to hidden. This is a 
very serious issue and these properties are extreemely important even when 
overflow is set to hidden. These properties are needed to find the content size!

I'll even give you a scenario proving my point; I was making a Label control 
for a GUI toolkit and this Label needed a preferred size and the only way to do 
this is to use scrollWidth/Height. (In NN4 one could use 
layerObject.document.width/height.)

One should also notice that the properties should not totally fail when
overflow is set to visible. The values should work ALL THE TIME.
Attachment #58860 - Attachment is obsolete: true
FYI I initially implemented it this way because the original bug report from
Wolfgang Schwarz and the additional comment from Martin Honnen at the beginning
of this bug were only about overflow:scroll and overflow:auto (nothing about
overflow:hidden).
I'm not sure there is a nsIScrollableView when there is no scrollbar, i.e. when
overflow:hidden is used, so getting this to work for overflow:hidden might be
more work.
Does IE let you scroll non-scrolled elements (i.e. overflow: hidden;)?

Fabian, I think you're right, I'm not sure there's a way to *scroll* something
that's not scrollable, which still seems very reasonable to me.
bug 80744 mentions a similar issue (if not the same one) about overflow:hidden.
When writing your own scrollbars it seems like the natural way to do this would
be to use a combination of css's clip-region and positioning properties. Asking
the UA to scroll something that you explicitly asked it to not make scrollable
still seems wrong to me. If the element.scroll* should scroll content in an
overflow: hidden; element, then to get any kind of consistency in this model the
arrow keys should also scroll such an element? They don't, and I don't think
they should.
Do you really think it is ok that scrollWidth, scrollHeight, clientWidth and 
clientHeight return 0 when overflow is set to hidden or visible?

When setting overflow to hidden I'm not disabling scrolling. I'm hiding the 
overflow. I think there is a big mistake seeing overflow as anything but a way 
to describe how overflowed content should be treated.

A similar case is when I open a window with no scrollbars. I can still scroll 
the window (either by selecting some text or using scripting). Do you think 
that this is wrong as well?

How come the scrolling of the viewport is not implemented in the same way as 
for normal elements?

No, I didn't say I think it's ok that scrollWidth, scrollHeight, clientWidth and 
clientHeight return 0 when overflow is set to hidden or visible, that seems like
a bug if IE doesn't do that.

I'm still waiting for an answer to my question about how IE deals with scrolling
of overflow: hidden; elements
(http://bugzilla.mozilla.org/show_bug.cgi?id=62536#c49), are they "scrollable"
with element.scroll*, are they "scrollable" with arrow keys?
IE allows scrolling when overflow is set to hidden using scripting 
(scrollIntoView, scrollLeft/Top). IE does not allow scrolling using keyboard 
or selection.
erik is right, imho. having two layers with clipping and positioning is the way
it needed to be for netscape 4 in the ancient days, because there was no other
way (and ie 4 wasn't any better). mozilla should not be limited in this way.
scrolling hidden content is a feature that is often neccessary for gui toolkits,
just as erik wrote, and the most logical way to do this is using scrollLeft/Top.
Ok, time to bring in the CSS gurus. I disagree when you say scrolling content of
an element that has overflow: hidden; is in any way logical.

Everything you can do with "scrollable" overflow: hidden; elements is AFAICT
just as doable with positioned elements and CSS clipping. To me that seems like
the logical way to go here, maybe that means more lines of script to write, but
that doesn't mean it's not the logical way to do it.

David, Ian, comments?
Scrolling when 'overflow' is 'hidden' does not make sense.  If IE does it, then
file a bug on IE requesting that they move that behavior to an
'-msie-secretly-scrollable' value for the 'overflow' property.
The CSS property is called overflow because it describes how to DISPLAY 
content with overflow hidden. The property is not called scroll or anything 
similar and does not explain the BEHAVIOR of the container.

The argument using clipping and absolute positioning for scrollable containers 
does not hold. This is a hack and is very limited and should not totally 
replace the useful properties scrollLeft/Top for containers, ANY CONTAINERS.

I'm sorry if I'm getting out of line here but all I want is Mozilla to be as 
good as possible and I think I have more experience when it comes to DHTML 
than most people and DHTML needs to get away from the hacks and workarounds in 
favor for some solid APIs.
If one should speak of logic, one should define what the premises are.
The premises are compliance with W3C, CSS and DOM.
Erik is right!
Functionality has nothing to do with appearance, end of story!
To separate content from presentation, and functionality from presentation of 
content, is what this is all about!
Thats the reason for XML to even exist, to begin with.
And dont try to wiggle your way out by saying that the premises arent about W3C 
or XML, because they are, it's what we all will have to deal with on the webb, 
when using this thing.
http://www.w3.org/TR/REC-CSS2/visufx.html#overflow
says
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.

Could it be more precise? 
No scrolling, no access to the clipped content.
me is with dbaron on this issue ; 'overflow : hidden' does not allow to position
the visible part of the document in the clipping region.
the css specs are about how the browser should render something for the user on
the screen, or maybe to other media. afaik they were not intended to have effect
on the internal representation of an element.
it is correct that the viewing user should not have access to the hidden content
(neither scrollbars, keyboard, dragging a selection etc.), but i don't think
that should affect anything else and especially not the scrolling via script.

the only overflow that really cannot be scrolled is overflow:visible, because
there is nowhere to scroll to.
As Axel quoted from the CSS spec above it couldn't be more clear in the spec,
and yes, the CSS spec does define when something should be scrollable and when
it shouldn't, that's why we have overflow: scroll;. You're arguing that the CSS
spec only defines how things are displayed to the user, and that's correct, it
defines that the overflowed content in an overflow: hide; element should not be
visible. In the far stretched edge case where you'd need something like this,
there's a logical way to do it, why introduce something that doesn't make sense,
is against the CSS spec, and is inconsistent, just to support an edge cases that
you can make work the right way in the first place?

So IE is broken and lets you scroll overflow: hidden; elements, well that's
Microsoft's problem, not ours. I don't see how you can argue with this. If you
think the CSS spec is wrong, then argue with the W3C CSS WG, but I doubt you'll
get far there either, what you're arguing for doesn't make sense.

There's a very logical way to do everything you can't do the _broken_ IE way
because of this "bug", so I don't see any (technical) reason to "fix" this.
Does this bug define how Bug 8927 behaves under overflow: hidden;?

It would seem intuitive to me that the anchor would scroll into view regardless
of sroll/hidden being set.


As Axel Hecht quoted "...no scrolling mechanism should be provided..." there is 
NOTHING in that text that deals with the way the content should be handled, 
only that the browser shouldn't provide any scrolling mechanism. It does not 
say that the browser should disallow scrolling. As others has commented before, 
overflow: hidden deals with the presentation of the data, not the behavior.
aaaaaaah, i *love* spec wars :-) everybody says the specs are a clear cut case,
and nobody brings in any real arguments why this should or should not be
implemented this way or the other.

my argument is that this feature is useful. what reasons (except the dubios css
specs) are there not to allow scrolling? don't get me wrong, i'm not offended if
this feature won't make it (just one more workaround neccessary), but are there
*good* reasons not to do it?
> what reasons (except the dubios css specs) are there not to allow scrolling?

The declaration 'overflow: hidden' is a clear statement that the elements to
which the declaration applies should never be scrolled, but that if any content
overflows it should be hidden.  What about that don't you understand?  Or do you
just think that MSIE defines web standards and we should follow them regardless?
The CSS spec is clear that no scrolling mechanism should be provided. Not that 
scripting the scrolling is not allowed. The CSS specs do not cover issues like 
this and therefore the most logical solution should be used.

I just hope that the reason why scripting scrollLeft/Top of a container is 
disabled is a logical reason and not a misinterpretation of a W3C standard 
that does not cover the issue.

There is no standard here so go with the logical one. Please!
The rendering that one can obtain through scripting should still be a rendering
that can be described by the CSS formatting model.  This one can't.
CSS spec talks about the CSS, not the DOM extensions of this issiue. CSS 
says 'no scrolling' which means 'no scrollbar' and making overflow:hidden 
should not display any interactive scrolling ability to the user.However, spec 
doesnt say that one must not be allowed to make the content scrollable via some 
functions triggered by javascript. So providing scrolling TOP/DOWN/LEFT/RIGHT 
ability using scripting on a ,for example, TEXTAREA does not override any CSS 
specification rules. In fact, usefulness of providing scrolling 
TOP/DOWN/LEFT/RIGHT ability using scripting is obvious. On the other hand, 
there are tons of non-spec features in Mozilla why not implement this one too?
The CSS rendering model doesn't describe form controls, but it does describe the
elements where you want this stuff to work.

I'm convinced you just don't care about standards, and I'm not going to bother
arguing this any more.
"I'm convinced you just don't care about standards"

What are you talking about? which standards? It is still standards complience. 
May be out of the context but, how money web browsers out there with 
CSS1/CSS2/DOM1/DOM2 compliance? 10? 20?. The answer is 'There are NONE'. In 
this context, could you explain Mozilla's stand on the Standards Compliant 
Browsers out there? There is a solid 95% IE dominance in the market. That means 
its features are defacto standard. And NO! you just cant ignore this fact. What 
we are trying to achive in this discussion so far is not to break the standard 
complience of Mozilla but to extend it. Where is the sense innovation here? 

When IE does things that don't make sense (as it does in this case) that only
matter in edge cases (like this case) we can, and will, ignore the fact that IE
has the majority of the market.

Exceptions to this rule will be made if this turns out to break more than a few
high profile sites.
d96erik, trying to do the logical thing here is what's this is all about, what
IE does is *not* logical.
It makes very much sense, as we're trying to point out, setting the overflow 
property to 'hidden' only specifies how the container should be 
displayed ,without scrollbars, and it does not say that the overflowing content 
should be inaccessible.
If scrolling on overflow: hidden is illogical, then surely it is illogical that
both mozilla and IE allow scrolling for frames with scrolling="no".

http://www.richdoughty.net/bugzilla/62536_frameset.htm
when the anchors are clicked, the frame relocates. As you would surely expect.

http://www.richdoughty.net/bugzilla/62536_overflow.htm
A virtually identical *effect* is achieved (in IE) as expected, yet it is
proposed that mozilla does not display this behaviour.

I know that neither of these examples used clientWidth etc, but this has turned
into a discussion about scrolling behaviour...

I think it would be better to implement the behaviour for overflow: hidden too.
This would resolve Bug 8927 too i believe.

If it entails more work, it would (IMHO) be better to future a fix for
overflow:scroll instead of dismissing it outright.

Thats just MTC.
Logical or not, this would be a great feature. I do think that sealing the fate
of a great browser in the name of some absurd interpretation of standards is in 
fact not logical. The features which would be good to have in a dynamic content 
should be implemented. Dynamic content is the way things going towards, and I 
dont believe XUL has a future.Therefore, DOM1/DOM2 must be beefed up. On the 
other hand, as far as, this discussion goes, I think everybody is wasting their 
time here. 

regards
> If scrolling on overflow: hidden is illogical, then surely it is illogical
> that both mozilla and IE allow scrolling for frames with scrolling="no".

Bug 86936.

In my opinion, scrolling="no" should completely disallow scrolling as should
overflow:hidden.  We should also provide a way for users to override either of
those settings (accessibility, you know).
I have never seen the word "logic" so bashed in my life.
To separate content from presentation, and functionality from presentation is 
what the current standardization-process is about to begin with.
The visible scrollbars are presentation, but to be able to scroll is part of 
that objects functionality.
I quote:
"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."

This relates to the presentation of this object, the div in question, affected 
by CSS, which exists for that purpose, but it still has the functionality to 
scroll, and logically, that should be accessable for scripting, which exists 
for the one reason to manipulate the underlying structure.
Note that i wrote "underlying"....
If you dont know what logic is, dont refer to it!
To separate content from presentation, and presentation from functionality, now 
what's so damned difficult about that?
And dont give us any **** about "standards" if you dont care about them.


Elements don't have the ability to scroll unless they have 'overflow: auto' or
'overflow: scroll' -- we create different objects in the rendering tree (which
we call the frame tree) in that case.

So if we wanted this to work, we'd have to map setting of .scrollLeft and
.scrollTop on 'overflow: hidden' elements to map those elements to be a pair of
rendering objects, one inside the other, with the clip on the outer one and with
the inner one being relatively positioned.

But wait, that's the standardized way to do scrolling.  So why can't you just
use that?
> no scrolling mechanism should be provided

Nowhere does that say "no scrollbars".  It instead says "no scrolling
mechanism".  

To answer your separation of content and presentation pointa, anything that
changes the way the page looks or acts is not content but presentation.  All
content does is create a content tree. Anything the user sees or interacts with
is presentation.  Content does not know anything about what the various nodes
really are, it just has a tree of nodes each of which has some attributes.

Notice that scripting _can_ affect presentation -- that's what the DOM CSS and
DOM Events specifications are for.  But this does not mean that all things
scriptable are content, by any means.

Scrolling, being a way things act is most definitely presentation and thus
within the purview of the CSS spec (and maybe the DOM Events spec for scrolling
events).
Boris, What part of "To separate content from presentation, and functionality 
from presentation is what the current standardization-process is about to begin 
with." did you not understand? Mikael was pointing out that the scrolling of an 
element with overflow hidden is functionality, not content.

Maybe your AOL browser has a problem with "functionality"?

This is my last post to this thread. It is getting out of hand. On one side 
there are experienced DHTML developers and on the other there are developers 
with an AOL Netscape background.. It is obvious who will have the last word :-(
Interestingly enough, Microsofts own documentation on the properties |scrollTop|
and |scrollLeft| state:

  "This property is always 0 for objects that do not have scroll bars. For these
   objects, setting the property has no effect."

That makes a lot of sense to me, but their own implementation doesn't follow
their own documentation.

Follow the steps on the page. With no overflow set scrollHeight returns 0.
Taking bug again for landing the latest fix.

bz or someone, r= for the last attachment?
Assignee: joki → jst
Comment on attachment 60511 [details] [diff] [review]
Fix element.scrollHieght and .scrollWidth when the element doesn't have scrollbars, map them to .offset*

Heh.  That's a nice way out.  r=bzbarsky
Attachment #60511 - Flags: review+
So Erik hasn't convinced you ? Well .. I can't see where he is wrong ??

Who sets the overflow ? The user ? NO! 
So, why would we set the overflow ? 
- In theory, to avoid content to be displayed.
- In practice this is also to hide scrollbars.

User should not be able to scroll in any way (keyboard, select) when it is 
hidden OK 
But if the page creator (the one who set the element overflow:hidden) want to 
use script (and that's something user cannot do) why can't him ????

Ok, there is already a way to do so. The clip. (As far as I know that's not 
supported on IE mac but i may be wrong)

As you said, it needs more lines. As I'm trying to make the lighter scripts as 
I can this make MUCH sense. All scrollbars using clip make around 10kb. Of 
course we can do better. With scrollHeight.. we will do better.

Why would we use another css attribute (clip) to obtain something about another 
one (scroll). 
Why don't you really want to do so ? 
- Users are not concerned with scrollHeight/Top ...
- DHTML community do not want to hack anymore.

So, i can't see any reason except "no time to do it" for you not to implement 
it.

Ignoring NS4 has become a bad habit for lots of "webmasters". More and more 
sites are IE only.
Don't let the new generation take that habit with Mozilla. 

If you got too much work ok, just tell it that's ok. But do not say it is no 
logical !
> But if the page creator (the one who set the element overflow:hidden) want to 
> use script (and that's something user cannot do)

This is blatantly false.  The used can execute arbitrary scripts on the web page
by using javascript: urls in the URL bar.  These urls can be bookmarked to
create fairly sophisticated scripts that allow the user to do pretty much
anything he wants.  So anything the page author can do with script the user can do.


Comment on attachment 60511 [details] [diff] [review]
Fix element.scrollHieght and .scrollWidth when the element doesn't have scrollbars, map them to .offset*

sr=shaver.  You kids play nice.
Attachment #60511 - Flags: superreview+
Patch checked in, element.scrollWidth and element.scrollHeight now work on
elements w/o a scrollbar too.

Back to joki for the onscroll fixes...
Assignee: jst → joki
JST wrote:

Fix element.scrollHieght and .scrollWidth when the element doesn't have
scrollbars, map them to .offset*


scrollWidth is not the same as offsetWidth. scrollWidth is the width of the 
content inside the viewport and offsetWidth is the size of the viewport plus 
borders and scrollbars.

Did you really mean that scrollWidth was going to return the same value as 
offsetWidth?
Eric, give me a testcase that shows a difference between element.scrollWidth and
element.offsetWidth and I'll have a look.
>>The user can execute arbitrary scripts on the web page
by using javascript: urls in the URL bar

... can't believe it ... is that an argument to not taking care of the bug ?
I'd rather the "too busy" one.

Well. The user can use scripting ... Do you really think that such an 
hypotetical very aknowledged visitor would have better hacks to do, than 
scrolling an hidden text ???

It would be easier for him to read the text in the source code. overflow hidden 
isn't a security property to keep a content secret...

So let us offer what we want to the user (who will have enough to play with on 
the page to leeave the location in peace).
Does anyone actually know of a real world page that uses element.scroll* on
overflow: hidden; elements?
I also feel that an overflow:hidden element should be scrollable via 
setting its scrollLeft and scrollTop properties, or by calling 
scrollIntoView().  Without reigniting the flame war above (which reminds 
me of some conversations we've had around my office ;-), my rationale 
goes like so:


I think we can all recognize that there are times that you might want to 
hide stuff that doesn't fit in a container, but provide some mechanism to 
scroll to see that stuff.  This is a very common thing to do in creating sites, 
games, etc which create a fictional or fantasy world, and even in other 
business-oriented sites where you're trying to establish a particular look 
to your site.

The real difference in proposed approaches seems to be:
 1) Some folks think that it's most appropriate to write a routine yourself to 
do this, by setting the rectangle and clip of the element manually.

 2) Some folks think that the browser should provide this functionality 
natively, in the same manner that it works for 'overflow:scroll' elements.  
(eg: setting the scrollLeft and scrollTop of elements, etc).

For Nav 4, I've actually written the routine described in #1 above in the 
DHTML framework I work on (www.isomorphic.com), and it's not trivial at 
all.  In fact, it's about 1K of fairly tricky code (without comments).  That's not 
even including code to take things like margins, padding and borders into 
account.  AND it only works if you actually can get the clip of your object.  
AND the clip must be set in pixels.  AND the sizes of your object must be 
set in pixels.  That's a lot of code to expect anyone who wants custom 
scrollbars to write, and it's still not bulletproof by any means!

Plus, there are some things you just can't do without native support.  For 
example, how can you do a   scrollIntoView()   by setting the clip?


What is the harm in implementing this feature, one that people who are 
actually doing DHTML now say they want, and which will simplify the life of 
anyone who's trying to do non-standard UIs with Mozilla?  There's already 
a code path that provides scrolling via these properties/methods, the one 
used in the 'overflow:scroll' case.  

The biggest disadvantage that I can see is that non-scrolling elements 
are instantiated differently in the 'frame tree' of Mozilla (see comment 
#80), and that making *every* element potentially scrollable thus would 
be more expensive.  

How about this for a solution:

 1) Implement overflow:hidden elements as non-scrolling elements 
initially, just as they are now.

 2) When javascript accesses or sets the scrollLeft or scrollTop properties 
of a non-scrolling element (calls scrollIntoView(), etc), convert the element 
in the frame tree to a scrolling element, but don't show its scrollbars.

 3) Proceed as if the element was scrollable in the first place, but without 
scrollbars.


This seems to balance the needs of the developers (not creating extra 
structures when they're not needed) and the needs of the people who 
want the feature (that they be able to use a uniform mechanism to scroll a 
canvas regardless of its overflow property).  This shouldn't be much 
harder to implement than the ability to dynamically set the overflow 
property of an element (that works, right?), it's just that the system is 
doing it for you.


If anyone still thinks that writing a manual scroll routine is easy, I invite you  
to write one yourself.  You need to be able to scroll any arbitrary object 
with  'overflow:hidden'  horizontally and vertically, say by pressing a button 
marked "up" and a button marked "down".  Don't forget to account for 
margins, padding, borders, different units (pixels, pts, etc), containment in 
other widgets, etc.  If this takes you less than 5 minutes and/or 500 bytes 
of code, I'd be *very* surprised...
*** Bug 8927 has been marked as a duplicate of this bug. ***
See attachment 58968 [details]. Click on "Alert scroll Properties"
You get undefined for d1.clientLeft, also if you change the overflow, press
once, and then alert the properties most of the values are 0.
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Keywords: mozilla1.0, oeone
FWIW, I agree with those that say you should be able to scroll ovorflow:hidden
content. (Well, we need _some_ way to scroll content that has no user scrolling
mechanism, anyway. Overloading 'hidden' seems to be the easiest way.)

Question: Does the following accurately describe the intended behaviour?

   element.scrollTop
      how far up the element content has been pushed relative to its default 
      position.

   element.scrollLeft
      how far left the element content has been pushed relative to its default 
      position.

   element.scrollBottom
      -element.scrollTop

   element.scrollRight
      -element.scrollLeft

   element.scrollHeight
   element.scrollWidth
      The size of the content (?).

   element.clientHeight
   element.clientWidth
      The computed values of the height and width properties (?).

   element.scrollIntoView()
      Scroll all scrollable views such that the element is visible.

   scroll event
      fired whenever the element scrolls. Bubbles. Cancelable.

Is that accurate?
scrollLeft, scrollLeft. Correct

scrollRight, scrollBottom. I do not think these are needed and IE does not 
have them. If implemented it would probably make sense to set scrollBottom = 
scrollHeight - clientHeight - scrollTop. In other words the distance from the 
lower edge of the content to the lower edge of the view port.

scrollWidth, scrollHeight is the width/height of the content

clientWidth, clientHeight. This the width/height of the view port. This means 
that it is offsetWidth - border-left-width - border-right-width - width of 
vertical scroll bar

clientLeft, clientHeight. The distance from the outer border edge to where the 
view port begins. This is usually the same as left-border-width but in case 
there is a scroll bar placed on the left side (for international use?) this 
should be inlcuded as well.

scrollIntoView([bTop]). Scrolls the element inot view by recursively scrolling 
all parent view ports into view as well. This method has one optional argument 
and the default value, which is true, means that the element should be aligned 
to the top of the view port. If false then the lower edge of the element 
should be aligned to the lower edge of the view port

scroll event. correct (any time scrollLeft, scrollTop changes)
[about bTop]
> If false then the lower edge of the element  should be aligned

Is that really what IE does?  It would be far more useful to have a value of
false indicate "scroll it into view, doesn't matter what the alignment is". 
This would mean that scrolling something into view would do nothing if the thing
is already in view (which is often useful).
scrollIntoView( bTop )

I totally agree that the IE behavior of this method is stupid. There should be 
three possible behaviors. align to top (useful when scrolling up in a list), 
align to bottom (useful when scrolling down in a alist) and just scroll into 
view using the shortest distance (if above view port align to top, if below 
view port align to bottom).

I do not know what the goal here is but with no argument I think it should 
scroll into view using the shortest distance. This behavior will in most 
scenarios be enough.
thanks
Whiteboard: [HAVE FIX] → [HAVE FIX] (py8ieh: use these dfns for ui2)
Since the onscroll event portion of this already exists in 35011 I'm separating
that out of this bug and letting jst decide if the remaining portions of this
bug require any more work based on the ongoing discussion.

Cleaing milestone as well since any more work on this bug will clearly not
happen in the next 5 hours.
Assignee: joki → jst
Target Milestone: mozilla0.9.9 → ---
Since "mozilla1.0" is one of the keywords for this bug I would like to know if 
this bug is beeing worked on. 1.0 is just around the corner and this bug is 
still to be fixed.

By the way: patch 60511 is incorrect. Mapping scrollWidth/Height to 
offsetWidth/height is NOT aceptable.
This will not be fixed for mozilla1.0.
Whiteboard: [HAVE FIX] (py8ieh: use these dfns for ui2) → (py8ieh: use these dfns for ui2)
Target Milestone: --- → mozilla1.1alpha
Hope I'm not way off here. 

myLayer.scrollTop = (getTop(myLayer) - getScrollTop());

function getScrollTop(){
	if(window.pageYOffset) return(window.pageYOffset);
	if(ie6) return(document.documentElement.scrollTop);
	if(ie5) return(document.body.scrollTop);
        return 0;
}

function getTop(layer){
   if (document.defaultView) return document.defaultView ... et c.
   return layer.offsetTop;
}


// another unnecessary IE feature.
scrollIntoView(id){location.hash = id;}

Element.prototype.scrollTop isn't even used to get the distance of the element
from the top of the viewport. I always thought MS put too many methods and
properties in. Most of them are buggy across different versions of IE. scrollTop
is one of the buggiest, which is probably why hardly anyone uses it. I just
thought I'd mention that I don't get any use from these props. Again, if I'm way
off here, I apologize.
To comment #108: I'm sorry to say this but you are off by quite a bit.

scrollLeft/Top is relative to the the element viewport. pageXOffet/pageYOffset 
is relative to the document viewport. This is a major difference.

offsetLeft/Top is not the same as defaultView.getComputedStyle(el, 
null).getPropertyValue("left"/"top") because offset* gices the position 
relative to the offset parent (the parent defining the coordinate space). 
computed style gives the calculated css value. These are in most cases not the 
same. A classic example is an inline element with position static. (Sometimes, 
for example for absolute positioned elements they happen to be the same.)

The scrollIntoView solution you are suggesting requires that the element has 
an id. Besides from this it is a pretty good solution. The problem is just 
that navigating to the anchor requires that scrollIntoView works (at least 
internally) and that is not the case. Just try one of the test cases...

I think you neeed to remember that every element has its own viewport. 
Sometimes there are nested viewports and a lot of the specs are not taking 
this into account. This is causing lot of confusion...

IE's implementation of scroll* is not buggy. The reason why you might think so 
is that you did not realize how it works. I agree that a lot of people are 
having trouble working with IE in standard mode vs quirks mode wheh checking 
the scroll properties on the topmost viewport.

Hardly anyone use it!?! I guess you are not a part of the DHTML developer 
comunity... at least not the one that has mostly targeted DOM and IE DHTML.

I'm sorry if I sound kind of harsh but a solid scroll model is very important 
and your last comment tried to plant confusion by adding comments that does 
not apply to the real world.
Keywords: oeone
Blocks: 48634
Isnt bug 145577 and bug 111207 dupes of this one?
no, they are not
No longer blocks: 48634
I'm not sure if this behavior should have been reported here or at bug 35011.

Self explanatory test case
*** Bug 167235 has been marked as a duplicate of this bug. ***
After filling a duplicate of this (sorry, I really tried to find the related
bugs), I am disappointed that this bug has not been resolved for a long time
due to a standards war.

Frankly, I have a more pragmatic approach to programming (and life in general).
As such, I've attached a test case that works in IE (because IE implements
assignment of element.scrollTop/scrollLeft for overflow:hidden).

So here is the challenge: recreate this test using only standards compliant
DHTML such that it works in both IE and mozilla. Please note that the resizing
behaviour is essential to this case.

I suggest that if no one meets this challenge, then we'll abandon the standards
war and just impelement the feature.
Of course, if it is possible to implement this using standards compliant DHTML,
then you can always point to the solution as the *pragmatic* reason why this is
not implemented.

Thanks
This is a customer supplied testcase which attempts to size the popup window to
content and then center the window on the screen.  It displays a series of
alerts that show the values of some of the properties.	
1) Comparing between mozilla and IE, I noticed that offsetHeight was very
different in Mozilla from IE.  It appears to me that this value is incorrect; 
currently, it is being calculated as close to scrollHeight, rather than
clientHeight.
2) Are offsetHeight/offsetWidth supposed to be smaller or larger than
clientWidth/clientHeight?
3) Also, if I set scrollbars=no, then the testcase breaks.  The properties
scrollHeight/scrollWidth are incorrect (related to patch 60511), and
clientHeight/clientWidth are set to 0.	Is this the intended effect?
Re: comment #116

I cannot view attachment 99149 [details] . It is a binary file of type
application/octet-stream . Could you re-upload your offsetHeight testcase as an
attachment of type source (text/html).

> 2) Are offsetHeight/offsetWidth supposed to be smaller or larger than
clientWidth/clientHeight?

elementRef.offsetHeight/Width should be greater or equal to
elementRef.clientHeight/Width . 

elementRef.offsetHeight/Width include strict content and padding and border
width and width/height of scrollbars (if present).
elementRef.clientHeight/Width include only strict content and padding.
drunclear:  It is a zip file containing two HTML files.  Just save it to disk
and unzip, then open up test.htm.
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
Summary: [RFE] function/property to get scroll position of elements → function/property to get scroll position of elements
Target Milestone: mozilla1.1alpha → ---
Something broke a while back.

document.documentElement.scrollTop now incorrectly returns 0 all the time, no
matter what. By default, document.documentElement.scrollTop == window.pageYOffset.

Currently the browser viewport scroll is set and read on document.body. This
might have been done intentionally to be compatible with IE4 but it makes no
sense whatsoever and it breaks logic as well as compatibility with IE6 in
standards mode.

scrollLeft/scrollTop should reflect the position of the viewport of an element
and by default the overflow/scrolling is handled by the root element (HTML in
HTML/XHTML) and not the document body.

Maybe someone should change the component because this got nothing to do with
events. To me "DOM Other" seems most logical but "DOM Mozilla Extensions' or
"DOM Level 0" seems to fit pretty well as well.
Flags: blocking1.3b?
>Currently the browser viewport scroll is set and read on document.body. This
>might have been done intentionally to be compatible with IE4 but it makes no
>sense whatsoever and it breaks logic as well as compatibility with IE6 in
>standards mode.

Exactly! Thank you! Finally someone who realizes the same thing I did many
months ago. Please have a look at bug 156388 and vote on it!
From a document's perspective, what you say is absolutely correct. 
From a window object perspective, the browser viewport in Gecko-based browsers
is given by the properties window.innerWidth and window.innerHeight.

>scrollLeft/scrollTop should reflect the position of the viewport of an element
>and by default the overflow/scrolling is handled by the root element (HTML in
>HTML/XHTML) and not the document body.

Exactly! The initial containing block (W3C) is the html element
(document.documentElement), not the body element (document.body). MSIE 6 in
standards compliant rendering mode is correct in measuring the scrollview of an
element within the viewport. Mozilla does not (in fact never did) honor
document.documentElement.scrollLeft/Top and this is not correct. Mozilla uses
window.pageXOffset and window.pageYOffset while, IMO, it should also honor
document.documentElement.scrollLeft and document.document.scrollTop as well.


I found the reason for the document.body.scroll* bug.

There is a special, invalid, handling in case a BODY element is used. Fixing
this part of the bug should be trivial by removing the invalid edge case.

In nsGenericHTMLElement.cpp in GetScrollInfo 

http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsGenericHTMLElement.cpp#1005

1005   if (!scrollFrame) {
1006     if (mNodeInfo->Equals(nsHTMLAtoms::body)) {
1007       // The scroll info for the body element should map to the scroll
1008       // info for the nearest scrollable frame above the body element
1009       // (i.e. the root scrollable frame).
1010 
1011       do {
1012         frame->GetParent(&frame);
1013 
1014         if (!frame) {
1015           break;
1016         }
1017 
1018         CallQueryInterface(frame, &scrollFrame);
1019       } while (!scrollFrame);
1020     }
1021 
1022     if (!scrollFrame) {
1023       return NS_OK;
1024     }
1025   }


Removing the added extra code for the BODY case should fix this part of the bug.

Should I file a separate bug for this and post the solution to that instead?
Component: DOM Events → DOM Mozilla Extensions
Keywords: mozilla1.0 → mozilla1.3
You are right this has nothing to do with dom events, moving to dom Other. It is
a good idea to file a separate bug for the problem you are describing because
this bug is about a new feature to be implemented and not about a bug in the
current features.
Component: DOM Mozilla Extensions → DOM Other
QA Contact: vladimire → gerardok
Oops, didnt notice you moved it already
Component: DOM Other → DOM Mozilla Extensions
Flags: blocking1.3b? → blocking1.3b-
*** Bug 171000 has been marked as a duplicate of this bug. ***
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Re comment #120:

Opera 7.11 and MSIE 6 for windows support
document.documentElement.scrollLeft/scrollTop in standards compliant rendering
mode. Mozilla 1.4 does NOT when I honestly think it should.
Demo proving this:
http://www10.brinkster.com/doctorunclear/BrowserBugsSection/MozillaBugs/Bug189308_ScrollEvent.html

Mozilla should drop window.scrollX/scrollY: window.pageXOffset/pageYOffset
already take care of scrolled document view values. It's redundant.

Mozilla should also drop document.body.scrollLeft/scrollTop when there is no
specific overflow:auto or overflow:scroll css declaration on the body. In the
demo page (Bug189308_ScrollEvent.html), only the root element *should* have a
overflow:auto declaration set; the body element has overflow:visible, so
returning values for document.body.scrollLeft/scrollTop when the document view
is scrolled is incorrect. 

If I'm not wrong, the default browser css declaration for the root element in
Mozilla used to be overflow:auto when now in 1.4 it is overflow:visible. I think
this is a mistake.

My 2 cents
> If I'm not wrong

You're wrong.  The thing that scrolls in mozilla is the viewport, not the root
element.
To comment #127:

Both documentElement and body have overflow visible by default and the
scrollable viewport contains the root element (Just like bz said). This is the
way it is supposed to be according to CSS2.

The only reason why document.body.scrollLeft/Top and
document.documentElement.scrollLeft/Top are provided (or actually maps to
something else than their own scrollable view) is to be more compatible with IE. 

See bug #211030 for more info (this was changed after 1.4). Try out the test
cases and you'll definately see that the HTML element nor the BODY provides the
scrollable viewport.
I just checked Mozilla 1.5 and it still does not support scrollLeft and 
scrollTop for a div with overflow hidden. I tried to read the whole post, but 
I am unclear if there was a decision on this feature/bug.

Can someone provide an update?
Blocks: 196779
> it still does not support scrollLeft and 
> scrollTop for a div with overflow hidden.

If you can't scroll an element with overflow: hidden, then its scrollLeft/scrollTop must be 0. See bug 259615.

----

I'm resolving this bug because all of the DHTML object model properties have been implemented appropriately for elements and because the remaining non-fixed ones are being addressed in specific bugs:

Bug 11207: implement clientLeft and clientTop

Bug 196779: Scroll position element properties not documented

Bug 229089: Textarea onscroll does not work

Resolving as FIXED
Status: NEW → RESOLVED
Closed: 23 years ago → 18 years ago
Keywords: dom2
Resolution: --- → FIXED
> Bug 11207: implement clientLeft and clientTop

Sorry. I meant to say Bug 111207 instead.
(In reply to comment #131)
> > it still does not support scrollLeft and 
> > scrollTop for a div with overflow hidden.
> 
> If you can't scroll an element with overflow: hidden, then its
> scrollLeft/scrollTop must be 0. See bug 259615.

Bug 259615 isn't related to this bug.  This bug concerns only scrolling by the author; bug 259615 concerns only scrolling by the user.

The problem mentioned in comment 130 was fixed by bug 69355.
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: