Bug 31835 - The URL "file://" should not cause m_noAccess to be set on SecurityOrigin.
Summary: The URL "file://" should not cause m_noAccess to be set on SecurityOrigin.
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Jeremy Orlow
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-24 08:18 PST by Adam Barth
Modified: 2009-11-30 16:09 PST (History)
1 user (show)

See Also:

Attachments
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 Adam Barth 2009-11-24 08:18:56 PST 
In http://trac.webkit.org/changeset/51338, we landed a temporary fix for Bug 31833.  The right fix is to use WebSecurityOrigin to represent SecurityOrigin objects instead of using strings.
Comment 1 Jeremy Orlow 2009-11-30 16:04:13 PST 
I am going to switch the chromium api over to using WebSecurityOrigin, but that's not the actual issue.  The actual issue is that we've found a corner case where createFromString(securityOrigin.toString()) != securityOrigin.  That's what should be fixed.
Comment 2 Adam Barth 2009-11-30 16:09:12 PST 
Jeremy and I chatted on IRC.  createFromString(securityOrigin.toString()) can't entirely round-trip (e.g. document.domain, @sandbox), but we think it makes sense to round-trip in this case.