[Webkit-unassigned] [Bug 63257] When blocking localStorage, Firefox throws a security exception on access, and maybe so should we

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=63257





--- Comment #33 from Dan Carney <dcarney at google.com>  2012-10-18 16:06:40 PST ---
(From update of attachment 169176)
View in context: https://bugs.webkit.org/attachment.cgi?id=169176&action=review

>> Source/WebCore/page/DOMWindow.cpp:749
>> +        if (!m_sessionStorage->area()->canAccessStorage(m_frame)) {
> 
> Are these canAccessStorage() tests really needed for the window.sessionStorage and the window.localStorage accessors? Each method within the storage itself has been modified to test interally, this extra layer of checking on the window attribute value means we'll generally be checking twice per operation, and the first check will incur the larger cost since its bypassing the cached value.
> 
> And if the check on the window attribute value really is needed... as coded it's bypassing the area's cached value and will incur the full cost of looking up the policy value. Could this check utilize the cached value?
> 
> Answering that first question first would be good. If we could avoid the test for the window attribute access all the better.

Presently there in no way to ensure the cache is cleared, so I had to leave an uncached version on calls to window.localStorage and window.sessionStorage since the point of the bug was to replicate firefox's behaviour an throw an exception on bad access.  In general, once the storage object is retrieved, the cache will take over, which is much faster than the present implementation, which is constantly checking with the permissionclient (i think across processes) at great expense.

>> Source/WebKit/chromium/src/StorageAreaProxy.cpp:137
>> +    if (UNLIKELY(!frame || !frame->page()))
> 
> Is there any case where 'frame' would be NULL? Not saying there isn't, just asking.

I don't know, but the null check here has been taken over from the refactor of Storage, which had it all over the place.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.