User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060927 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060927 Minefield/3.0a1
If an element is positioned absolutely at the bottom of an element which has min-height set (and position:relative; overflow:hidden), it is positioned at the top of the containing element.
In the latest Release-Version of Firefox the element gets positioned correctly after clicking on a link inside of it (event-handlers of this link don't get fired). The latest nightly build keeps the wrong position.
Reproducible: Always
Steps to Reproduce:
1. see attached file
Actual Results:
wrong position
jumpy click behavior in Release version
Expected Results:
correct position

> If an element is positioned absolutely at the bottom of an element which has
> min-height set (and position:relative; overflow:hidden), it is positioned at
> the top of the containing element.
I am not sure I understand. Are you saying that being positioned at the top of the containing element is the expected results?
> Actual Results:
> wrong position> Expected Results:
> correct position
Ralf, please, can you clarify, specify what are the actual results and what are the expected results.
Adding testcase and qawanted keywords

Thank you Ralf for the clarification.
From your testcase, I see that I get actual results with Firefox 2.0 RC1 rv:1.8.1 build 20060918 and with Seamonkey 1.5a rv:1.9a1 build 2006092709
I get expected results with IE 7 RC1, Opera 9.02, Swift 0.1
Component: -> Layout R & A Pos
Now,
we need to search for possible duplicates, eg if a bug like bug 196937 (or bug 128670) is a duplicate of this one. I believe your bug 354504 is actually just a consequence of bug 128670. I've asked over there to confirm this. That's why I'm leaving qawanted keyword.
If bug 354504 is an independent bug from bug 128670 and independent from bug 196937, then I wonder if your testcase can be furthermore reduced.

Ralf, I believe this bug is a duplicate of bug 128670: summary, description, testcases and comments over there support this. Thererfore, resolving as such.
*** This bug has been marked as a duplicate of 128670 ***