Julien Wajsberg [:julienw] Reporter
	Description • 9 years ago

STR:
1. Loads the attachment.
2. Tries to inspect the ":after" generated content.
3. Click on "toggle" to make the div disappear.

=> Note that the :after node is not displayed in the inspector anymore.

I think it should be displayed like the other nodes, using a paler color but still displayed.

	Patrick Brosset <:pbro>
	Comment 1 • 9 years ago

My immediate reaction is that it's correct and shouldn't be changed. Gecko does not seem to generate frames for the pseudo-element when the originating element isn't rendered. I wonder if this is specified somehow or just what Gecko happens to do.
I think devtools should respect what the platform does for this and not fake a generated element when there's none. Therefore, if we want to change this, there'll be platform work involved.

Brian, you worked on this more than me, what's your point of view?

	Brian Grinstead [:bgrins]
	Comment 2 • 9 years ago

I agree that it's not ideal, but right now we have no way to tell if the pseudo was removed due to the parent element being hidden or some other reason, all we know is that the content has been unbound from the tree.  I suspect it would be a lot of work to add a special 'debug mode' in the platform such that pseudo elements don't get unbound if the parent becomes hidden (and I believe there are other cases where this happens also).  But I think Olli would know better about that and if it'd be possible.

I could imagine some hacky way to handle this from the devtools level where we ignore a removal if something like window.getComputedStyle(node, ":after").content is not empty and the binding parent hasn't changed.  But if you tried to actually inspect the node it would fail since there is no node there.  And if the pseudo node actually got removed while in this state then another notification would not fire and we'd end up back where we started before Bug 1034110 / 1208544.  Because of those reasons I'd only consider a change here if we could do it at the platform level.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 3 • 9 years ago

Given that hidden element, https://html.spec.whatwg.org/multipage/rendering.html#hiddenCSS, is display: none http://mxr.mozilla.org/mozilla-central/source/dom/html/nsGenericHTMLElement.cpp#1349 , there isn't any layout objects bound to it so I can't see how it could have any pseudo elements either.

	Patrick Brosset <:pbro>
	Comment 4 • 9 years ago

Julien, based on the above, I'd like to close this as WONTFIX, but before that, I'd like to know the use case that this would solve for you, maybe there's something else we could do in devtools to help?

	Julien Wajsberg [:julienw] Reporter
	Comment 5 • 9 years ago

In my mind, a pseudo-element is part of the DOM tree (I know it's not "physically", but logically it still is), so it should not be removed if it's a "child" of an hidden element.

Actually the CSS2 spec [1] says that it's attached to the document tree.

[1] http://www.w3.org/TR/CSS21/generate.html#before-after-content

My use case is that I was investigating something more complicated on a website (deezer.com), I had to find the right element to add the right class so that the subchild is not hidden anymore and I could inspect the generated content.

It's actually useful to inspect hidden nodes: most of the time we can still see the "default" (static) styles.

	Patrick Brosset <:pbro>
	Comment 6 • 9 years ago

(In reply to Julien Wajsberg [:julienw] from comment #5)
> My use case is that I was investigating something more complicated on a
> website (deezer.com), I had to find the right element to add the right class
> so that the subchild is not hidden anymore and I could inspect the generated
> content.
> 
> It's actually useful to inspect hidden nodes: most of the time we can still
> see the "default" (static) styles.
Interesting use case I think.
So, say, you have something like this:

- DOM tree is very deep (navigation in the inspector hard),
- you selected the element you expect the ::before to be attached to,
- one of the parents of this element is hidden, so the element is hidden too, and the pseudo-element isn't generated,
- the parent that's hidden is actually hidden because a class has been set on yet another parent.

Something like this:

<div id="root" class="some-state">
  ...
   ...
     <div id="hidden-parent">
       ...
         ...
           <div id="test-element">

With #test-element selected, you see that the ::before isn't present in the tree and so you try and understand why.
The element has no style that makes it hidden, so you first have to find out which of its parent is hidden.
Thankfully this can be done easily by scrolling up in the inspector, looking for the last parent that's greyed-out. This would be #hidden-parent.
Once you found it, you see that it's hidden because of this rule `.some-state #hidden-parent {display:none}`.
Which means you still have to find where the .some-state class comes from, which means more scrolling up the inspector, or using the search input.

That's a lot of clicking, scrolling around needed, and by then, you'd probably have lost track of the original element too. Once you switch the class on #root, you'd have to find #test-element again to inspect its generated content.
On thing that would help is bug 1221590: a back button for the inspector that would allow to select the previously selected elements.

Is this a good description of the use case? Is there anything else the inspector could do to help?

	Julien Wajsberg [:julienw] Reporter
	Comment 7 • 9 years ago

Yeah it's a perfectly good description !

I still struggle to understand why I am allowed to inspect hidden elements, but I would be prevented from inspecting hidden pseudo elements... I mean I understand the underlying reason, but as a user this is painful.

	Patrick Brosset <:pbro>
	Comment 8 • 9 years ago

Just re-read this bug after a while, and I 'm going to WONTFIX it.
My understanding is that displaying pseudo-elements when they, in fact, don't exist isn't something we can easily do (and I still think we shouldn't).
Additionally, it looks like bug 1221590 would help with the navigation problem.

	Patrick Brosset <:pbro>
	Comment 10 • 8 years ago

So in bug 1287042, I'm showing the pseudo-element rules in the rule-view.
So, if there is a generated pseudo-element in the DOM, then it will be shown in the markup-view, and the corresponding CSS rule will be shown in the rule-view for its parent.
And if there isn't a generated pseudo-element, for any reason, you won't see it in the markup-view, but you'll still see the rule in the rule-view.

Although this doesn't address the requirement of comment 0, this should help a lot.

	Julien Wajsberg [:julienw] Reporter
	Comment 11 • 8 years ago

Yeah I think it will help. Let's wait for bug 1287042 to land and I'll tell you if it's good enough :)