Bug 81438 - Add support for crossorigin attribute in script elements
: Add support for crossorigin attribute in script elements
Status: RESOLVED FIXED
: WebKit
HTML DOM
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
:
: 70574
  Show dependency treegraph
 
Reported: 2012-03-16 17:59 PST by
Modified: 2012-03-21 00:00 PST (History)


Attachments
Patch (11.00 KB, patch)
2012-03-16 18:08 PST, Pablo Flouret
abarth: review+
gyuyoung.kim: commit‑queue-
Review Patch | Details | Formatted Diff | Diff
Patch for landing (11.93 KB, patch)
2012-03-19 14:39 PST, Pablo Flouret
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


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.