Bug 81438

Summary: Add support for crossorigin attribute in script elements
Product: WebKit Reporter: Pablo Flouret <pf@parb.es>
Component: HTML DOMAssignee: Nobody <webkit-unassigned@lists.webkit.org>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth@webkit.org, fishd@chromium.org, ojan@chromium.org, webkit.review.bot@gmail.com
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 70574    
Attachments:
Description Flags
Patch
abarth: review+, gyuyoung.kim: commit‑queue-
Patch for landing none

Description From 2012-03-16 17:59:22 PST
Basically mirror img's crossorigin attribute behavior for script.

Gecko added it recently https://bugzilla.mozilla.org/show_bug.cgi?id=696301

Mail went out to the whatwg with no response so far, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-February/034969.html
I'll bump the thread to see if anyone has any thoughts.
------- Comment #1 From 2012-03-16 18:08:03 PST -------
Created an attachment (id=132433) [details]
Patch
------- Comment #2 From 2012-03-16 18:33:04 PST -------
(From update of attachment 132433 [details])
I took a quick look and this looks pretty good.  I'll look in more detail later if no one beats me to the punch.
------- Comment #3 From 2012-03-16 20:39:59 PST -------
(From update of attachment 132433 [details])
Attachment 132433 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11974258
------- Comment #4 From 2012-03-19 00:18:12 PST -------
(From update of attachment 132433 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=132433&action=review

> Source/WebCore/dom/ScriptElement.cpp:320
> +    if (m_element->fastHasAttribute(HTMLNames::crossoriginAttr)

So, this isn't 100% correct.  We should lock in the notion of whether this is a crossorigin load when the load is initiated.  By re-checking the attribute here, we might get a different value the second time.  That's an extremely minor bug though.
------- Comment #5 From 2012-03-19 00:23:29 PST -------
(Obviously, we should address the EFL failure before landing this patch.)
------- Comment #6 From 2012-03-19 14:38:37 PST -------
(In reply to comment #4)
> (From update of attachment 132433 [details] [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=132433&action=review
> 
> > Source/WebCore/dom/ScriptElement.cpp:320
> > +    if (m_element->fastHasAttribute(HTMLNames::crossoriginAttr)
> 
> So, this isn't 100% correct.  We should lock in the notion of whether this is a crossorigin load when the load is initiated.  By re-checking the attribute here, we might get a different value the second time.  That's an extremely minor bug though.

Yeah, good catch. ImageLoader::notifyFinished() should probably be fixed as well (although the code there doesn't really prevent the image from loading at the moment, i guess there's bug 80028 for that).

(In reply to comment #5)
> (Obviously, we should address the EFL failure before landing this patch.)

EFL woes look unrelated, i'll upload a new patch and see if ews comes to the rescue.
------- Comment #7 From 2012-03-19 14:39:50 PST -------
Created an attachment (id=132674) [details]
Patch for landing
------- Comment #8 From 2012-03-19 21:20:47 PST -------
(From update of attachment 132674 [details])
I'm tired of waiting for the efl-ews.  I think you're right that the failure wasn't caused by your patch.
------- Comment #9 From 2012-03-19 22:29:28 PST -------
(From update of attachment 132674 [details])
Clearing flags on attachment: 132674

Committed r111359: <http://trac.webkit.org/changeset/111359>
------- Comment #10 From 2012-03-21 00:00:24 PST -------
Looks like this bug can be closed.