[trk] (DOM2 CSS) CSSUnknownRule




DOM: CSS Object Model
18 years ago
4 years ago


(Reporter: jst, Unassigned)




Firefox Tracking Flags

(Not tracked)


Comment hidden (empty)

Comment 1

18 years ago
future problem...
Target Milestone: --- → Future
QA Contact: vidur → ian
Keywords: dom2
Component: DOM Level 2 → DOM Style
Taking QA Contact on all open or unverified DOM Style bugs...
Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.
Keywords: nsbeta1
Removing nsbeta1 nomination -- there was a misunderstanding and some "approved
out features" were nominated by mistake! Sorry!
Keywords: nsbeta1
so what needs to be done for this exactly?
I feel that we should absolutely not implement CSSUnknownRule....  
*** Bug 157641 has been marked as a duplicate of this bug. ***

Comment 8

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

Comment 9

15 years ago
bz: do you mean this should not be implemented for performance reasons, or other
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

15 years ago
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs

Comment 12

15 years ago
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?
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.
Note http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html (which
screams "wontfix this bug" to me).
Marking wontfix per comment 14.
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
Duplicate of this bug: 909007
You need to log in before you can comment on or make changes to this bug.