In chrome, Web Inspector uses "chrome:" schema which has very limited permissions. However, we want to use localStorage to store front-end settings.
Created attachment 70884 [details] Patch.
Comment on attachment 70884 [details] Patch. These "grant" API are like grenades without a pin. We shouldn't have them at all. A better design might be to run the inspector in the "chrome-extension" scheme. That way it can have its own public key to define who should have access to its local storage.
Attachment 70884 [details] did not build on qt: Build output: http://queues.webkit.org/results/4419052
Attachment 70884 [details] did not build on mac: Build output: http://queues.webkit.org/results/4470040
Comment on attachment 70884 [details] Patch. View in context: https://bugs.webkit.org/attachment.cgi?id=70884&action=review > WebCore/page/SecurityOrigin.h:124 > bool canAccessDatabase() const { return !isUnique(); } At some point we might want to use database and filesystem from within inspector. So the right solution is to make inspector non-Unique on all the platforms.
(In reply to comment #5) > (From update of attachment 70884 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=70884&action=review > > > WebCore/page/SecurityOrigin.h:124 > > bool canAccessDatabase() const { return !isUnique(); } > > At some point we might want to use database and filesystem from within inspector. So the right solution is to make inspector non-Unique on all the platforms. Indeed. However, we shouldn't do that by granting it magical privileges. Instead, we should use a URL scheme that doesn't impose uniqueness.
> Indeed. However, we shouldn't do that by granting it magical privileges. Instead, we should use a URL scheme that doesn't impose uniqueness. +1. That's exactly what I meant in the "non-Unique" part of the comment.