If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

element.setAttribute('class',...) has no visible effect after onload

RESOLVED FIXED in mozilla1.8alpha5



13 years ago
13 years ago


(Reporter: JP Fiset, Assigned: bz)



Firefox Tracking Flags

(Not tracked)



(4 attachments)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040928

Using javascript and attempting to change the class attribute of a <g> element
(also test with rect, and others), the actual value of the attribute is changed,
but no visible effect come of it.

The test case has three files: an html doc, a svg doc and a css doc. Buttons on
the html doc offers three styles, and when clicked the associated javascript
calls into the svg doc to change the class on the <g> element (which contains a
single rectangle). 

Initially, the <g> element is associated with a class, and this is reflected
when displayed. When changing the attribute value for 'class', it can be
verified that it has the correct value. However, the viewed styling remains as
it was initially, regardless of the value set for the class attribute.

Reproducible: Always
Steps to Reproduce:
1. Set up CSS with multiple styles available
2. Create SVG with <g> element using one of the styles in CSS
3. Under <g> element, draw a rectangle
4. Using javascript, attempt to change the class attribute of the <g> element to
another valid style 

Actual Results:  
Nothing visually was changed

Expected Results:  
The rectangle should have adopted the new styling

Comment 1

13 years ago
Could you please attach your testcase?

Comment 2

13 years ago
Created attachment 160762 [details]

This is the style sheet associated with this report.

Comment 3

13 years ago
Created attachment 160764 [details]

This is the HTML page driving the SVG in test case

Comment 4

13 years ago
Created attachment 160765 [details]

This is the SVG doc associated with this report

Comment 5

13 years ago
I think this might be per specification - className is readonly for SVG.


  interface SVGStylable { 

    readonly attribute SVGAnimatedString className;
    readonly attribute css::CSSStyleDeclaration style;

    css::CSSValue getPresentationAttribute ( in DOMString name );

Ian, comments?
Well, className might be readonly, but surely the class attribute itself can't 
be. I mean, that's just core DOM stuff, all attributes are mutable. No?

Having said that, this is WFM using a simple testcase:


...yet fails in the case attached to this bug. (I stepped through it with the 
DOM Inspector and the JavaScript Debugger -- the attribute does get changed, but 
for some reason the style doesn't get recomputed.)
Oh, I see. If you change the style after the onload event, it doesn't take 
effect. Weird.

TESTCASE: http://www.hixie.ch/tests/adhoc/svg/dynamic/006.xml
Ever confirmed: true
Summary: element.setAttribute('class',...) has no visible effect → element.setAttribute('class',...) has no visible effect after onload
(Incidentally, className is readonly but className.baseVal isn't. You could
change that without any problem.)
> Having said that, this is WFM using a simple testcase:

The key is that the simple testcase sets the attribute before initial style
resolution and frame construction.  Doing it after onload means that we have to
do an actual style reresolve.

As for why this bug happens, it's simple.  SVG element's implementation of
nsIStyledContent is broken.  See bug 238450 comment 8, bug 238450 comment 11,
bug 238450 comment 27.  Then I got tired of being summarily ignored on the issue
and figured having dynamic class changes working was simply not on the list of
things we wanted out of SVG.
Attachment #160765 - Attachment mime type: text/plain → image/svg+xml
Attachment #160762 - Attachment mime type: text/plain → text/css
Er, I lied.  It's nsIContent, not nsIStyledContent.
Created attachment 161120 [details] [diff] [review]
This probably fixes it.
Attachment #161120 - Flags: superreview?(tor)
Attachment #161120 - Flags: review?(tor)
Attachment #161120 - Flags: review?(tor) → review+


13 years ago
Attachment #161120 - Flags: superreview?(tor) → superreview+
Assignee: general → bzbarsky
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.8alpha5
Thanks Boris! Sorry this fell off my radar before I headed back to school
It's OK.  Just graduate already, dammit.  ;)

Checked in on the trunk.
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.