User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 If two block-elements are side-by-side in a document using float: left style attribute, and they happen to be the same z-index, the user cannot click any links in the floated block, nor select any of the text. If, however, the floated block is brought to the foreground by increasing the z-index, links become clickable and text selectable. The fix for the given example can be seen at http://makyo.drab-makyo.com/RTC%20New%20Webiste/site/ Reproducible: Always Steps to Reproduce: 1. Create a document and a style sheet. 2. In the document, create two <div> elements and fill them with text and links. 3. In the stylesheet, position both <div> elements relatively and set the one that will be on the left as float: left; Do not set a z-index for either (both will be z-index: 0;) Actual Results: Unable to click the links or select the text in the floated navigation bar on the page. Expected Results: With both elements being of the same z-index, one should not cover up the other and make selection or link activation impossible.

Probable duplicate of bug 226554

The second DIV overlaps the first because blocks are laid out as if floats does not exist (although its line boxes are shortened): http://www.w3.org/TR/CSS21/visuren.html#block-formatting They are both rel.pos. so the one later in the document is in front of the first one. Brief overview of stacking order: http://www.w3.org/TR/CSS21/visuren.html#propdef-z-index Detailed description of stacking order: http://www.w3.org/TR/CSS21/zindex.html If you remove the 'position' declaration for #content in the example it should make it go under the rel.pos. block with the links. Or, if you need it to be positioned for some reason then I think you have to add an explicit z-index to get the #navbar on top. Whether or not the event should target overlapped elements is bug 102695, which most likely will end up as WONTFIX in favor of adding a specific CSS property so that you can specify event transparency (bug 380573).