35618 - [trk] (DOM2 CSS) CSSUnknownRule

Status: RESOLVED WONTFIX

(Core :: DOM: CSS Object Model, defect, P3)

Comment 1

[Johnny Stenback (:jst)]

future problem...

Comment 2

[Hixie (not reading bugmail)]

Taking QA Contact on all open or unverified DOM Style bugs...

Comment 3

[Hixie (not reading bugmail)]

Nominating this bug for nsbeta1 on behalf of [e-mail].

Comment 4

[Hixie (not reading bugmail)]

Removing nsbeta1 nomination -- there was a misunderstanding and some "approved
out features" were nominated by mistake! Sorry!

Comment 5

[Boris Zbarsky [:bzbarsky]]

so what needs to be done for this exactly?

Comment 6

[Boris Zbarsky [:bzbarsky]]

I feel that we should absolutely not implement CSSUnknownRule....  

Comment 7

[Boris Zbarsky [:bzbarsky]]

*** Bug 157641 has been marked as a duplicate of this bug. ***

Comment 8

[Benjamin Smedberg]

*** Bug 188321 has been marked as a duplicate of this bug. ***

Comment 9

[Benjamin Smedberg]

bz: do you mean this should not be implemented for performance reasons, or other
reasons?

Comment 10

[Boris Zbarsky [:bzbarsky]]

This should not be implemented for security reasons (look up all the issues IE
has been having because of their implementation) and because this section of the
DOM spec flat-out contradicts the parsing rules in the CSS spec (the people who
wrote the DOM spec didn't really know CSS and it shows in many places, this
being one of them).

Comment 11

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 12

[Brad Neuberg]

First, I'd like to point out that my bug, <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=188321">188321</a> is _not_ a
duplicate of this bug.  My bug is an RFE that asks for an infrastructure to be
able to access/create custom CSS style properties for XBL widgets without using
C++, while the CSS CSSUnknownRule has to do with the CSS engine encountering an
unknown _selector_ rather than an unknown _style rule_ (i.e. it encounters a
rule such as *id { someRule: someProperty; } where it doesn't understand what
the asterisk selector is).

Also, some people have responded that my RFE breaks the CSS specification; of
course it does.  However, so do the Mozilla specific CSS rules
-moz-border-radius, -moz-binding, etc.  The reason for my specification is to
further the concept of XBL widgets as reusable packets of code.  In the past if
you wanted to pass in things that are obviously "style" or "visual" properties
of an XBL widget that you want to change at runtime, you had to add your own C++
custom property.  This is not maintainable, and the codebase of custom C++
properties is a mess (you have to change many locations, and it really isn't
rationalized).  Some might respond that you could just create some JavaScript
setters in your XBL widget to set these properties, but this also leads to
unmaintainable code. Lets say someone else comes along to change some visual
style of your XBL widget; are they going to expect to look in the .js file for
that style change or the .css file?  The correct place is the CSS file.

Now about security issues.  One danger is that an XBL widget, which would be
trusted chrome, could be passed a "string" value through a custom XBL style
property in an untrusted style sheet.  This string value could then somehow
cause the XBL widget to do something that is not visual but which is instead
damaging (such as deleting a file). However, the exact same thing is true of a
JavaScript file: you might have a .js file that lies within the trusted chrome
domain with a method such as deleteFile(string fileName), and then call that
method from some untrusted XUL file.  Both of these scenarios depend on someone
"stupidly" coding their chrome XBL or JavaScript files, however.  Do we want to
protect stupid chrome writers?  They can already hurt themselves pretty badly
with the current infrastructure, so why make a special exception in this case?

Comment 13

[Boris Zbarsky [:bzbarsky]]

What did that comment have to do with this bug?  As you said, bug 188321 has 
nothing to do with this bug; why did you even drag it in?

The security issue here is that sites can load some random content as CSS (in 
quirks mode they can) and then access a parsed version of it via the CSSOM.  If 
we allow CSSUnknownRule, then most of the content will be accessible in this 
fashion, allowing sites to read the content of arbitrary web pages (eg 
including ones that need the user's cookies to get).  This would be a gross 
security violation.  There is a known security vulnerability in IE along these 
lines, as I said.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Note http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html (which
screams "wontfix this bug" to me).

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Marking wontfix per comment 14.