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.

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.

Taking QA Contact on all open or unverified DOM Style bugs...

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.

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

Comment on attachment 53856 [details] [diff] [review] Does everything except for onscroll. sr=jband

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.

Bug 35011 actually covers the remaining element.onscroll, so I'm marking this 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.

Comment on attachment 54436 [details] [diff] [review] FlushPendingNotifications() before asking for frame/view info r=fabian

*** 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...

Mark, Fabian, reviews?

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

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

Fix checked in, the only thing that's left now is to make element.onscroll (and window.onscroll) fire when scrolling. Reassigning to joki.

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

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.

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?

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

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.

Patch checked in, element.scrollWidth and element.scrollHeight now work on elements w/o a scrollbar too. Back to joki for the onscroll fixes...

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

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

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.

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.

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.

Here is a description of what IE does: http://msdn.microsoft.com/workshop/author/om/measuring.asp

Isnt bug 145577 and bug 111207 dupes of this one?

no, they are not

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.

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.

>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?

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.

Oops, didnt notice you moved it already

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

Mass-reassigning bugs to dom_bugs@netscape.com

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?

> 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

> 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.