Closed Bug 314346 Opened 20 years ago Closed 19 years ago

[FIX]hovering over content, generated with :before/after{content:url(...)}, does not trigger :before/after:hover{content:...}

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: dao, Assigned: bzbarsky)

References

(
URL
)

Details

Attachments

(2 files)

Testcase
638 bytes, text/html
Details
Proposed fix
1.54 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 If you append an image to <foo></foo> with foo:before/after{content:url(...)}, :before/after:hover{content:...} will not be applied when hovering over the image (but when hovering over other contents of foo). Strangely something like :before/after:hover{background:red} that does not change the appended content works as expected. Reproducible: Always Steps to Reproduce: 1. <foo>something</foo> 2. foo:after { content: url(my_image.png); } 3. foo:hover:after { content: "anything" } 4. try hovering over foo and my_image.png directly (which also means not to hover over foo's padding or line-spacing) Actual Results: content of :after does not change as you hover over the image. Expected Results: Same behavior as with text instead of images. Can also be seen at http://www.playable.de/ -- I'm speaking of the three big images above the page's actual content. You can use Opera (and maybe Konqueror / Safari?) to see how it should look like. I know this is a bug of minor importance, since almost nobody uses content:url(...). But I do. I'd love to see Gecko handle it right as I'm not going to apply any workaround, because it would require additional markup.
I don't see what it is that you expect to happen with the testcase that isn't happening. It could be that the bug works for me, but it would help if you give clearer "Expected results" and "Actual results" statements describing the testcase http://www.design-noir.de/bugzilla/content-url-hover.html Also, :before:hover is an invalid selector (you get it backwards in some of your statements, but I presume it's never what you mean).
Right, I meant :hover:before as mentioned in the text. Sorry for that. Here's what is happening: http://design-noir.de/bugzilla/content-url-hover.png There should appear "bar!" instead of the image. To reproduce you have to move the cursor from the right, and only from the right. Otherwise you will hit the line that contains the image and :hover will be triggered before you're over the image. I hope this was clear now, my English is not the best ...
Can confirm. Pulling from above or below image triggers; pulling from right doesn't. Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8) Gecko/20051029 Firefox/1.5
Here's another example (actual excerpt from playable.de): http://design-noir.de/bugzilla/content-url-hover2.html This should show the bug more obvious. In this case, :hover is only triggered from below, because <a> has some line-spacing there (see a{background:lime}). The rest (<img/>) is overlapped by the css-attached image (a:after {content:url(toplink.png); margin-left:-267px;}) which doesn't trigger :hover.
Attached file Testcase —
Maybe my testcase is invalid, but this seems WFM
Comment on attachment 202165 [details] Testcase ><HTML><HEAD> > ><STYLE> > >span {background-color:blue;} >#s1:after { content: url(http://www.mozilla.org/products /firefox/buttons/header.png) } >#s1:hover:after { content: "SUCCESS"} >#s2:after { content: "[:after]" } >#s2:hover:after { content: "SUCCESS" } ></STYLE></HEAD><BODY> ><SPAN id="s1">SPAN1 CONTENT</SPAN><BR/> ><SPAN id="s2">SPAN2 CONTENT</SPAN><BR/> ><BR/> ><PRE>STYLE is > >span {background-color:blue;} >#s1:after { content: url(http://www.mozilla.org/products /firefox/buttons/header.png) } >#s1:hover:after { content: "SUCCESS"} >#s2:after { content: "[:after]" } >#s2:hover:after { content: "SUCCESS" } ></PRE> ></BODY></HTML>
Comment on attachment 202165 [details] Testcase ><HTML><HEAD> > ><STYLE> > >span {background-color:blue;} >#s1:after { content: url(http://www.mozilla.org/products/firefox/buttons/header.png) } >#s1:hover:after { content: "SUCCESS"} >#s2:after { content: "[:after]" } >#s2:hover:after { content: "SUCCESS" } ></STYLE></HEAD><BODY> ><SPAN id="s1">SPAN1 CONTENT</SPAN><BR/> ><SPAN id="s2">SPAN2 CONTENT</SPAN><BR/> ><BR/> ><PRE>STYLE is > >span {background-color:blue;} >#s1:after { content: url(http://www.mozilla.org/products/firefox/buttons/header.png) } >#s1:hover:after { content: "SUCCESS"} >#s2:after { content: "[:after]" } >#s2:hover:after { content: "SUCCESS" } ></PRE> ></BODY></HTML>
No, doesn't work for me. Moving the mouse over the image without hitting any blue doesn't trigger. But maybe it was fixed on the trunk? I'm still on the 1.8 branch.
Really sorry for the spam, i though it was possible to edit attachments. Forget comment 6 and comment 7
I just tried the tests it with a recent trunk nightly; bug is similarly present. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051107 Firefox/1.6a1
Version: Trunk → 1.8 Branch
Version: 1.8 Branch → Trunk
Attached patch Proposed fix — — Splinter Review
This is one option; the other is to walk out of native anonymous content at the entrye to nsEventStateManager::SetContentState, but I like this one more because it's more consistent with how we handle other things. The problem here, of course, was that the nsGenConImageContent was the mHoverContent, and then we nulled out its parent when starting the reframe... so the <span> was no longer in :hover as far as the ESM knew when we resolved style for the new frames.
Attachment #233531 - Flags: superreview?(roc)
Attachment #233531 - Flags: review?(roc)
Assignee: dbaron → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Priority: -- → P3
Hardware: PC → All
Summary: hovering over content, generated with :before/after{content:url(...)}, does not trigger :before/after:hover{content:...} → [FIX]hovering over content, generated with :before/after{content:url(...)}, does not trigger :before/after:hover{content:...}
Target Milestone: --- → mozilla1.9alpha
Attachment #233531 - Flags: superreview?(roc)
Attachment #233531 - Flags: superreview+
Attachment #233531 - Flags: review?(roc)
Attachment #233531 - Flags: review+
Fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Works great, thanks Boris.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: