Open Bug 241033 Opened 22 years ago Updated 3 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.