Closed Bug 1287042 Opened 8 years ago Closed 8 years ago

DevTools - Inspector doesn't show pseudoelements with display:none style

Categories

(DevTools :: Inspector, defect, P2)

47 Branch
x86_64
Linux
defect

Tracking

(firefox50 fixed)

RESOLVED FIXED
Firefox 50
Tracking Status
firefox50 --- fixed

People

(Reporter: iippolitov, Assigned: pbro)

References

Details

Attachments

(2 files)

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
Component: Untriaged → Developer Tools: Inspector
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Attached file 1287042.html
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.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Having associated styles for pseudoelements shown would be really nice and should suffice any needs.
Thank you in advance.
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?
Flags: needinfo?(bgrinstead)
I expect bug 1223389 to be solved by this as well.
Assignee: nobody → pbrosset
Status: REOPENED → ASSIGNED
Priority: -- → P2
See Also: → 1223389
(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.
Flags: needinfo?(bgrinstead)
::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/
Attachment #8772744 - Flags: review?(bgrinstead)
Comment on attachment 8772744 [details]
Bug 1287042 - Always before/after CSS rules in rule-view;

https://reviewboard.mozilla.org/r/65510/#review62702

Nice and easy, works for me
Attachment #8772744 - Flags: review?(bgrinstead) → review+
Pushed by bgrinstead@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ec882720349c
Always before/after CSS rules in rule-view; r=bgrins
https://hg.mozilla.org/mozilla-central/rev/ec882720349c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: