Last Comment Bug 694019 - we should be able to highlight and inspect a :pseudo element
: we should be able to highlight and inspect a :pseudo element
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Developer Tools: Inspector (show other bugs)
: Trunk
: x86 Linux
: P2 normal with 1 vote (vote)
: Firefox 26
Assigned To: Brian Grinstead [:bgrins]
:
: Patrick Brosset <:pbro>
Mentors:
: 712495 773130 836520 856576 877312 882571 (view as bug list)
Depends on: 717919 remote-inspector 914079
Blocks: DevToolsPaperCuts 663830 gaia-devtools
  Show dependency treegraph
 
Reported: 2011-10-12 08:16 PDT by Paul Rouget [:paul]
Modified: 2013-09-26 18:04 PDT (History)
26 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Mockup of possible UI for Rules view (120.45 KB, image/png)
2012-01-04 14:08 PST, Heather Arthur [:harth]
no flags Details
work in progress (3.44 KB, patch)
2013-01-31 17:08 PST, Tetsuharu OHZEKI [:tetsuharu] [UTC+9]
no flags Details | Diff | Splinter Review
wip2 (3.35 KB, patch)
2013-01-31 23:43 PST, Tetsuharu OHZEKI [:tetsuharu] [UTC+9]
no flags Details | Diff | Splinter Review
proposal-v3 (15.97 KB, patch)
2013-02-01 09:36 PST, Tetsuharu OHZEKI [:tetsuharu] [UTC+9]
no flags Details | Diff | Splinter Review
breadcrumb mockup (22.05 KB, image/png)
2013-02-04 10:25 PST, Tetsuharu OHZEKI [:tetsuharu] [UTC+9]
no flags Details
694019-1.patch (22.81 KB, patch)
2013-09-03 01:14 PDT, Brian Grinstead [:bgrins]
paul: review+
Details | Diff | Splinter Review
694019-2.patch (37.74 KB, patch)
2013-09-04 00:04 PDT, Brian Grinstead [:bgrins]
pbrosset: feedback+
Details | Diff | Splinter Review
694019-3.patch (38.99 KB, patch)
2013-09-04 01:50 PDT, Brian Grinstead [:bgrins]
paul: review-
Details | Diff | Splinter Review
694019-4.patch (39.87 KB, patch)
2013-09-04 03:14 PDT, Brian Grinstead [:bgrins]
mratcliffe: review+
Details | Diff | Splinter Review

Description Paul Rouget [:paul] 2011-10-12 08:16:43 PDT
It could be useful to be able to inspect pseudo elements like :after and :before.
Comment 1 Sebastian Zartner 2011-11-24 22:11:56 PST
http://code.google.com/p/fbug/issues/detail?id=537 is some kind of related, because Firebug at least already displays pseudo elements.
Comment 2 Heather Arthur [:harth] 2011-12-09 15:06:20 PST
As an intermediate step, can we just show the all the pseudo-element rules for an element in the rule view?
Comment 3 Rob Campbell [:rc] (:robcee) 2012-01-03 05:54:46 PST
also things like, :first-child, :first-line, :first-letter, ...
Comment 4 Paul Rouget [:paul] 2012-01-03 06:21:02 PST
(In reply to Rob Campbell [:rc] (robcee) from comment #3)
> also things like, :first-child

This is a pseudo class, and we already support that, because :first-child reference an existing DOM element.

> :first-line, :first-letter, ...

Yeah, we need to support these too.
Comment 5 Paul Rouget [:paul] 2012-01-03 06:21:18 PST
*** Bug 712495 has been marked as a duplicate of this bug. ***
Comment 6 Heather Arthur [:harth] 2012-01-04 14:08:06 PST
Created attachment 585888 [details]
Mockup of possible UI for Rules view

Here's a possible UI for showing pseudo-element rules in the Rules view. It just adds a section for each pseudo-element, separated by darker headers.
Comment 7 Paul Rouget [:paul] 2012-01-05 03:26:49 PST
(In reply to Heather Arthur [:harth] from comment #6)
> Created attachment 585888 [details]
> Mockup of possible UI for Rules view
> 
> Here's a possible UI for showing pseudo-element rules in the Rules view. It
> just adds a section for each pseudo-element, separated by darker headers.

(sorry, long comment, thinking out loud)

So you're suggesting that, for each element, we have an additional UI inside our Node Centric tools, to show the pseudo-elements.
That would mean extending the UI for the Rule View, for the Property View and for the other coming tools.

Can we imagine, instead, a way to highlight and inspect pseudo elements directly?

If highlighting a pseudo-element is too tricky (and I guess it is), we can imagine just extending the Rule View and the Property View then (other tools might not need to show the pseudo-elements).

To avoid confusion, I would hide (fold) the pseudo-element related UI in a single line at first:

             +------------------------------+
             |                              |
             ||inline:                      |
             |element {                     |
             |}                             |
             |                              |
             ||inline:10                    |
             |#main {                       |
             |...                           |
             |}                             |
             |                              |
             |------------------------------|
             | [+] :before, :first-line     |
             |------------------------------|
             |                              |
             |                              |
             |                              |
             +------------------------------+

Clicking on the [+] would unfold the pseudo-elements rules.

But, that would be too much visually-complex for the Property View (where a folding mechanism is already there, and that would mean scrolling very far to get the pseudo-elements properties).

And I don't think we should have 2 different UIs for Rules and Properties.

So here is another idea: for all of the tools, we could add, at the bottom, a dropdown menu that would let the user select a pseudo-element (if any):


             +------------------------------+
             |                              |
             ||inline:                      |
             |element {                     |
             |}                             |
             |                              |
             ||inline:10                    |
             |#main {                       |
             |...                           |
             |}                             |
             |                              |
             |                              |
             |                              |                                     |
             |                              |                                     |
             |                              |      |                              |
             |                              |      |                              |
             |                              |      +------------------------------+
             |                              |      |                              |
             |                              |      | x  Main element              |
             |                              |      |    :before                   |
             |                              |      |    :after                    |
             |                              |      |                              |
             +---+--------------------------+      |---+--------------------------|
             | ^ |available pseudo-elements | +--> | ^ |available pseudo-elements |
             +---+--------------------------+      +------------------------------+


