User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 In the page, http://autoweb.net/~ryan/bug/index.pl.html properly follows the :hover attributes, however, the menu down the left does not. (Mouseover does not cause the links to highlight) mozilla-firebird 0.6-8 (Debian Package number) and mozilla 1.4 render this correctly, Mozilla 1.5 and 1.6 as packaged by Debian do not. Reproducible: Always Steps to Reproduce: 1. Visit the page http://autoweb.net/~ryan/bug/index.pl.html 2. Mouseover various links 3. Actual Results: Some links render according to the :hover style, some do not. Expected Results: All links should have rendered as per the :hover style.

Hmmm. It's possible to get the menu links to go into :hover state by pressing tab or switching windows with alt-tab, so it seems like some sort of HasStateDependentStyle or reresolution bug.

My build with the patch to bug 233094 works on this testcase... (the menu is a floated table cell).

(In reply to comment #2) > My build with the patch to bug 233094 works on this testcase... (the menu is a > floated table cell). Sorry, I left out the other rendering bug - the right cell seems to be displayed below the "left" cell (also a regression from earlier Mozilla releases). Thanks!

> the other rendering bug - the right cell seems to be displayed below the "left" > cell I'm not sure that's a bug, actually. The second float has no width set, should be in the same table cell as the first float, and has content whose preferred width is "as wide as possible". So we may actually be doing this correctly now (and wrong before), but I don't quite understand the intricacies of shrink-wrapping layout well enough to judge.

(In reply to comment #4) > > the other rendering bug - the right cell seems to be displayed below the "left" > > cell > > I'm not sure that's a bug, actually. The second float has no width set, should > be in the same table cell as the first float, and has content whose preferred > width is "as wide as possible". So we may actually be doing this correctly now > (and wrong before), but I don't quite understand the intricacies of > shrink-wrapping layout well enough to judge. Ok, you convinced me to experiment some more. If I drop the float:left from both cell styles (.rightcolumn and .leftcolumn), both 'bugs' I was seeing go away. The :hover part is probably a legitimate bug, still, but my addon about the cell formatting can be ignored (I'm still abusing tables for layout as I switch to CSS for everything else on this site - it takes a while to sort through everything.)

Fixed by checkin for bug 233094.