Dymaxion Reporter
	Description • 22 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

The DOM Inspector doesn't recognize CSS pseudo-elements, they're simply ignored
silently.

Reproducible: Always

Steps to Reproduce:
1. Open a page that uses CSS pseudo-elements.
2. Look for them in the inspector.


Actual Results:  
Nothing found.

Expected Results:  
CSS pseudo-elements found and selectable like all other elements.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 22 years ago

They are not in the DOM, unlike other elements....  We _could_ try to show them,
but it would be quite slow (probe for a pseudo style context, etc).

	Dymaxion Reporter
	Comment 2 • 22 years ago

Maybe an option to manually probe for pseudo-elements, then, instead of of
always looking for them?  A context menu or a button that allows you to trigger
such a search would solve the problem.  On the other hand, we could
automatically trigger the search for each element as they're selected in the
inspector.  Either wouldn't be perfect (doesn't show you that they're their if
you don't know to look), but it would let you play with them if you knew where
to look, which is most of the issue.

	Alex Vincent [:WeirdAl]
	Comment 3 • 22 years ago

They show up in the Stylesheets view.  Because as bz pointed out they are not
technically a part of the styled element except when the pseudo-element takes
effect, this is at best an enhancement, and may be invalid.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 22 years ago

This can't be invalid.  There's no basis for marking it invalid.  It's either
wontfix, or will be fixed.

	Chris Casciano
	Comment 5 • 22 years ago

ooo... looks like this bug exists after all...

Re: I've looked around and I can't seem to find them in the Style View ('CSS
Style Rules' pane, right?) at least not for the element they're associated to.
Pseudo classes like :visited seem to when they're applied, but :before,
:first-letter, etc don't appear to. (attaching a test doc in a sec)

After a short back and forth with bz on IRC i'm inclined to agree that they
shouldn't appear as nodes, but that the 'CSS Style Rules' view is the most
appropriate place... so in my testcase HTML>BODY>P>A would have something like
the following listed (my cascade order is probably off):

*:-moz-any-link   resource:///....
*:-moz-any-link   about:Pref....
*:visited         about:Pref....
a                 http://....
a:before          http://....
a:after           http://....
a:visited         http://....


As to enhancement, I agree, unless this should be working already as Alex eluded
to... then its probably trivial.

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 22 years ago

They show up in the Style Sheets view.  But yes, not in the style rules view.

It's not exactly clear to me how we'd do them in the style rules view given the
current style system architecture...

	Alex Vincent [:WeirdAl]
	Comment 8 • 22 years ago

http://www.w3.org/TR/CSS2/selector.html#pseudo-elements

Are there any pseudo-elements/classes Mozilla supports that aren't in the CSS2 
spec?

I'm a little confused:  do we want this to fix pseudo-elements only, or pseudo-
classes as well?

From CSS2: 
Pseudo-classes 
:first-child
:link
:visited 
:hover
:active
:focus 
:lang 

Pseudo-elements 
:first-line
:first-letter
:before
:after

Also, which simple selector in a given selector would you apply it to?  If it 
was pseudo-elements only, I can see how they'd pretty much have to be the last 
selector in a chain (html > body > p:first-line).  They don't leave much room 
for debate.  Restricting this bug to that alone, you could have some sort of 
XUL selection system (radio buttons, menulist, whatever) in the style rules 
panel, to apply the right psuedo-class to the end of the selector.

If this bug affects pseudo-classes as well, we're in trouble.  Imagine html > 
body > p:first-child > a:visited.  To do that, we'd need a third subpanel in 
the style rules panel, so the user can set pseudo-classes on each element.  No 
thanks.

I just glanced at the code involved: I have a sneaking suspicion I might be 
able to do this, if we restricted ourselves to pseudo-elements only.  (There 
appears to be an almost total reliance on JS for the tree views of 
styleRules.xul).

	Boris Zbarsky [:bzbarsky]
	Comment 9 • 22 years ago

Inspector already shows most of the pseudo-classes (the only ones it can't show
are the transitory ones like :hover, :active, and maybe :focus).

Mozilla does implement the CSS3 ::selection pseudo-element as :-moz-selection
(the -moz is there because we don't support the ::foo notation yet).

	Christopher Aillon (sabbatical, not receiving bugmail)
	Comment 10 • 21 years ago

Mass re-assigning bugs to dom.inspector@extensions.bugs

	Christopher Aillon (sabbatical, not receiving bugmail)
	Comment 11 • 21 years ago

*** Bug 238758 has been marked as a duplicate of this bug. ***

	Jesse Ruderman
	Comment 12 • 17 years ago

Being able to see pseudo-elements would be useful for making reduced testcases for Gecko bugs.  For example, earlier this week, I had a messy testcase that triggered a crash.  I wanted to switch it from HTML to XHTML so I could make it less messy, but switching to XHTML made the crash go away.  DOM Inspector's "CSS Style Rules" showed me that a quirk.css rule for

  :not(dl) > dd

applied, but it turned out that the relevant rule was the one for

  :not(dl) > dd:before

In this case, I was lucky that there was a similar non-:before rule, so DOM Inspector was able to lead me to the right place.  Replacing the DD with a SPAN and a :before rule allowed me to switch to XHTML and continue reducing the testcase.

(This example was for bug 403454.  Something similar happened with "optgroup:before" in forms.css for bug 403569.)

	Heather Arthur
	Comment 13 • 15 years ago

A small patch for the inpsector's domUtils that adds an extra argument to getCSSStyleRules for the psuedo element, much like getComputedStyle. Firebug and DOM Inspector could call this function for all the pseudo elements they want to support. I think this is a good way to approach it, the other option is to return all the pseudo element rules that apply to that element in the call to getCSSStyleRules.

This is just an example patch, I don't know C++, so its probably hemorrhaging memory.

why is this in mozilla-central?

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 15 years ago

> This is just an example patch, I don't know C++, so its probably hemorrhaging
> memory.

It's not too bad.  Some comments:

1)  You need to change the uuid of the interface
2)  Please put space after "if" in "if (...)" constructs.
3)  You do have one memory leak: the pseudoElt atom in GetCSSStyleRules.  You
    should make that code look like this:

  nsCOMPtr<nsIatom> pseudoElt;
  if (!aPseudo.IsEmpty()) {
    pseudoElt = do_GetAtom(aPseudo);
  }

