Closed Bug 140944 Opened 22 years ago Closed 22 years ago

body.scroll* properties always return 0

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0

People

(Reporter: gilad_t, Assigned: jst)

Details

(Whiteboard: [FIXED ON TRUNK] DIGBug)

Attachments

(2 files, 1 obsolete file)

here scrollTop doesn't work
973 bytes, text/html
Details
Same as above but slightly more efficient.
1.15 KB, patch
bzbarsky
: review+
shaver
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
I was told that scrollLeft and scrollTop properties should work like in IE, but didn't get them to work.
They always return 0.
I attach a sample file which alers scrollTop.
This was checked up to mozilla 1.0 release candidate.

    
    

    
  
confirm that with a small window that requires scrolling to click on the GetInfo
link, that Mozilla 2002-04-26-06/trunk, and 2002-04-25-06/1.0.0 on win2k all
return zero while IE 5.5 does not.
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
  
Whiteboard: DIGBug

    
    

    
  
Is there a workaround for this?  I'm running into a problem with this for a
prototype DHTML photo album sorter I'm doing for the YGP group.  My event
handling code breaks if the document is scrolled, and I don't know of any way to
detect that situation unless this bug gets fixed.  :-(

    
    

    
  
IE6 always gives me '0' as result! (as does mozilla)

    
    

    
  
Seeing the same as Jonas-

win2k IE 6.0.2600 is always giving me 0 for scrollTop

    
    

    
  
Note that the body is not being scrolled at any point here (unlike in IE, where
it is).  This is because in IE the documentElement is the body, whereas in
Mozilla it's the <html> element...

nonetheless, the testcase fails if document.documentElement.scrollTop is
accessed too.
OS: Windows 2000 → All
Hardware: PC → All

    
    

    
  
Um, even in IE the documentElement (in DOM terms, at least) is the HTML element,
just like it is in Mozilla. Which one gets the scrollbars I don't know though,
and that difference might well be the reason for this bug...

    
    

    
  
No workaround for this one, fix coming up...
Status: NEW → ASSIGNED
Keywords: mozilla1.0, 
          
            nsbeta1
Summary: scrollTop and scrollLeft properties always return 0 → body.scroll* properties always return 0
Whiteboard: DIGBug → [HAVE FIX] DIGBug
Target Milestone: --- → mozilla1.0

    
    

    
  


  

        Attachment #81861 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 81862 [details] [diff] [review]
Same as above but slightly more efficient.

fix the tyop, and sr=shaver.  You tested the bejeezus out of this, right? 
Right.

        Attachment #81862 -
        Flags: superreview+

    
    

    
  
Comment on attachment 81862 [details] [diff] [review]
Same as above but slightly more efficient.

r=bzbarsky

        Attachment #81862 -
        Flags: review+

    
    

    
  
Fix checked in on the trunk.
Whiteboard: [HAVE FIX] DIGBug → [FIXED ON TRUNK] DIGBug

    
    

    
  
If the current patch checked in on the trunk works well and this is a low risk
patch (is it?), shouldn't this be fixed in the 1.0 branch too ?

If not, shouldn't the scroll* proporties be removed completely from the 1.0
branch instead?

    
    

    
  
Styg, do you volunteer to test scroll* properties on the trunk to verify that it
fixes the problem? Then perhaps we can check this fix on the branch. If we
removed scroll* properties, we'd have thousands of developers going down on us
in the next hour.

    
    

    
  
Fabian, I don't like the way you misspell my name. In danish "styg" means 
something like evil or very ugly. But I will make som test with a trunk-build 
later today anyway ;-)

    
    

    
  
I promised to test this on the trunk, and I've done it. It is however not a very
thoroughly test, I have just ran a quick test on a page in Peter-Paul Koch's
JavaScript section:

http://www.xs4all.nl/~ppk/js/index.html?/~ppk/js/winprop.html

Go to this page, and make the browser small enough to force horisontal
scrollbars in the main-frame. Scroll down to the section named "Your browser"
and scroll the main-frame a bit to the right so both scrollTop and scrollLeft
should give values bigger than zero. Now click on the "refresh list" link at the
bottom of the section. The browser is now tested for various window-proporties
and those which is found and are different from zero is listed.

