Closed Bug 145320 Opened 18 years ago Closed 13 years ago

Unable to detect "hover" on tree structure in *.css

Categories

(Core Graveyard :: Skinability, defect, major)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sailfish, Assigned: enndeakin)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

On previous revision levels (e.g., 0.9.4) a *.css skin file could detect hover
on elements in a tree, i.e., treerow, treecol, treecell, treeitem, etc. This no
longer appears to be supported.

When developing skins its often very desireable for a *.css file to be able to
detect this and provide specialized styling to enhance the skin's usability.

This is a request to re-implement hover-detect on tree elements.
confirming since this would be nice to have
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think nice to have is an understatement.  I think this would be essential to
improving the bookmark and history sidebar.  (bug 251910)
Flags: blocking1.9a1?
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Assignee: bugs → skinability
QA Contact: pmac
Neil, how much work is this? bug 251910 would benefit greatly from this.
Blocks: 251910
Fairly simple to implement. This patch uses the following syntax:

treechildren::-moz-tree-row(hover) {
  background-color: yellow;
}

treechildren::-moz-tree-cell-text(hover) {
  text-decoration: underline;
}
Assignee: skinability → enndeakin
Status: NEW → ASSIGNED
Attachment #277525 - Flags: superreview?(neil)
Attachment #277525 - Flags: review?(neil)
Comment on attachment 277525 [details] [diff] [review]
implement hover for trees

Just having a quick prereview in case I noticed anything obvious...

>     if (selection) {
>+      if (aRowIndex == mMouseOverRow)
>+        mScratchArray->AppendElement(nsGkAtoms::hover);
Does this really depend on having a selection (not that you won't have one)?
(In reply to comment #5)
> (From update of attachment 277525 [details] [diff] [review])
> Just having a quick prereview in case I noticed anything obvious...
> 
> >     if (selection) {
> >+      if (aRowIndex == mMouseOverRow)
> >+        mScratchArray->AppendElement(nsGkAtoms::hover);
> Does this really depend on having a selection (not that you won't have one)?
> 

No, I meant to put that outside the condition.
Comment on attachment 277525 [details] [diff] [review]
implement hover for trees

>+    PRInt32 xTwips = pt.x - mInnerBox.x;
>+    PRInt32 yTwips = pt.y - mInnerBox.y;
>+    PRInt32 newrow = GetRowAt(xTwips, yTwips);
A shame xTwips is never used... I wonder why GetRowAt wants it.

Does it make sense (at some point) to be able to script this
e.g. autocomplete could seem to be able to make use of this.
Attachment #277525 - Flags: superreview?(neil)
Attachment #277525 - Flags: superreview+
Attachment #277525 - Flags: review?(neil)
Attachment #277525 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
> Does it make sense (at some point) to be able to script this
> e.g. autocomplete could seem to be able to make use of this.
> 

What are you expecting to be able to script?
I also need to figure out how to make a test for this, probably some combination of reftest like canvas checking with a mouse event simulation.
Flags: in-testsuite?
Depends on: 400999
Keywords: dev-doc-needed
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
documented with the other Mozilla CSS extensions now.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.