Closed
Bug 35618
Opened 25 years ago
Closed 20 years ago
[trk] (DOM2 CSS) CSSUnknownRule
Categories
(Core :: DOM: CSS Object Model, defect, P3)
Core
DOM: CSS Object Model
Tracking
()
RESOLVED
WONTFIX
Future
People
(Reporter: jst, Unassigned)
References
Details
(Keywords: dom2)
No description provided.
Reporter | ||
Comment 1•25 years ago
|
||
future problem...
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Updated•24 years ago
|
QA Contact: vidur → ian
Updated•24 years ago
|
Component: DOM Level 2 → DOM Style
Comment 2•24 years ago
|
||
Taking QA Contact on all open or unverified DOM Style bugs...
Comment 3•24 years ago
|
||
Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.
Keywords: nsbeta1
Comment 4•24 years ago
|
||
Removing nsbeta1 nomination -- there was a misunderstanding and some "approved
out features" were nominated by mistake! Sorry!
Keywords: nsbeta1
![]() |
||
Comment 5•24 years ago
|
||
so what needs to be done for this exactly?
![]() |
||
Comment 6•23 years ago
|
||
I feel that we should absolutely not implement CSSUnknownRule....
![]() |
||
Comment 7•23 years ago
|
||
*** Bug 157641 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
*** Bug 188321 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
bz: do you mean this should not be implemented for performance reasons, or other
reasons?
![]() |
||
Comment 10•22 years ago
|
||
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).
Reporter | ||
Comment 11•22 years ago
|
||
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW
Comment 12•22 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?
![]() |
||
Comment 13•22 years ago
|
||
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•22 years ago
|
||
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.
Description
•