Closed Bug 296922 Opened 20 years ago Closed 19 years ago

a:hover pseudoclass with position:relative makes rendering jitter

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: Gabriel.de-Perthuis, Unassigned)

References

()

Details

(Keywords: css1, qawanted)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.8b2) Gecko/20050507 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); fr; rv:1.8b2) Gecko/20050507 Firefox/1.0+

See http://topos.tobu.free.fr/test/hovertest.html (testcase) and
http://www.w3.org/Style/CSS/ (try to click on the 3 on the right column in
«Specs 1, 2.1, 3»).
When a a:hover moves or resizes the bounding box of a link, the cursor position
that activated the hover is no longer in the bounding box of the link. Mozilla
understands this as «the link is no longer active», which causes the jitter. In
the w3 page case this makes the link unusable.

To avoid this, mozilla should not use the :hover pseudoclass when calculating a
link's active area.



Reproducible: Always

Steps to Reproduce:
I'm not really sure, this is a bug. I think, what Mozilla is doing in current
trunk builds, is technically correct.
I think this was introduced with the fix for bug 20022, so maybe David has
something to say about this.
See bug 20022, comment 51 which links to a similar testcase.
This doesn't conflict with the issue of #20022 , the event-handling part is well
as it is. Suppressing the mouse event wouldn't work anyway because moving the
mouse vertically would still change the hover state.
Looking at the other testcase, it works by causing a reflow. I don't think event
loops caused by reflows on hover can be avoided, because the reflow affects the
whole document. Maybe reflows caused by hover state changes should be
suppressed, but probably there's no way to tell where the reflow comes from.
Causing a reflow in a hover class is asking for trouble.

In these two cases there is no reflow (mine uses position-relative, the w3 page
uses an outline). The boundaries of the link without the hover class have no
reason to change. So the ui should just keep the hover area as it is,
independently of the new boundaries of the link.
Since the current behaviour is annoying for the user, has no useful applications
and has a workaround, let's call it a bug.

Actually the outline shouldn't change the link boundaries anyway, so it looks
like there is another issue on the w3 page.
Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8b4)
Gecko/20050905 Firefox/1.0+ ID:2005090518

This behavior persists in the above nightly.  I'm confirming this bug, with the
caveat that (as indicated in comment 1) this may not be considered a bug by the
developers.

As a side note, it would be handy to submit a testcase through bugzilla (just so
we have a copy we know won't go anywhere).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: css1, qawanted
It really doesn't make any sense to treat the link as being hovered when the
mouse cursor isn't actually over the link.  Given that constraint, there's no
way to avoid jitter when people use styles like that...
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.