Closed Bug 35618 Opened 25 years ago Closed 20 years ago

[trk] (DOM2 CSS) CSSUnknownRule

Categories

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

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: jst, Unassigned)

References

Details

(Keywords: dom2)

No description provided.
future problem...
Status: NEW → ASSIGNED
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. ***
*** Bug 188321 has been marked as a duplicate of this bug. ***
bz: do you mean this should not be implemented for performance reasons, or other reasons?
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).
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.