4)  You can probably just forward-declare nsIAtom in inDOMUtils.h and then
    #include nsIAtom in inDOMUtils.cpp.

With those dealt with, looks good to me, though it's not really a fix for this bug.  It should probably go in a separate bug that this bug depends on.

> why is this in mozilla-central?

"this" being inDOMUtils?  Because it has to use Gecko-private objects (nsRuleNode, say), so has to be linked into the layout library.

	Sebastian Zartner [:sebo]
	Comment 15 • 15 years ago

As Dylan already mentioned in comment 13 this is also an issue at Firebug:

http://code.google.com/p/fbug/issues/detail?id=537

In my eyes this is a bug and not just an enhancement, because some pseudo-classes are already exposed while others are not. And since pseudo-elements are part of the style rules why shouldn't they be returned by getCSSStyleRules(), too?

	Ian Moody [:Kwan] (UTC+1)
	Comment 16 • 14 years ago

This patch copies the fix from Firebug at http://code.google.com/p/fbug/source/detail?r=10363.

	Ian Moody [:Kwan] (UTC+1)
	Comment 17 • 14 years ago

Here a version without the new indenting so it's easier to see what actual code changed

	Colby Russell :crussell (no longer Mozilla-ing)
	Comment 18 • 14 years ago

Comment on attachment 536072 [details] [diff] [review]
Copy Firebug fix

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

First, thanks for the patch.

But this looks like it's for the devtools style inspector.  You'll want to file a bug in the Firefox > Developer Tools component.

	Ian Moody [:Kwan] (UTC+1)
	Comment 19 • 14 years ago

