WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
81438
Add support for crossorigin attribute in script elements
https://bugs.webkit.org/show_bug.cgi?id=81438
Summary
Add support for crossorigin attribute in script elements
Pablo Flouret
Reported
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.
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
View All
Add attachment
proposed patch, testcase, etc.
Pablo Flouret
Comment 1
2012-03-16 18:08:03 PDT
Created
attachment 132433
[details]
Patch
Adam Barth
Comment 2
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.
Gyuyoung Kim
Comment 3
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
Adam Barth
Comment 4
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.
Adam Barth
Comment 5
2012-03-19 00:23:29 PDT
(Obviously, we should address the EFL failure before landing this patch.)
Pablo Flouret
Comment 6
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.
Pablo Flouret
Comment 7
2012-03-19 14:39:50 PDT
Created
attachment 132674
[details]
Patch for landing
Adam Barth
Comment 8
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.
WebKit Review Bot
Comment 9
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
>
Darin Fisher (:fishd, Google)
Comment 10
2012-03-21 00:00:24 PDT
Looks like this bug can be closed.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug