User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 the elements overlap Reproducible: Always Steps to Reproduce: 1. Open the attached file. 2. Resize the bowser's window to such a big size when the 'frame' and 'footer' do not to reach each other. (This requires high resolution) 3. Switch on the 'last element' by the button below. -If it is necessary then the 'last element' pushes down the 'footer'. This is the expected behaviour. 4. Switch off the 'last element'. 5. Resize the browser's window to so small size when the 'frame' and 'footer' do reach each other. In this case the vertical scrollbar appears. 6. Switch on the 'last element' - Symptom: the elements overlap, the 'footer' remains there which seems to be unexpected behaviour. 7. Resize the window in horizontal direction just for one or two pixels. - The 'footer' gets to its intended position. 8. Switch off the 'last element' 9. Resize the window vertically again. - 'footer' gets back to its proper position. Our question is about this symptom. Is this a bug or feature?

Confirming bug, 2003-11-10-05 trunk Linux

Any chance of a minimal testcase?

The bug occurs not when an element is resized (see testcase#2, testcase#A and tree a) below) but when the resizing of a parent is enforced by resizing it's child (see testcase#1, testcase#B and tree b) below). a. :: OK BODY position: absolute -> resize |-DIV position: absolute, bottom: 0px b. :: BUG BODY position: absolute |-DIV position: static -> resize |-DIV position: absolute, bottom: 0px The expected behaviour can be checked in Opera 7, I tested it under win2K, Opera 7.03, 7.21 and 7.22. The case represented by the tree b) can be investigated when You resize the child and after that resize the window too (see testcase#C), beacuse in the case of resizing the window the child positioned to the bottom jumps down to it's proper position at once. Are these cases good as minimal testcases?

Yeah, they're fine. The problem is made pretty clear by the last one of those or the testcase in comment #4.

*** Bug 254813 has been marked as a duplicate of this bug. ***

Fixed by checkin for bug 261064