Bug 22588 - securityOrigin() should move from Document and WorkerContext into ScriptExecutionContext
Summary: securityOrigin() should move from Document and WorkerContext into ScriptExecu...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-01 22:11 PST by David Levin
Modified: 2008-12-02 00:49 PST (History)
1 user (show)

See Also:

Attachments
patch for bug. (15.46 KB, patch)
2008-12-01 22:54 PST, David Levin 		ap: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Levin 2008-12-01 22:11:02 PST 
Code like XMLHttpRequest should work on either the Document or WorkerContext.

Moving SecurityOrigin into ScriptExecutionContext helps this goal.
Comment 1 David Levin 2008-12-01 22:54:25 PST 
Created attachment 25668 [details]
patch for bug.
Comment 2 Alexey Proskuryakov 2008-12-02 00:20:16 PST 
Comment on attachment 25668 [details]
patch for bug.

r=me

It is quite sad that you have to hack around the difference between ScriptExecutionContext::setSecurityOrigin and Document::setSecurityOrigin. I think that the initDNSPrefetch() call in setSecurityOrigin() is misplaced - there are lots of things that depend on protocol in loader, but we don't eagerly initialize them all in setSecurityOrigin(), or track in Document at all.
Comment 3 Alexey Proskuryakov 2008-12-02 00:49:31 PST 
Committed revision 38900.