DOM Inspector add-on (NOT the Firefox builtin inspector tool!) doesn't show dynamically updated/created ::before / ::after pseudo-elements automatically

RESOLVED INCOMPLETE

Status

enhancement
RESOLVED INCOMPLETE
17 years ago
6 months ago

People

(Reporter: pbs, Unassigned)

Tracking

({helpwanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

17 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.
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).
(Reporter)

Comment 2

17 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.
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.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
This can't be invalid.  There's no basis for marking it invalid.  It's either
wontfix, or will be fixed.

Comment 5

16 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.
OS: Windows 2000 → All
Hardware: PC → All

Comment 6

16 years ago
Posted file testcase
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...
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).
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).
Mass re-assigning bugs to dom.inspector@extensions.bugs
Assignee: caillon → dom.inspector
*** Bug 238758 has been marked as a duplicate of this bug. ***
Product: Core → Other Applications
Assignee: dom-inspector → nobody
QA Contact: timeless → dom-inspector

Comment 12

12 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.)

Comment 13

9 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?
> 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.
Depends on: 557726
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?
Posted patch Copy Firebug fix (obsolete) — Splinter Review
This patch copies the fix from Firebug at http://code.google.com/p/fbug/source/detail?r=10363.
Attachment #536072 - Flags: review?(Sevenspade)
Here a version without the new indenting so it's easier to see what actual code changed
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.
Attachment #536072 - Flags: review?(Sevenspade)
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 :)
Attachment #536072 - Attachment is obsolete: true
Attachment #536075 - Attachment is obsolete: true

Comment 20

6 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.
(In reply to :Gijs Kruitbosch from comment #20)
> So at this point the actual elements are shown in the DOM tree.

Huh?

Comment 22

6 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.

Comment 23

6 years ago
I see that the feature landed on Nightly.

Comment 24

4 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.

Comment 25

4 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.

Updated

4 years ago
Summary: CSS pseudo-elements are not shown in Inspector → CSS pseudo-elements are not shown in DOM Inspector add-on

Comment 26

4 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!

Comment 27

4 years ago
This bug should be closed; pseudo-elements are not added to the DOM by design.
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.

Comment 29

4 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.

Comment 30

4 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.

Comment 31

4 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.

Comment 32

4 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?
Flags: needinfo?(igor.pellegrini)

Comment 33

4 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.
(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/
P.S. It is mentioned in the "Troubleshooting Information" page as "DOM Inspector", with an add-on ID of inspector@mozilla.org

Comment 36

4 years ago
For the Firefox builtin tool, please see bug 1208544 and friends. This bug is about a different tool.
Summary: CSS pseudo-elements are not shown in DOM Inspector add-on → DOM Inspector add-on (NOT the Firefox builtin inspector tool!) doesn't show dynamically updated/created ::before / ::after pseudo-elements automatically
Depends on: 1034110

Comment 37

4 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 :/
Flags: needinfo?(igor.pellegrini)

Comment 38

4 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.
Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → INCOMPLETE
Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023
You need to log in before you can comment on or make changes to this bug.