Bug 81438 - Add support for crossorigin attribute in script elements
: Add support for crossorigin attribute in script elements
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: HTML DOM
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: Nobody
:
Depends on:
Blocks: 70574
  Show dependency treegraph
 
Reported: 2012-03-16 17:59 PDT by Pablo Flouret
Modified: 2012-03-21 00:00 PDT (History)
4 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo Flouret 2012-03-16 17:59:22 PDT
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 Pablo Flouret 2012-03-16 18:08:03 PDT
Created attachment 132433 [details]
Patch
Comment 2 Adam Barth 2012-03-16 18:33:04 PDT
Comment on attachment 132433 [details]
Patch

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 Gyuyoung Kim 2012-03-16 20:39:59 PDT
Comment on attachment 132433 [details]
Patch

Attachment 132433 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11974258
Comment 4 Adam Barth 2012-03-19 00:18:12 PDT
Comment on attachment 132433 [details]
Patch

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 Adam Barth 2012-03-19 00:23:29 PDT
(Obviously, we should address the EFL failure before landing this patch.)
Comment 6 Pablo Flouret 2012-03-19 14:38:37 PDT
(In reply to comment #4)
> (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.

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 Pablo Flouret 2012-03-19 14:39:50 PDT
Created attachment 132674 [details]
Patch for landing
Comment 8 Adam Barth 2012-03-19 21:20:47 PDT
Comment on attachment 132674 [details]
Patch for landing

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 WebKit Review Bot 2012-03-19 22:29:28 PDT
Comment on attachment 132674 [details]
Patch for landing

Clearing flags on attachment: 132674

Committed r111359: <http://trac.webkit.org/changeset/111359>
Comment 10 Darin Fisher (:fishd, Google) 2012-03-21 00:00:24 PDT
Looks like this bug can be closed.