Open Bug 241033 Opened 20 years ago Updated 2 years ago

overflow scroll bars move position when a div is set to display none and then display block

Categories

(Core :: Layout, defect)

x86
Windows 2000
defect

Tracking

()

People

(Reporter: mozilla, Unassigned)

References

()

Details

(Keywords: testcase)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040419
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040419

When a <div> element is set to overflow:auto and elements inside it cause scroll 
 bars to appear the scroll bars behave unexpectedly when the <div> is set to
display:none and back to display:block.

When the scroll bars are moved, and the <div> element is set to display:none,
and then back to display:block, the scroll bars appear to have moved from where
they were left. However the display inside the <div> shows the view for where
the scroll bars should be. When the scroll bar is then used the contents "jump"
to catch up to where the scroll bar now is.

Also, if you move the scroll bars to a position, refresh the page (the scroll
bars are now reset back to 0,0) then set the <div> to display:none and back to
display:block, it causes the scroll bars to move to the position they were set
to before the page refresh.

Setting the <div> to display:none and then display:block, doesnt appear to
affect the scroll bars IF the scroll bars have not been moved since the <div>
was last set to display:none and then display:block.




Reproducible: Always
Steps to Reproduce:
1. Set up a html/xhtml page with a fixed width <div> with overflow:auto and a
larger div inside, with some js to set the <div> to display:none and display:block.
2. Scroll to any position on the <div>
3. Hide and show the <div>

Actual Results:  
The scroll bars move to a seemingly arbitary position but not the view of the
inside of the <div>

Expected Results:  
Kept the scroll bars where they were before the <div> was hidden? or perhaps
reset it to 0,0. But certainly not move them bizarrely.
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
does it work for you ?

WFM 

FF Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061116 Minefield/3.0a1
SM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061119 SeaMonkey/1.5a
We run into this problem when spoofing scroll bars. We use the onscroll event of one div to sync the state of another div. When the first div (or any of its ancestors) is hidden with display:none and redisplayed, its scrollTop is reset to 0 but the scroll event is not fired. The preferred behavior is for the scrollTop position to be remembered between display toggling.
Blocks: tibco
(In reply to comment #3)
> We use the onscroll event of one div to sync the state of another div. When the first div (or any of its
> ancestors) is hidden with display:none and redisplayed, its scrollTop is reset
> to 0 but the scroll event is not fired.

Hi, I'm reseting the scroll with: htmlDiv.scrollTop = 0; having visibility = "hidden" and display = "none" at the same time but nothing happens.
MSIE 6.0.2900 resets it properly.

I think that the "onscroll" event should be raised when changes happens "manually" (i.e. setting scrollXXX properties).
Sorry, my browser version is:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.