Closed Bug 638413 Opened 14 years ago Closed 12 years ago

Elements that use overflow hidden will lose their scroll position on resize.


(Core :: Layout, defect)

Not set





(Reporter: david.haasler, Unassigned)



(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110302 Firefox/4.0b13pre

In our testcase, an overflow element is horizontally scrolled to an offset of 50px. The element loses the scrolling position by changing its width.

Reproducible: Always

Steps to Reproduce:
1. open testcase
2. click button
Actual Results:  
An alert box opens with the following text: "fail: scroll position changed from 50 to 0.". The overflow element lost its scrolling position.

Expected Results:  
An alert box opens with the following text: "ok". The scrolling position remains.

This problem occurs with all Firefox versions on all desktop browsers. It did not occur on an Android device (Firefox 4.0b4).
Attached file testcase
Regression window:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a1) Gecko/20060315 Firefox/1.6a1
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a1) Gecko/20060316 Firefox/1.6a1
roc, is this scrollframe's reflow stuff screwing up?
Component: DOM → Layout
QA Contact: general → layout
Whiteboard: DUPEME
We may be experiencing something similar to this behaviour in Modernizr[1]. Due to a very odd bug with Safari 5.1[2] we needed to set the document.documentElement to be overflow hidden otherwise Safari gets caught in a infinite reload loop. However this has presented a new issue in Firefox where the scroll position is lost due to setting the overflow of documentElement to hidden. 

This only happens if the script is in the head.

Ever confirmed: true
This test actually seems to pass on trunk. I'm not sure what might have fixed it. Can anyone confirm it's fixed in nightly builds?
I cannot reproduce the problem of the testcase anymore in Firefox10ESR and 16.0.1 and later.

Fixed window(m-c)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110812 Firefox/8.0a1 ID:20110812030744
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110812 Firefox/8.0a1 ID:20110812065831
Fixed Pushlog:

Fixed window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110811 Firefox/8.0a1 ID:20110811142310
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110811 Firefox/8.0a1 ID:20110811175210
Fixed Pushlog:

I guess Bug 386444 or Bug 657401 fixed this.
Probably 386444. Thanks Alice.

By the way, feel free to mark bugs FIXED yourself if you've determined that they are.
Closed: 12 years ago
Resolution: --- → FIXED
Seems like we may be seeing a regression of this issue in FF19, the Modernizr bug[1] appears to be back.

Ryan, can you please file a bug with a testcase?  Note that the description you link to seems unrelated to this bug as filed...
Boris, it's somewhat related in that overflow hidden element loses scroll position when you go back to the page after navigating away from it. It's not resizing but it's showing the same symptoms.

This one with Modernizr that uses a detect which sets documentElement to be initially 'overflow:hidden'[1] this is needed to fix a bug in Safari. On navigating away and then clicking back the scroll position is lost, only in firefox, other browsers handle this fine. See test case[2].

Now the same test case[3] with the documentElement overflow hidden line removed doesn't lose scroll position in FF19 when navigating back to the test case.

Ryan, please please file a separate bug.  Adding links to a fixed bug is not all that useful.....
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.