Bug 31835
| Summary: | The URL "file://" should not cause m_noAccess to be set on SecurityOrigin. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adam Barth <abarth> |
| Component: | WebKit API | Assignee: | Jeremy Orlow <jorlow> |
| Status: | ASSIGNED | ||
| Severity: | Normal | CC: | jorlow |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Adam Barth
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Jeremy Orlow
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.
Adam Barth
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.