Closed
Bug 296922
Opened 20 years ago
Closed 19 years ago
a:hover pseudoclass with position:relative makes rendering jitter
Categories
(Core :: Layout, defect)
Core
Layout
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:
Comment 1•20 years ago
|
||
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.
Comment 3•19 years ago
|
||
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).
Comment 4•19 years ago
|
||
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.
Description
•