Oh, my apologies, I'm afraid I misread the module page as to where the source is to be found.  I did mean to fix the DOM Inspector extension (I did not previously know about the upcoming devtools one), unfortunately looking at the actual code (assuming I've found it this time) it would appear rather different, and not suitable for borrowing this code (and I'm not sure the licences would be compatible).  Thank you for your time and assistance :)

	:Gijs (he/him)
	Comment 20 • 12 years ago

So at this point the actual elements are shown in the DOM tree. The style rules view is still broken though. Naively, I don't think the patch on this bug would fix that, but there does seem to be more work necessary in order to show the style rules etc.

	Colby Russell :crussell (no longer Mozilla-ing)
	Comment 21 • 12 years ago

(In reply to :Gijs Kruitbosch from comment #20)
> So at this point the actual elements are shown in the DOM tree.

Huh?

	:Gijs (he/him)
	Comment 22 • 12 years ago

(In reply to Colby Russell :crussell from comment #21)
> (In reply to :Gijs Kruitbosch from comment #20)
> > So at this point the actual elements are shown in the DOM tree.
> 
> Huh?

On OS, current Firefox trunk has a style rule for a :before on the #navigator-toolbox under certain conditions ( http://mxr.mozilla.org/mozilla-central/source/browser/themes/osx/browser.css?rev=ed39a9db0fb1#2441 ). In current nightlies, this is what DOMI shows if you've got anonymous content set to be shown.

	Cezar D
	Comment 23 • 11 years ago

I see that the feature landed on Nightly.

	tf
	Comment 24 • 9 years ago

Something happens here? The bug still persist .. extremely annoying. I have to switch chrome everytime i need to inspect pseudo element.

Sometimes the pseudo elements appear inside the inspector, sometimes not.
Third behavior: The psdueo elements appear.. but the Rules-Pane on the right is completely empty.

	:Gijs (he/him)
	Comment 25 • 9 years ago

(In reply to tf from comment #24)
> Something happens here? The bug still persist .. extremely annoying. I have
> to switch chrome everytime i need to inspect pseudo element.
> 
> Sometimes the pseudo elements appear inside the inspector, sometimes not.
> Third behavior: The psdueo elements appear.. but the Rules-Pane on the right
> is completely empty.

If you're talking about the builtin inspector tools in Firefox, this is all meant to work there. Please file a new bug with exact steps to reproduce the issues you're talking about (including a testcase that shows the missed elements/rules), so we can fix them.

	asdfasdfasdf
	Comment 26 • 9 years ago

Sometimes the pseudo elements appear inside the inspector, sometimes not.
Third behavior: The psdueo elements appear.. but the Rules-Pane on the right is completely empty.

Same here!

	Tyler
	Comment 27 • 9 years ago

This bug should be closed; pseudo-elements are not added to the DOM by design.

	Martijn Wargers (dead)
	Comment 28 • 9 years ago

This bug is valid. Pseudo-elements are not added to the DOM, but web developers would like to know which elements get these pseudo-elements.

	Tyler
	Comment 29 • 9 years ago

(In reply to Martijn Wargers [:mwargers] (QA) from comment #28)
> This bug is valid. Pseudo-elements are not added to the DOM, but web
> developers would like to know which elements get these pseudo-elements.

Opening a site that uses ::before and ::after, those have been visible in the inspector for quite some time. If this is a new bug or for something other than the Mozilla Firefox F12 Developer Tools Inspector pane, please open a *new* bug per Gijs' comment above.

	Jesse Ruderman
	Comment 30 • 9 years ago

This bug is for the DOM Inspector add-on, as stated in the summary, not the developer tools that appear when you press F12.

	igor.pellegrini
	Comment 31 • 9 years ago

Same bug on the DOM inspector.
For me (Firefox 40.0.3) some pseudo-::before-elements are shown in the DOM inspector, while (in the SAME page!) others are not shown.

Note: I can see the pseudo-element rendered in the page without problems. It is just missing in the DOM inspector.

	:Gijs (he/him)
	Comment 32 • 9 years ago

(In reply to igor.pellegrini from comment #31)
> Same bug on the DOM inspector.
> For me (Firefox 40.0.3) some pseudo-::before-elements are shown in the DOM
> inspector, while (in the SAME page!) others are not shown.
> 
> Note: I can see the pseudo-element rendered in the page without problems. It
> is just missing in the DOM inspector.

Can you provide a testcase where this happens?

	Andrei Vacariu
	Comment 33 • 9 years ago

One situation where the ::after isn't show on an element is when the ::after is appended to :hover. In this situation it'd be nice that when :hover is checked in the right-click menu, the ::after element is shown in the inspector.

Since this bug is so old, I'm not sure what it applies to anymore, but I'm talking about the Inspector tool that comes with Firefox 41.

	Tony Mechelynck [:tonymec]
	Comment 34 • 9 years ago

(In reply to Andrei Vacariu from comment #33)
> Since this bug is so old, I'm not sure what it applies to anymore, but I'm
> talking about the Inspector tool that comes with Firefox 41.

Actually IIUC the "DOM Inspector add-on" which existed in 2002, and to which the "Other Applications :: DOM Inspector" bugs apply, is the one which is still packaged with trunk builds of SeaMonkey, and available at AMO for other apps if desired: https://addons.mozilla.org/addon/dom-inspector-6622/

	Tony Mechelynck [:tonymec]
	Comment 35 • 9 years ago

P.S. It is mentioned in the "Troubleshooting Information" page as "DOM Inspector", with an add-on ID of inspector@mozilla.org

	:Gijs (he/him)
	Comment 36 • 9 years ago

For the Firefox builtin tool, please see bug 1208544 and friends. This bug is about a different tool.

	igor.pellegrini
	Comment 37 • 9 years ago

(In reply to :Gijs Kruitbosch from comment #32)
> (In reply to igor.pellegrini from comment #31)
> 
> Can you provide a testcase where this happens?

Unfortunately I have no possibility to share it. Is happening in a quite big page from a project not yet published.
I wish I had time to narrow the behaviour to simple code so I could post here :/

	igor.pellegrini
	Comment 38 • 9 years ago

I think I found the culprit.
The extension "CSS Reloader" (https://addons.mozilla.org/it/firefox/addon/css-reloader/). This takes care of reloading an updated CSS without sending another HTTP request.
When working with CSS pseudo-elements probably it doesn't update the markup in a way that the DOM Inspector can be aware of eventual new ones.
Reloading the page will update everything correctly.

That's just a trace; I'm not sure the wrong behavior is happening just in the case of using this extension.

	Firefox Bug Husbandry Bot
	Comment 39 • 6 years ago

Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023

	Firefox Bug Husbandry Bot
	Comment 40 • 6 years ago

Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023