That could directly be part of the sidebar (not the tools themselves).
The tools would need a way to be invoked for a pseudo-element.

Another option could be to add an arrow in the the breadcrumbs-current-node to let the user select the pseudo element (and, at the same time, let the user check the pseudo *classes*).

I will bring this problem to our UI-meeting next week. For now, I think the breadcrumbs idea is the best one.
Comment 8 Rob Campbell [:rc] (:robcee) 2012-01-05 06:35:43 PST
I think Heather was proposing adding :pseudo element rules to the Rules view alone. I don't think we'd want to show those in the Property view, for example because they wouldn't make sense there. I think it's a fine suggestion.

Collapsing pseudo elements might be nice to have, though it requires extra clicks to make them visible. I think heather's suggestion is nice and simple.
Comment 9 Paul Rouget [:paul] 2012-01-05 07:01:38 PST
(In reply to Rob Campbell [:rc] (robcee) from comment #8)
> I think Heather was proposing adding :pseudo element rules to the Rules view
> alone. I don't think we'd want to show those in the Property view, for
> example because they wouldn't make sense there.

Why? What about getComputedStyle(element, "after")?

> Collapsing pseudo elements might be nice to have, though it requires extra
> clicks to make them visible.

Why would that be a problem? I prefer that rather than having the style of the pseudo elements popping up as soon as you highlight an element that has pseudo elements in it.

> I think heather's suggestion is nice and simple.

It is nice a simple for the Rule View if we consider that the ability to inspect a pseudo element is strictly restricted to the Rule View. But I don't see why we would do that.

Also, the first time I saw the mockup, it took me a while to understand that I was looking at the style of *several* elements. This is confusing. I think we want, at least, to let the user explicitly ask for the pseudo-element style. Then the user will understand that he will see the pseudo-elements style.
Comment 10 Rob Campbell [:rc] (:robcee) 2012-01-05 07:12:43 PST
I'm not sure this bug is the best place for this discussion, but here we are.

(In reply to Paul Rouget [:paul] from comment #9)
> (In reply to Rob Campbell [:rc] (robcee) from comment #8)
> > I think Heather was proposing adding :pseudo element rules to the Rules view
> > alone. I don't think we'd want to show those in the Property view, for
> > example because they wouldn't make sense there.
> 
> Why? What about getComputedStyle(element, "after")?

What about it? How do you display those rules in the property view so that it doesn't confuse the developer? I guess you could put a new section under an :after heading with all the applied styles, but that feels funny.

Maybe we should tackle how to deal with the property view in a separate bug rather than try to do everything in here.

 > > Collapsing pseudo elements might be nice to have, though it requires extra
> > clicks to make them visible.
> 
> Why would that be a problem? I prefer that rather than having the style of
> the pseudo elements popping up as soon as you highlight an element that has
> pseudo elements in it.

People don't like clicking. They want to see everything immediately.

> > I think heather's suggestion is nice and simple.
> 
> It is nice a simple for the Rule View if we consider that the ability to
> inspect a pseudo element is strictly restricted to the Rule View. But I
> don't see why we would do that.

ok, I guess there's an argument to have things in other views as well, but we should probably deal with those in separate bugs.

> Also, the first time I saw the mockup, it took me a while to understand that
> I was looking at the style of *several* elements. This is confusing. I think
> we want, at least, to let the user explicitly ask for the pseudo-element
> style. Then the user will understand that he will see the pseudo-elements
> style.

Not really. As "Pseudo Elements" they don't really exist in the DOM per se. They are an artifact of styling applied to the current element.

I do think it'd be nice to be able to highlight pseudo elements in the inspector but have a feeling that'll require a bit of extra trickery. I think this sort of solution in this bug is a good stop-gap measure.
Comment 11 Paul Rouget [:paul] 2012-01-05 07:34:57 PST
(In reply to Rob Campbell [:rc] (robcee) from comment #10)
> I'm not sure this bug is the best place for this discussion, but here we are.
> 
> (In reply to Paul Rouget [:paul] from comment #9)
> > (In reply to Rob Campbell [:rc] (robcee) from comment #8)
> > > I think Heather was proposing adding :pseudo element rules to the Rules view
> > > alone. I don't think we'd want to show those in the Property view, for
> > > example because they wouldn't make sense there.
> > 
> > Why? What about getComputedStyle(element, "after")?
> 
> What about it? How do you display those rules in the property view so that
> it doesn't confuse the developer?

In this mockup, the Rule view is split in two: regular element rules + pseudo-elements rules.
For the Property view, we would do the same things: regular element properties + pseudo-elements properties.

> I guess you could put a new section under
> an :after heading with all the applied styles, but that feels funny.

But why wouldn't that feel funny with the Rule View? It is exactly what this mockup shows.

> Maybe we should tackle how to deal with the property view in a separate bug
> rather than try to do everything in here.

We want the user to be able to debug the style of the pseudo elements. There is no reason to let him use the Rule View but not the Property View, right? We need both.

So then, there are 2 approaches:
1) you show the regular element and the its pseudo-elements in the same (split) view; // current mockup
2) you give a way to the user to select a pseudo-element, so only the pseudo-element style is shown.

1) is easier to implement but comes with different UIs depending on the tool (at least property and rule). 2) comes with a consistent behavior.

>  > > Collapsing pseudo elements might be nice to have, though it requires
> extra
> > > clicks to make them visible.
> > 
> > Why would that be a problem? I prefer that rather than having the style of
> > the pseudo elements popping up as soon as you highlight an element that has
> > pseudo elements in it.
> 
> People don't like clicking. They want to see everything immediately.

Well, you can't show everything, it can get confusing.

> > > I think heather's suggestion is nice and simple.
> > 
> > It is nice a simple for the Rule View if we consider that the ability to
> > inspect a pseudo element is strictly restricted to the Rule View. But I
> > don't see why we would do that.
> 
> ok, I guess there's an argument to have things in other views as well, but
> we should probably deal with those in separate bugs.

I think we need a generic solution.

> > Also, the first time I saw the mockup, it took me a while to understand that
> > I was looking at the style of *several* elements. This is confusing. I think
> > we want, at least, to let the user explicitly ask for the pseudo-element
> > style. Then the user will understand that he will see the pseudo-elements
> > style.
> 
> Not really. As "Pseudo Elements" they don't really exist in the DOM per se.
> They are an artifact of styling applied to the current element.
> 
> I do think it'd be nice to be able to highlight pseudo elements in the
> inspector but have a feeling that'll require a bit of extra trickery.

I am not saying we should highlight the pseudo-element, but that we should treat them
like regular elements in the node-centric tools.

> I think this sort of solution in this bug is a good stop-gap measure.

Do we need stop-gap measure? Can't we get a clean and consistent solution?

How do you feel about being able to (sub)select a pseudo element from, either the sidebar, or the breadcrumbs?
Comment 12 Michael Ratcliffe [:miker] [:mratcliffe] 2012-01-05 09:02:51 PST
Personally I think that the sidebar approach makes a lot of sense. Selecting pseudo element should be possible in all tools.

Just couldn't resist joining the chat.
Comment 13 Paul Rouget [:paul] 2012-01-05 09:09:19 PST
(In reply to Michael Ratcliffe from comment #12)
> Personally I think that the sidebar approach makes a lot of sense. Selecting
> pseudo element should be possible in all tools.

The question is more about if the selection should affect all the tools, or just the current tool.

If you select :after while you're looking at the Rule View, then switch to the Property View, what do you want to see? The regular node properties of the pseudo-element properties?
Comment 14 Michael Ratcliffe [:miker] [:mratcliffe] 2012-01-05 09:18:58 PST
Personally I think that it would be information overload if you could always see pseudo elements in every tool ... just imaging how long the list could get in the property view.

Selecting pseudo elements is really just doing something that can't easily be done in the highlighter but it would be cool if they could be selected like any other node.

If selecting them in the highlighter is not possible I would say that selecting them should be like selecting any other element and affect all tools.
Comment 15 Paul Rouget [:paul] 2012-01-05 09:28:04 PST
(In reply to Michael Ratcliffe from comment #14)
> Personally I think that it would be information overload if you could always
> see pseudo elements in every tool ... just imaging how long the list could
> get in the property view.

Yeah. We should show them only if the user ask for it.

> Selecting pseudo elements is really just doing something that can't easily
> be done in the highlighter but it would be cool if they could be selected
> like any other node.
> 
> If selecting them in the highlighter is not possible I would say that
> selecting them should be like selecting any other element and affect all
> tools.

Exactly.
Comment 16 Heather Arthur [:harth] 2012-01-10 00:13:46 PST
I see you all's point about the computed style and I just thought of something - what if you have rules like:

#main {
  font-family: Helvetica;
}

#main::first-line {
  font-family: Arial;
}

If you were inspecting the ::first-line pseudo-element you'd want to see the Helvetica crossed out because it'd be overridden. However if you were inspecting the main element it wouldn't be crossed out. To represent this nicely in the rules view we'd want to be able to switch completely between the main element and its pseudo-elements like Paul's second idea.

I say we go all the way, like Rob and Mike were saying, and allow selecting the pseudo-element in the highlighter: outlining the pseudo-element's bounding box, adding the pseudo-element to the infobar selector, and showing the rules and computed style for the pseudo-element in the sidebar.

If you right-click "Inspect Element" within the bounds of a pseudo-element, it'll inspect that pseudo-element. It could also be a sub-selection thing like we're doing with pseudo-classes, and we could allow sub-selection from the infobar and breadcrumb. Technically, pseudo-elements are rendered exactly like children, so we could represent that weirdness in the breadcrumbs and maybe HTML view eventually, though that is sketchy.

Doing it all the way would require some platform work and serious hashing out, all the "extra trickery", but I think anything less would be incorrect, inconsistent, or not apparent. One of those three, and if we had to do something in the meantime, I don't know about sub-selecting a pseudo-element without the highlighter bounding box changing. Fbug and Chrome seem to err on the side of apparentness and visual correlation by just showing the rules straight up, but there are definitely consistency issues there.
Comment 17 Michael Ratcliffe [:miker] [:mratcliffe] 2012-01-10 03:06:51 PST
You describe the situation perfectly. Highlighting pseudo-elements using the highlighter just like other elements is certainly the best way to go. I would suggest calling the method getNodeForTool() and say that it should return the node at the cursor position (using screen co-ordinates) regardless of whether the node is in an iframe etc. In fact, if it could also be used to inspect chrome elements it would be even nicer.
Comment 18 James Socol [:jsocol, :james] 2012-01-10 07:01:58 PST
(In reply to Heather Arthur [:harth] from comment #16)
> I say we go all the way, like Rob and Mike were saying, and allow selecting
> the pseudo-element in the highlighter: outlining the pseudo-element's
> bounding box, adding the pseudo-element to the infobar selector, and showing
> the rules and computed style for the pseudo-element in the sidebar.

Firebug just shows the rules for pseudo-children at the top of the list of rules for the selected element, but as a web dev being able to use the highlighter to pick the pseudo-element would be fantastic.
Comment 19 Dave Camp (:dcamp) 2012-01-17 08:34:05 PST
Triage, filter on pegasus.
Comment 20 Paul Rouget [:paul] 2012-01-17 14:52:51 PST
The "inspector pseudo elt" menu should live in the pseudo-bar. bug 717919.
Comment 21 Paul Rouget [:paul] 2012-07-12 02:26:09 PDT
*** Bug 773130 has been marked as a duplicate of this bug. ***
Comment 22 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-01-21 09:38:48 PST
Do we have any plan to fix this problem in recent versions?
This must need to inspect styles.
Comment 23 Paul Rouget [:paul] 2013-01-21 09:45:45 PST
Nothing planned yet.
Comment 24 Paul Rouget [:paul] 2013-01-30 18:18:25 PST
*** Bug 836520 has been marked as a duplicate of this bug. ***
Comment 25 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-01-31 16:57:27 PST
At this time, we cannot get the style rules of ::(-moz-)selection with using inIDOMUtils.getCSSStyleRules() or other methods until fix bug 836977. But we can get pseudo elements. So we should defer only inspecting ::(-moz-)selection.
Comment 26 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-01-31 17:08:08 PST
Created attachment 708862 [details] [diff] [review]
work in progress

This is work in progress.
I think that we should implement inspecting ::(-moz-)selection after fixed bug 836977.

Paul, should we follow the mockup UI (attachment 585888 [details]) ?
And what else do we need to resolve this bug?
Comment 27 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-01-31 23:43:14 PST
Created attachment 708960 [details] [diff] [review]
wip2

Support "::(-moz-)selection" pseudo-element.
It's to jump to conclusions that we cannot support "::(-moz-)selection" until fixed bug 836977.
Comment 28 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-02-01 09:36:32 PST
Created attachment 709095 [details] [diff] [review]
proposal-v3

Changed from wip-v2:
* Follow the mockup UI.
* Fix some bugs.
Comment 29 Paul Rouget [:paul] 2013-02-04 06:20:18 PST
Comment on attachment 709095 [details] [diff] [review]
proposal-v3

This approaches is functional. It works and brings some information we didn't have before. Is it possible to show pseudo-element in the computed view as well?

---

That said, could we, instead of showing pseudo elements in the RuleView/ComputedView, let the user select the pseudo-element from the context menu in the infobar (below the pseudo-classes)? Then it would be possible to only inspect a pseudo element (RuleView, ComputedView and Layout would be only be about this pseudo-element)? That would mean updating the Selection.jsm object to handle pseudo-element nodes.

The code might be a little more complex. Selection.jsm would need to expose 2 new functions: `isPseudo()` and `getPseudoName()`. And all the tools using `inspector.selection` would need to handle this special case.

I hope this is clear. Tetsuharu, what do you think?
Comment 30 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-02-04 10:03:42 PST
(In reply to Paul Rouget [:paul] from comment #29)
> This approaches is functional. It works and brings some information we
> didn't have before. Is it possible to show pseudo-element in the computed
> view as well?

Thank you, Paul.
This is not possible to show pseudo-element in the computed view, because I thought that the current comuputed view is just only about the selected element. So it's not suitable that to show pseudo-element's styles.


> That said, could we, instead of showing pseudo elements in the
> RuleView/ComputedView, let the user select the pseudo-element from the
> context menu in the infobar (below the pseudo-classes)? Then it would be
> possible to only inspect a pseudo element (RuleView, ComputedView and Layout
> would be only be about this pseudo-element)? That would mean updating the
> Selection.jsm object to handle pseudo-element nodes.
> 
> The code might be a little more complex. Selection.jsm would need to expose
> 2 new functions: `isPseudo()` and `getPseudoName()`. And all the tools using
> `inspector.selection` would need to handle this special case.

Do you mean the inspector highlights the pseudo-element?
If it is so, I think it is good sounds. But it might be complex in some case which is like ::selection.

I don't think it's not good for display the infomation about pseudo-elements. Pseudo-elements is not state. It's different from pseudo-classes. Using same (or very similar) UI is not good in this case. If we'll add similar UI, we should highlight the pseudo-element (But it have above problem. :'-(

I thought we'll implement the mode fot DOM Tree view whch shows virtual pseudo-elements. But also I don't know well it's enable on our inspector design and whether or not its UI mode is really good for debugging.

The better (but not best) approach which I thought at this moment is that we add toggle switch which inspect only specified pseudo-elements to Computed view.

Paul, how do you think about these?
Comment 31 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-02-04 10:25:35 PST
Created attachment 709775 [details]
breadcrumb mockup

(In reply to Paul Rouget [:paul] from comment #29)
> That said, could we, instead of showing pseudo elements in the
> RuleView/ComputedView, let the user select the pseudo-element from the
> context menu in the infobar (below the pseudo-classes)? Then it would be
> possible to only inspect a pseudo element (RuleView, ComputedView and Layout
> would be only be about this pseudo-element)? That would mean updating the
> Selection.jsm object to handle pseudo-element nodes.

(This is supplement of comment #30)
I flash the idea!
How about add showing pseudo-element to breadcrumb, not change the state. (Please see mockup)
I think this can resolve some problem which I commented!
Comment 32 Paul Rouget [:paul] 2013-02-14 07:00:44 PST
> But it might be complex in some case which is like ::selection.

We don't have to support them all. I'd focus on before/after (maybe first-line/letter too).

> It's different from pseudo-classes. Using same (or very similar) UI is not good in this case.

It's different, but part of the "logic" (pseudo-something).

Below the pseudo-classes, we could add some text like this:


          +--------------------+
          |  Copy Inner HTML   |
          |  Copy Outer HTML   |
          |  Delete Node       |
          +--------------------+
          |Toggle pseudo Class |
          |--------------------|
          |  :hover            |
          |  :focus            |
          |  :active           |
          +--------------------+
          |Select pseudo elt   |
          |--------------------|
          |  :before           |
          |  :after            |
          |  :first-line       |
          +--------------------+

This would be available from the breadcrumbs and the infobar.

And I like the breadcrumbs mockup.

What do you think?
Comment 33 Tetsuharu OHZEKI [:tetsuharu] [UTC+9] 2013-02-15 08:51:37 PST
I'm trying to implement the breadcrumbs mockup & the context menu to select pseudo element. I think Paul's suggestion is good. But Its works is proceeding with difficulty.

At the current stage, 

* We don't have a way to highlight the pseudo element (e.g. ::first-line). So we can highlight the element which is root of the pseudo element. Should we file a new bug which relate to bug 839458?

* Implement the breadcrumbs mockup is a little more complex (Paul's guess was correctly.)  I can't say with confidence it, but we may need some abstract representation Selection.jsm which represents DOM Node that we select now.

* I don't find a way to pass the information about that Inspector is selecting the pseudo element now. But this may be caused from my knowledge lacking to know about devtools design. It would be helpful if you answer more information when I get stuck.

And sadly, my main works is busy now...
It may need a times until I finish to make the patch.
Comment 34 Paul Rouget [:paul] 2013-03-08 07:06:41 PST
(In reply to Tetsuharu OHZEKI [:saneyuki_s] from comment #33)
> I'm trying to implement the breadcrumbs mockup & the context menu to select
> pseudo element. I think Paul's suggestion is good. But Its works is
> proceeding with difficulty.
> 
> At the current stage, 
> 
> * We don't have a way to highlight the pseudo element (e.g. ::first-line).
> So we can highlight the element which is root of the pseudo element. Should
> we file a new bug which relate to bug 839458?

We could just highlight the parent node for now.
But we'll need to get something like getBoundingClientRect for pseudo elements.

> * Implement the breadcrumbs mockup is a little more complex (Paul's guess
> was correctly.)  I can't say with confidence it, but we may need some
> abstract representation Selection.jsm which represents DOM Node that we
> select now.

Via Selection.jsm, we can define a new kind of "node", but thinking about it, we might prefer this approach: in Selection.jsm, we could add:
> isPseudoElementSelected: true/false
> getPseudoElementName(): ":before"
> setPseudoElementName()

Then anyone using Selection.jsm, can also support pseudoElements, but this would be optional. And that would me the implement simpler.

> * I don't find a way to pass the information about that Inspector is
> selecting the pseudo element now. But this may be caused from my knowledge
> lacking to know about devtools design. It would be helpful if you answer
> more information when I get stuck.
> 
> And sadly, my main works is busy now...
> It may need a times until I finish to make the patch.

I hope that answers most of your questions. If you need any more help, let me know. I'll try to answer sooner this time :)
Comment 35 Girish Sharma [:Optimizer] 2013-03-11 04:45:50 PDT
About the issue on how to show pseudo elements, and/or allow user to select pseudo elements using the rules/computed view sidebar :

we can have a top toolbar for rules view (computed already has one) and add cog wheel buttons on it. This toolbar can then act like place for all the options (which will come in future) like choosing the color type (authored, rgb, hex or hsla), choosing the state of the element (hover, focus etc) and ofcourse, choosing the pseudo element (before, after etc.)

Chrome also does something similar, and I like only this thing in their sidebar :)
Comment 36 Paul Rouget [:paul] 2013-03-13 09:13:14 PDT
I don't want this to be rule-view specific, but generic (inspector scope). What Chrome does is not optimal in this way.
Comment 37 Girish Sharma [:Optimizer] 2013-03-13 09:14:42 PDT
I was saying in addition to the breadcrumbs context menu. Context menu can remain hidden from the user sometimes.
Comment 38 Julen Ruiz Aizpuru 2013-05-20 00:35:52 PDT
*** Bug 856576 has been marked as a duplicate of this bug. ***
Comment 39 J. Ryan Stinnett [:jryans] (use ni?) 2013-05-29 13:43:54 PDT
*** Bug 877312 has been marked as a duplicate of this bug. ***
Comment 40 Heather Arthur [:harth] 2013-05-30 22:23:55 PDT
Implementation should probably wait for remote inspector (bug 805526)
Comment 41 Anthony Ricaud (:rik) 2013-07-21 11:33:44 PDT
*** Bug 882571 has been marked as a duplicate of this bug. ***
Comment 42 Brian Grinstead [:bgrins] 2013-09-03 01:14:51 PDT
Created attachment 798733 [details] [diff] [review]
694019-1.patch

Tests are still WIP
Comment 43 Paul Rouget [:paul] 2013-09-03 01:28:11 PDT
Comment on attachment 798733 [details] [diff] [review]
694019-1.patch

s/h2/div.
Comment 44 Brian Grinstead [:bgrins] 2013-09-04 00:04:27 PDT
Created attachment 799311 [details] [diff] [review]
694019-2.patch

Move pseudo elements to front inside of collapsible group, and expand tests
Comment 45 Brian Grinstead [:bgrins] 2013-09-04 01:50:51 PDT
Created attachment 799353 [details] [diff] [review]
694019-3.patch

Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=054cac889be8.  Added tests for expand/collapse functionality.
Comment 46 Paul Rouget [:paul] 2013-09-04 02:20:06 PDT
Comment on attachment 799353 [details] [diff] [review]
694019-3.patch

s/sortRules/sortRulesForPseudoElement/
s/markOverriddenPseudo/markOverridden/
s/layout.css.show_pseudo_elements/devtools.inspector.expand_pseudoelement_rules/

>+    return !!this._showPseudoElements;
>+ !!this.showPseudoElements;
Double bangs are useless here. And in some other places. Only use !! when you're not sure about the type.

> +      try {
> +        this._showPseudoElements = Services.prefs.getBoolPref("layout.css.show_pseudo_elements");
> +      }
> +      catch(e) { }

No need to try catch. Add a pref here:
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#1077

s/thisElement/selectedElement/ (in the property as well)

> +.ruleview .theme-gutter {

Do you need .ruleview?

> +.ruleview-rule-pseudo-element {

Add a \n before.


Please ask :miker for the next review.
Mike, if you can focus on devtools/server/actors/styles.js...
Comment 47 Brian Grinstead [:bgrins] 2013-09-04 03:14:53 PDT
Created attachment 799388 [details] [diff] [review]
694019-4.patch

Updates from review by :paul.  Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=3e320a08036a
Comment 48 Michael Ratcliffe [:miker] [:mratcliffe] 2013-09-04 06:36:37 PDT
Comment on attachment 799388 [details] [diff] [review]
694019-4.patch

Review of attachment 799388 [details] [diff] [review]:
-----------------------------------------------------------------

Lookin good!
Comment 49 Brian Grinstead [:bgrins] 2013-09-04 06:42:28 PDT
Can you please check this in?
Comment 50 Michael Ratcliffe [:miker] [:mratcliffe] 2013-09-04 08:55:27 PDT
https://hg.mozilla.org/integration/fx-team/rev/4b65dc0a16cd
Comment 51 Wes Kocher (:KWierso) 2013-09-04 17:05:17 PDT
https://hg.mozilla.org/mozilla-central/rev/4b65dc0a16cd
Comment 52 Paul Rouget [:paul] 2013-09-26 18:04:51 PDT
(wrong author in the commit)

Note You need to log in before you can comment on or make changes to this bug.