Closed
Bug 185431
Opened 22 years ago
Closed 6 years ago
DOM Inspector add-on (NOT the Firefox builtin inspector tool!) doesn't show dynamically updated/created ::before / ::after pseudo-elements automatically
Categories
(Other Applications :: DOM Inspector, enhancement)
Other Applications
DOM Inspector
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: pbs, Unassigned)
References
Details
(Keywords: helpwanted)
Attachments
(4 files, 2 obsolete files)
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.
![]() |
||
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).
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.
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.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
![]() |
||
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.
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.
OS: Windows 2000 → All
Hardware: PC → All
Comment 6•22 years ago
|
||
![]() |
||
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...
Updated•22 years ago
|
Keywords: helpwanted
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).
![]() |
||
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).
Comment 10•21 years ago
|
||
Mass re-assigning bugs to dom.inspector@extensions.bugs
Assignee: caillon → dom.inspector
Updated•20 years ago
|
Product: Core → Other Applications
Updated•17 years ago
|
Assignee: dom-inspector → nobody
QA Contact: timeless → dom-inspector
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.)
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?
![]() |
||
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.
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?
Comment 16•14 years ago
|
||
This patch copies the fix from Firebug at http://code.google.com/p/fbug/source/detail?r=10363.
Attachment #536072 -
Flags: review?(Sevenspade)
Comment 17•14 years ago
|
||
Here a version without the new indenting so it's easier to see what actual code changed
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.
Attachment #536072 -
Flags: review?(Sevenspade)
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 :)
Updated•13 years ago
|
Attachment #536072 -
Attachment is obsolete: true
Updated•13 years ago
|
Attachment #536075 -
Attachment is obsolete: true
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.
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?
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.
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.
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.
Updated•9 years ago
|
Summary: CSS pseudo-elements are not shown in Inspector → CSS pseudo-elements are not shown in DOM Inspector add-on
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!
Comment 27•9 years ago
|
||
This bug should be closed; pseudo-elements are not added to the DOM by design.
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.
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.
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.
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.
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?
Flags: needinfo?(igor.pellegrini)
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.
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/
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
Comment 36•9 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
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 :/
Flags: needinfo?(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.
Comment 39•6 years ago
|
||
Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
Comment 40•6 years ago
|
||
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.
Description
•