Status

()

For bugs in Firefox Desktop, the Mozilla Foundation's web browser. For Firefox user interface issues in menus, developer tools, bookmarks, location bar, and preferences. Many Firefox bugs will either be filed here or in the Core product. (more info)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160606114208
Steps to reproduce:
create a document with a pseudoelement with content and style the element with "display:none"
Then open dev tools (ctrl-shift-i) and choose parent element
Here is an example: https://codepen.io/oxpa/pen/WxdkNX
Actual results:
The parent element has no children
Expected results:
The parent element should have a pseudoelement child

The inspector is actually showing what's really happening. The hidden element is part of the DOM, so the inspector shows it, but since it's hidden, it does not generate any boxes in the layout, and in turn, that means the generated content (pseudo-element) has no boxes to be inserted into, and so the layout engine doesn't not generate it.
See bug 1223389.

Hello, Patric.
The only hidden element is ":after" element itself. And it is not inspectable if is hidden.
Currently there is no way I can use devtools to distinguish two different states:
1) no changes into ':after'
2) content of ':after' is altered, but is hidden
Yet the outcome may alter the page.
As an example usage: I may rely on content of ":after" element to enable features on a page in JS. And set the content using media queries in CSS. (as flickity does with 'watchCSS' option http://flickity.metafizzy.co/options.html#watchcss )
Layout may skip generating hidden pseudoelements, yet it is really useful to have anything to work with those like we can do with ':hover' selector.

Oh I see, sorry for closing this as a dupe, this isn't the same problem, I closed it too quickly. Bug 1223389 is about the parent being hidden, not the pseudo-element itself.
So, in your case, the pseudo-element is styled this way:
div::after { content: "foo"; display: none; }
And devtools does not show it in the markup-view.
Still, getComputedStyle(div, "::after").content does work and returns "foo", as expected.
And since you want to use this in Javascript to trigger some actions, it would indeed be nice if the inspector would show the pseudo-element.
In fact, we used to not show pseudo-elements at all in the markup-view, which was bad, but instead we would show the corresponding CSS rules in the rule-view (the sidebar where CSS rules are shown).
So, at least, whether the content of the rule was correct or not, the element hidden or not, the rule was shown in the sidebar.
Now, we do show pseudo-elements in the markup-view, which is really useful in a lot of cases, but it's true that in your case, and in the case of bug 1223389, the CSS rules do not generate elements in the tree, which is why we don't show anything there (and I guess it would be very hard to for us to show them).
So, I propose a mix of both approaches:
- if pseudo-elements are present in the tree, show them in the markup-view only
- if there are no pseudo-elements in the tree, but the element has pseudo-element rules defined, then show them in the rule-view.
This way it's easy for people to see that the rule is defined, but somehow something prevents it from creating an element in the tree.

Now the question, I guess, is whether we should just show the pseudo-element rules all the times in the rule-view. Maybe it's just better to have both the element in the markup-view *and* the corresponding CSS rule on its parent in the rule-view.
Fwiw, that's what Chrome does.
I have a patch almost ready that does what I said in comment 4, but I'm wondering if maybe I should simplify it and just show the pseudo-element rules all the time.
Brian: you implemented the before/after in the markup-view, do you have thoughts about this?

(In reply to Patrick Brosset <:pbro> from comment #6)
> Now the question, I guess, is whether we should just show the pseudo-element
> rules all the times in the rule-view. Maybe it's just better to have both
> the element in the markup-view *and* the corresponding CSS rule on its
> parent in the rule-view.
> Fwiw, that's what Chrome does.
>
> I have a patch almost ready that does what I said in comment 4, but I'm
> wondering if maybe I should simplify it and just show the pseudo-element
> rules all the time.
>
> Brian: you implemented the before/after in the markup-view, do you have
> thoughts about this?
I think simplifying and showing in both places all the time makes sense. It's hard to keep track of the situations when it won't show up in the markup view so may as well be consistent.

Created attachment 8772744[details]Bug 1287042 - Always before/after CSS rules in rule-view;
::before and ::after pseudo-elements are visible in the markup-view today
but if, for some reason, they aren't generated, we still want to know that
the CSS rule exists.
This may happen if you use display:none on the pseudo-element CSS rule itself.
When that happens, the pseudo-element won't be generated and therefore there
will be no possibility to see the rule in the rule-view (you'd have to go to
the style-editor for that).
This change keeps the pseudo-elements in the markup-view, but also adds the
corresponding CSS rules in the rule-view.
Review commit: https://reviewboard.mozilla.org/r/65510/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/65510/