What steps will reproduce the problem? 1. Open http://weblogs.vpro.nl/dexter/2010/03/27/aflevering-11-left-turn-ahead/comment-page-1/#comment-2274 2. Choose 'Inspect Element' on a reply to a comment (e.g. inspect the one dated "13 april 2010 om 15:04") 3. Climb up in the stack of elements till you reach <ul class="children"> (like in the attached screenshot) and compare the rendered output and Firebug's 'Computed' tab with the contents of the 'Style' tab.

What is the expected result? What do you see instead?

The browser shows list markers, that are mentioned under 'Computed' (e.g. "list-style-type: circle"). When I look at 'Style', there's a rule under "Inherited from ol.commentlist" that reads "list-style: none outside none". I don't know if ULs should inherit from parental OLs, but at least this looks inconsistent to me.

I also asked about this on http://stackoverflow.com/questions/2634637 (which contains some more elaborations links to screenshots).

Which version of Firebug? (more specific than 'latest' please): 1.5.3 Which version of Firefox? 3.6.3 On what operating system? Linux

As the developer of the first page linked to fixed the issue with the unwanted list markers, I made a minimal test case with which you can play around. Just select the and notice that Firebug says that the inherited the list-style property from the (though it didn't, when we look at the actually rendered page).

Please compare this with WebKit's web inspector and especially with the Opera variant. The latter explicitly makes clear that it falls back to the browser's default values of list-style-type and list-style-position.

What happens if you have the Style panel's "Expand Shorthand Properties" enabled? In that case it looks correct to me. Note that this only has to do with Firefox 3.6.

In other words: with Firefox 3.6, Firebug is incorrectly combining the rules. Might be a Firefox bug if Firebug does not branch on versions when getting this information.

In that case, it just says:

ol { list-style-image:none; list-style-position:outside; list-style-type:none; }

I haven't tested this with other versions of Firefox (or Firebug), nor on other platforms (though I doubt the latter would make a difference), but I think it's highly possible that the bug is actually caused by Firefox. That said, as far as I know the web page is rendered correctly.

I can confirm this testing it with FF 3.0.19/3.6.3/3.7a4pre + FB 1.6X.0a9 on Windows 7. The "list-style-type" for the is correctly shown as circle when having a look at the page and the "Computed" tab, but inside the "Style" tab it's saying "none" instead of "circle". Though the is really inheriting from the , because when changing one of the other two values of the it also changes the display. Really seems to be a bug in Firefox. Question is, how Firebug is generating the list of inherited styles. When someone tells me, I can make a test case for that.

If you use Style>Show User Agent styles, then list-style-type: circle; is shown. In that view I think the bugs might be: 1) list-style shorthand needs to be expanded to correctly display overwriting, 2) the long selector list on the User Agent styles obscures the rules. Is it true?

Is comment 6 asking a question that I can usefully answer here? If so, which?

Sorry Boris my mistake. I read the comments, added your CC, then went back to try the example. Then I realized its probably just that the User Agents styles are off by default. And forgot to remove you.

I currently think there is no Firefox bug here.

But John has a point here: with ‘Show User Agent CSS’ off, Firebug incorrectly shows:

Inherited from ol: ol { list-style:none outside none; }

But with that option and ‘Expand Shorthand Properties’ enabled it shows that ‘list-style-type: none’ isn't inherited from the ol and correctly shows

ol ul, ul ul, […] { list-style-type:circle; }

from html.css .

Does someone have Firefox 3.5 installed. I thought the same version of Firebug on 3.5 was OK, but on 3.6 it was in error. But it could just be my memory...

I tested this with FF 3.5.11pre + FB 1.5.4/1.5 (SVN) + Windows 7 and it's not working. This is related to issue 1189, for which I created a test case today. John is right with his comment #6. Note that even when the user agent styles are not displayed, they still need to be taken into account regarding cases like this one.

Similar problem in Firebug 1.8 on FF5&6b with border-collapse CSS property. Testcase: http://jsfiddle.net/nsmVY/ (when inspecting any of red-bordered cells of the inner table Firebug reports: "Inherited fromtable#zz #zz { border-collapse: collapse; }", although the border-collapse CSS property must not be inherited according to the CSS spec and it's clearly seen that it isn't inherited in fact). I think that this behavior is confusing and simply wrong.

Harutyun, maybe you can have a look at that, since you already had to do with inherited styles lately.

comment 12 is different than the original issue here

here are styles shown as inherited by fbug Css.inheritedStyleNames = { "border-collapse": 1, "border-spacing": 1, "border-style": 1, "caption-side": 1, "color": 1, "cursor": 1, "direction": 1, "empty-cells": 1, "font": 1, "font-family": 1, "font-size-adjust": 1, "font-size": 1, "font-style": 1, "font-variant": 1, "font-weight": 1, "letter-spacing": 1, "line-height": 1, "list-style": 1, "list-style-image": 1, "list-style-position": 1, "list-style-type": 1, "opacity": 1, "quotes": 1, "text-align": 1, "text-decoration": 1, "text-indent": 1, "text-shadow": 1, "text-transform": 1, "white-space": 1, "word-spacing": 1, "word-wrap": 1 };

