Closed
Bug 503813
Opened 16 years ago
Closed 15 years ago
changing generated content on :hover does not work when the hovering is over the generated content
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
status1.9.1 | --- | ? |
People
(Reporter: dev-null, Assigned: roc)
References
Details
(Keywords: regression, testcase)
Attachments
(3 files)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090712 Minefield/3.6a1pre
Steps to reproduce:
1. Open the testcase.
2. Mouse over "generated content" at the right of "testA".
Actual result:
Does nothing.
Expected result:
:hover should work like testB, i.e. "generated content" in testA should change to red "content is used with hover".
20080817033619 works fine.
20080818033342 fails.
Likely from bug 238072.
Flags: wanted1.9.1.x?
Flags: blocking1.9.2?
Reporter | ||
Comment 1•16 years ago
|
||
When this bug occurs with <a>, click on the generated content does not work first time.
In this testcase, clicking on "generated content" at the right of "testA" once does nothing.
When click again, it follows the link.
Is this the same bug? Or another separate bug is needed?
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → roc
Assignee | ||
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Updated•15 years ago
|
status1.9.1:
--- → ?
Flags: wanted1.9.1.x?
Summary: :hover does not work with generated content → changing generated content on :hover does not work when the hovering is over the generated content
OS: Windows XP → All
Hardware: x86 → All
Assignee | ||
Comment 2•15 years ago
|
||
GetContentForEvent should return the nearest enclosing non-generated content.
This function is used in quite a few places but I'm pretty sure this is the right thing to do in all those cases. We simply shouldn't be targeting DOM events at generated content.
Attachment #397605 -
Flags: review?(dbaron)
Assignee | ||
Comment 3•15 years ago
|
||
This patch fixes both testcases in this bug.
Whiteboard: [needs review]
Comment on attachment 397605 [details] [diff] [review]
fix
r=dbaron
But I think you should also remove nsHTMLCanvasFrame::GetContentForEvent; it's now the only GetContentForEvent implementation that doesn't do this fixup, and as far as I can tell it's entirely unneeded. (I can't see how it can occur in generated content now, but we may as well avoid problems if it ever can.)
Attachment #397605 -
Flags: review?(dbaron) → review+
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review] → [needs landing]
Assignee | ||
Comment 5•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 1.9.2 landing]
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs 1.9.2 landing] → [needs 192 landing]
Comment 7•15 years ago
|
||
Wed Sep 02 14:46:33 2009 +1200 (at Wed Sep 02 14:46:33 2009 +1200):
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/41c751e0aab1
status1.9.2:
--- → beta1-fixed
Whiteboard: [needs 192 landing]
Comment 8•15 years ago
|
||
Confirmed fixed in 1.9.2.
You need to log in
before you can comment on or make changes to this bug.
Description
•