Accessing style attributes of a DOM node in an editor frame with Javascript buggy

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
RESOLVED WORKSFORME
11 years ago
8 years ago

People

(Reporter: Matthew Minix, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: XUL Runner 1.8.0.9

This one is a little weird, given this code, 

--JS--
for(style in nodeStart.style) {
 alert(style + ": " + nodeStartStyle[style]);
}

--HTML--
<span style='font-weight: bold'>blah</span>

alerts - "0: font-weight"

however, if the line
alert(nodeStart.style.fontWeight);

is placed at the top it gives the correct response of "font-weight: bold"

This happens in XUL Runner 1.8.0.9, but I also tested it in 1.9a7pre and got the same result.  The HTML is in an <editor> tag, if that makes a difference.


Reproducible: Always

Steps to Reproduce:
1. Create an XUL file with an editor tag
2. Paste the above HTML code into the editor
3. Run the Js code above on the node
Actual Results:  
0: font-weight

Expected Results:  
font-weight: bold
Ah, numbered properties for enumeration!  I'd wager this could be correct (but definitely confusing), since the first property of the style declaration (property "0") would be font-weight.

You probably want computed style instead.
(Reporter)

Comment 2

11 years ago
I was thinking that could be as well, but, the loop never turns up font-weight, and when nodeStart.style[0][style]  is done it returns the first letter =)

Having it work the way I expected after placing alert(nodeStart.style.fontWeight); at the top is what makes me think this is a bug.  From what I know, nothing about that statement should have made it work, but, I could be wrong.

In this instance the goal was to get the styles that apply to one element and not it's parent node, so getComputedStyle is working with searching for what doesn't match, rather than what does, however it's much slower than style is, at least in Firefox, maybe not in XULRunner
So... The alert resolves the property, which is then defined on the JSObject.  Before then there is no "fontWeight" property there.

Which is odd.  I would have expected fontWeight (exposed via XPConnect in this case) to be enumerable.  Why isn't it, until we resolve it the first time?  Some sort of classinfo helper mess?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

10 years ago
Component: DOM: Core → DOM: Core & HTML
This worksforme now (including in builds from when this was filed, interestingly).  Will attach the testcase.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.