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)
Tracking
()
NEW
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.
Comment 1•20 years ago
|
||
Confirming.
Comment 2•18 years ago
|
||
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
Comment 3•17 years ago
|
||
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.
Comment 4•17 years ago
|
||
(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).
Comment 5•17 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•