use DOMUtils's new pseudo-class lock API for locking pseudo-classes

[harthur]

This uses the new DOMUtils pseudo-class lock API from bug 708874 to toggle :hover, :active, and :focus on the CSS panel.

This is preferable to what Firebug currently has because setting these locks doesn't update the element's actual content state, rather it just updates the element's style. So mousing over another element doesn't lose the :hover, etc.

I can't figure out how to listen for when a new element is selected and listen for when Firebug is closed from the CSS panel. So right now the pseudo-class stays on the element until you manually uncheck it.

[sroussey]

What version of Firebug has (or will have) this API?

It looks like we will need to keep a list of elements whose state we have changed, such that we can reset them on certain events. Obviously, resetting all of them on Firebug close is required. I can add some code to your patch to show how to listen to that particular event.

The other times to reset them seems to still be an open issue though. I often want to set the hover an element then select the child element to see how its CSS rules have changed. So resetting based on selecting another element doesn't seem like the solution. However, I'm not sure what is the solution if just clicking on the content page is not enough. Thoughts?

[harthur]

This API will be in Firefox 13.

Keeping a list would be hard. What Firefox devtools did is keep the lock around only if you move to an element within the hierarchy chain in the breadcrumbs. This allows inspecting parent elements with the lock after locking it on a child element.

You can see the feature in Aurora right now by right clicking the node's selector, instructions here: http://www.youtube.com/watch?feature=player_embedded&v=wuZB6JA4dCU.

[SebastianZ]

As far as I saw the new functions are:

void addPseudoClassLock(in nsIDOMElement aElement, in DOMString aPseudoClass);
void removePseudoClassLock(in nsIDOMElement aElement, in DOMString aPseudoClass);
bool hasPseudoClassLock(in nsIDOMElement aElement, in DOMString aPseudoClass);
void clearPseudoClassLocks(in nsIDOMElement aElement);

So we obviously need to keep track of the elements with locked state to be able to call clearPseudoClassLocks() on them. Why do the functions not support a nsIDOMNodeList or why isn't there a function to clear the pseudo-class locks of all elements on the page?
We need to make sure the UX for this is clear. If the states should be reset by some events, it might be better to create a different UI than the Style side panel options menu items we have now. See also issue 3230.
Heather, do you know, if other pseudo-classes than :active, :hover and :focus are supported? I referring to your comment on bug 708874. See issue 4131.

Sebastian

[harthur]

It doesn't support NodeLists. You can iterate over a NodeList and use any of the functions on each node individually.

Check out the UI for this in the built-in Firefox devtools, I'd recommend playing around with it. It adds an orange ":hover" to the selectors in the breadcrumbs, for one.

Devtools removes the lock when you inspect a new node altogether, unless you are just navigating up the tree with the breadcrumbs, then the lock is retained. This covers all the most common use cases for wanting to keep a lock around.

All other pseudo-classes are supported, but the :visited issue is a whole different issue altogether. :visited rules aren't exposed to getComputedStyle() or getCSSStyleRules() due to a privacy change in Firefox, see bug 713106, and setting a pseudo-class lock isn't going to change that.

[SebastianZ]

Check out the UI for this in the built-in Firefox devtools, I'd recommend playing around with it. It adds an orange ":hover" to
the selectors in the breadcrumbs, for one.

I did that and it's pretty hidden like in Firebug. I would like to make these options more obvious and move them away from the normal options, because they are not panel specific but element specific. At least they should be put into the context menu of the elements. That doesn't make it much more obvious but at least they would be right placed.
Setting a lock should also be indicated inside the HTML panel somehow, e.g. by changing the background color of the node or something like that.

All other pseudo-classes are supported

That's great. So maybe there should be an item for each one? Or do you think this would congest the UI?

but the :visited issue is a whole different issue altogether

Thanks for the hint.

Sebastian

[sroussey]

I did that and it's pretty hidden like in Firebug

So hidden in fact, that I can figure out how to do it... :(

[harthur]

Devtools is planning on putting it in a special new node-specific menu on that "infobar" (the thing that show's the node's selector) soon to make it more discoverable. The HTML view could be a good place to put the control in Firebug, as a context menu on the elements of the tree.

I don't think you want an item for each pseudo-class in existence, and there are too many them. There's only really need for :hover, :active, and :focus because those are dynamic and hard to pin down when debugging.

If this is going to take a long time to figure out it might be worthwhile to just hook up the new API to the current UI at first, as it's still a significant improvement in UX.

[SebastianZ]

Heather, would it be possible to help us here with an updated patch according to the things we discussed?

Sebastian

[harthur]

It might be a better use of time for someone more familiar with Firebug's code to do this. Were the functionality and UI specified?

[SebastianZ]

Were the functionality and UI specified?

In my previous comment I tried to explain how I imagine it to work. We discussed this in a conf call earlier and it seemed people agreed to that UI.

Sebastian

[harthur]

I wouldn't be able to get around to it anytime soon, but I'm here to answer questions.

[SebastianZ]

After hesitating for that long I decided to use your patch. Currently I applied it to a separate branch.
The reason I did so now is that the patch really has benefits over what we currently have. I put the UI changes into a new issue.

Sebastian