742549 - crossorigin attribute on script elements not reflected in crossOrigin IDL property

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[James Ide]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.9 Safari/536.5

Steps to reproduce:

Created a page that has <script crossorigin="anonymous" src="..."></script> in the markup. The page also dynamically creates a script element, sets its crossOrigin property to true, and inserts it into the document head.


Actual results:

Opened the Web Console to inspect the properties of the two script elements. The parser-inserted script's crossOrigin property was undefined, but getAttribute('crossorigin') returned "anonymous". The script-inserted script's crossOrigin property was true, but getAttribute('crossorigin') returned null and debugging tools like the built-in Inspector and Firebug did not show an empty crossorigin attribute in the markup.


Expected results:

The parser-inserted script's crossOrigin property should have been set to "anonymous". The script-inserted script should have the "crossorigin" content attribute set and visible to debugging tools.

Comment 1

[James Ide]

My UA is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120402 Firefox/14.0a1"

Comment 2

[Boris Zbarsky [:bzbarsky]]

There's actually just no crossOrigin IDL property at all.  I didn't add one in bug 696301.  You're right that we should add one.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Add a .crossOrigin IDL property. that the content attribute is crossorigin (lowercase) in SVG, hence the need to have different

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 612657 [details] [diff] [review]
Add a .crossOrigin IDL property.   that the content attribute is crossorigin (lowercase) in SVG, hence the need to have different

Review of attachment 612657 [details] [diff] [review]:
-----------------------------------------------------------------

We should use 'using' more to fix the hiding problem for setattr

Comment 5

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Is this in a spec somewhere?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> We should use 'using' more to fix the hiding problem for setattr

That leaves the question of which one to 'use'.  I'm not sure I want to deal with that....

> Is this in a spec somewhere?

Not yet.  I did raise it on whatwg at some point, but not much response.  WebKit did add an IDL property for at least HTML; dunno about SVG.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

i think you can just say "using parentclass::SetAttr;" and you'll get them all.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yes, but parentclass is different for all the subclasses, no?  So I can't put that in the macro; I'd have to sprinkle it all over the tree.  Still worth it?

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think it's something we should do, but it doesn't need to be done here. In fine with landing what you have.

Comment 10

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d966f9a5e4f2

Comment 11

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/d966f9a5e4f2