I have testet this in Mozilla 1.0 Release Candidate 1, Mozilla 1.0 Trunk
2002050708 and Internet Explorer 5.5SP2. My results:

Mozilla 1.0RC1:
self.pageXOffset: 53
self.pageYOffset: 2793
self.screenX: 69
self.screenY: 37
self.innerHeight: 613
self.innerWidth: 657
self.outerHeight: 759
self.outerWidth: 865
self.screen.height: 864
self.screen.width: 1152
self.screen.availHeight: 864
self.screen.availWidth: 1152
self.screen.colorDepth: 32
self.screen.pixelDepth: 32
document.body.scrollHeight: 6287
document.documentElement.scrollHeight: 6327
document.body.scrollWidth: 642
document.documentElement.scrollWidth: 776
document.body.offsetHeight: 6287
document.documentElement.offsetHeight: 6327
document.body.offsetWidth: 642
document.documentElement.offsetWidth: 776
(note, there is no scrollTop or scrollLeft property***)

Mozilla Trunk 2002050708:
self.pageXOffset: 63
self.pageYOffset: 2840
self.screenX: 210
self.screenY: 8
self.innerHeight: 680
self.innerWidth: 668
self.outerHeight: 814
self.outerWidth: 676
self.screen.height: 864
self.screen.width: 1152
self.screen.availHeight: 864
self.screen.availWidth: 1152
self.screen.colorDepth: 32
self.screen.pixelDepth: 32
document.body.clientHeight: 665
document.body.clientWidth: 653
document.body.scrollHeight: 6397
document.documentElement.scrollHeight: 6397
document.body.scrollWidth: 777
document.documentElement.scrollWidth: 777
document.body.scrollLeft: 63 ***
document.body.scrollTop: 2840 ***
document.body.offsetHeight: 6357
document.documentElement.offsetHeight: 6397
document.body.offsetWidth: 645
document.documentElement.offsetWidth: 777

IE55-SP2:
self.screen.height: 864
self.screen.width: 1152
self.screen.availHeight: 864
self.screen.availWidth: 1152
self.screenTop: 88
self.screenLeft: 212
self.screen.colorDepth: 32
document.body.clientHeight: 664
document.body.clientWidth: 686
document.body.scrollHeight: 6042
document.documentElement.scrollHeight: 684
document.body.scrollWidth: 791
document.documentElement.scrollWidth: 706
document.body.scrollLeft: 47 ***
document.body.scrollTop: 2773 ***
document.body.offsetHeight: 684
document.documentElement.offsetHeight: 684
document.body.offsetWidth: 706
document.documentElement.offsetWidth: 706

The nature of this "testcase" doesn't prove that the results are pixel-perfect,
but it definitely looks god to me.

You could make a more advanced testcase testing IFRAMEs and DIVs and in a
scientific pixel-precise way... Maybe I will later, eh well I guess I *have* to
if it is required for a 1.0branch checkin which I hope for ?

    
    

    
  
Thanks Stig! And sorry for the misspelling :-)

    
    

    
  
Email requesting approval to check this in on the mozilla1.0 branch was sent to
drivers@mozilla.org yesterday, no responce yet...

    
    

    
  
The normal way to find the scroll position in IE is:
- If only body.scrollTop is available, use body.scrollTop. (Old version of IE.)
- If both body.scrollTop and documentElement.scrollTop are available, add them.
(One will be nonzero depending on quirks/standards mode.)

This patch made us compatible with IE's quirks mode.

    
    

    
  
Comment on attachment 81862 [details] [diff] [review]
Same as above but slightly more efficient.

a=rjesup@wgate.com for branch checkin.	Make sure it's in trunk too

    
    

    
  
Comment on attachment 81862 [details] [diff] [review]
Same as above but slightly more efficient.

a=rjesup@wgate.com for branch checkin.	Make sure it's in trunk too

    
    

    
  
Fixed on the mozilla1.0 branch as well.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
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: