264697 - Having an on-hover blockquote inside a LI list item renders incorrectly after hovering removed

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Stephen Oberholtzer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041016 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041016 Firefox/1.0

This sort of thing:

<style>
li blockquote { display: none }
li:hover blockquote { display: block }
</style>

causes blockquote elements inside list items to not normally be rendered (or
even take part in the flow).  When the cursor is over the LI, the blockquote
should be drawn. When the cursor is removed from the LI, the blockquote is no
longer rendered.  In theory, the page before hovering should be rendered
identically to the page after hovering.

In practice, this doesn't happen.

Reproducible: Always
Steps to Reproduce:
1. Go to http://klozoff.ms11.net/xpconnect-classes.xml.  It has an XSLT rule to
generate HTML. (To view the HTML, press Ctrl-A, the right-click and choose 'View
selected source'.)

1.5. Note how all the list items are spaced very close together.

2. Place your cursor at the bottom of the screen, just under all the '@mozilla's
in the list.

3. Slowly move your cursor up towards the top of the screen.

Actual Results:  
As the cursor goes over each list items, the blockquote is displayed, pushing
the list items below it downward.  When the cursor is moved up, and off of each
list item, some of the list items (all of them, if you move the cursor slowly
and steadily enough) will have some extra spacing between them left over.

Expected Results:  
The list items should be as close together as they were initially after the
:hover attribute no longer applies.

A few interesting things to note:

* The generated HTML passes the W3C validator in HTML 4.01 Strict mode. I made
sure of that, just to make sure it wasn't the result of trying to treat bad HTML
as standards compliant.

* Moving the cursor downward over the list tends to partially 'fix' the extra
spacing (usually in clumps of two list items).

* The amount of extra spacing is influenced by the text size. Bigger text adds
more space. Partial testing indicates that the excess height is equal to the
value of the 'font-size' as I read it out of the Computed Style with DOM inspector.

* Changing the text size (for example, using Ctrl+Plus or Ctrl-Minus) will
redraw the screen correctly.

Comment 1

[José Jeria]

This seems to work fine on trunk, but not the 1.7 branch. 

Comment 2

[Boris Zbarsky [:bzbarsky]]

Marking worksforme (it does, on trunk).  This was fixed by roc's dynamic-margin
fix a few weeks back.