and mdn states that border-collapse is inherited https://developer.mozilla.org/en/CSS/border-collapse

but testcase shows it isn't? maybe someone who knows css better than me, can correct Css.inheritedStyleNames list?

and to solve original issue, we can simply change the place where systemStylesheets are thrown away

but will it be better if style is shown as overridden and no overriding rule is displayed?

Comment deleted

and to solve original issue, we can simply change the place where systemStylesheets are thrown away but will it be better if style is shown as overridden and no overriding rule is displayed?

If a system style rule is required to be seen because it overrides a user style, then we must show it, regardless of the user option. It is always better to "do the right thing" then to require the user to fiddle with various (hidden) options.

The quick fix is to always show the system stylesheet and remove the option to hide it.

Otherwise, we need to selectively forcibly show them in cases like this.

We should fix this... otherwise we are lying to the user. I guess striking out the rule even when not showing the system rules is OK as a stopgap measure, but it should be properly fixed.

If a system style rule is required to be seen because it overrides a user style, then we must show it, regardless of the user option. It is always better to "do the right thing" then to require the user to fiddle with various (hidden) options.

We should fix this... otherwise we are lying to the user. I guess striking out the rule even when not showing the system rules is OK as a stopgap measure, but it should be properly fixed. I agree.

The quick fix is to always show the system stylesheet and remove the option to hide it. That will cause annoyed users, because for them the System styles are normally not important. If we can, we should avoid this solution.

Just want to note, that the new styles view integrated with the inspector feature of Firefox has the same problem. System styles are not shown at all.

Sebastian

Chrome does a decent job figuring out which system styles to show. It doesn't show all of them (that can be a lot), but does show the one's that are interacting or are important in some way.

I like the idea of no options when we can. The brutal details of the system styles rarely meet a need. But neither does dismissing them all.

The first thing to do is apply the strikeout where is should be so we aren't lying to the user. Then we can decide on how to handle the system styles.

I agree, that just showing the system styles, that are relevant, is probably the best solution.

Though I think it can be interesting to see the system styles in some cases, so I would keep the option, but just rename it to "Show all user agent styles" or so.

Sebastian

Part of the issue of showing the system styles is that the rules are just ugly:

address, article, aside, blockquote, body, caption, center, col, colgroup, dd, dir, div, dl, dt, fieldset, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, html, li, listing, map, marquee, menu, nav, noframes, ol, p, plaintext, pre, section, table, tbody, td, tfoot, th, thead, tr, ul, xmp { unicode-bidi: -moz-isolate; }

Ideally, that would just be: ul { unicode-bidi: -moz-isolate; }

The rest is irrelevant to what we are looking at. And it only takes three lines instead of ten. Unfortunately, I don't know of anything we can do to fix this without Mozilla Platform help. Perhaps the only way is to get a fix in the built-in dev tools.

Anyhow, that aspect would depend on Issue 2222.

I have a basic fix for this (doesn't force system style, but should mark as overridden). However, because of Issue 1189, the test in comment 1 still fails. :(

Honza, can you review r12489?

Arg, and I don't have the priv to change the commit message. Can someone mark it as [1.9] ?

Honza, can you review r12489? Great will do!

Arg, and I don't have the priv to change the commit message. Can someone mark it as [1.9] ? Done

Honza

Steven, which test case did you use to check your changes? The first one doesn't exist anymore. The only one I can see is in comment 12 and is still wrong (probably because it's unrelated to system styles).

Sebastian

Ok, now I saw, that there is already a test case in comment 1. Though I created an improved test case now at https://getfirebug.com/tests/issues/3009/issue3009.html, which includes precise steps to reproduce and is delimiting the problem described here from the one of issue 1189 (related to parts of shorthand properties not being striked out).

Btw. I tested it after I fetched the changes of r12489. Steven, let me know, if you need anything else.

Sebastian

Patch committed at R12499

The problem is that I am not sure why the condition was actually there. All inherited styles have been skipped and not crossed out. It solves this issues, but anybody knows about any risks here?

Steven, can you explain your patch in more details?

Honza

There's still the problem, that in such cases the system style is not displayed. Should we put that into a separate issue?

Sebastian

There's still the problem, that in such cases the system style is not displayed. Originally, I thought that this is what Steven's patch is solving. Steven?

Should we put that into a separate issue? Yes, if the answer for previous question is no.

Anyway, please test the change (and issue 1189) very carefully. I am wondering if anything else could be broken (and auto-test coverage here is pure)

Honza

This issue (1 of 8) has been fixed in Firebug 1.9b4 http://getfirebug.com/releases/firebug/1.9/firebug-1.9.0b4.xpi

Please try it and let us know if it works for you.

Thanks for the help! Honza

Yeah, I figured to do this in two steps. It will not force a system style to show. If this works I will add that in. Was another issue created for that?

There's still the problem, that in such cases the system style is not displayed. Should we put that into a separate issue? Sebastian, can you create a new issue report for this? Thanks! Honza

Sebastian, can you create a new issue report for this? Issue 5084

Sebastian