The new details about sessionStorage and localStorage are really cool. It would be more powerful if it can show the parent domains. The use case is a website with URLs like pseudo.example.org. Storage is done on example.org in order to access it on every subdomains (by changing the document.domain property). When on pseudo.example.org, the web inspector should list storages on pseudo.example.org and example.org.
(In reply to comment #0) > The new details about sessionStorage and localStorage are really cool. > > It would be more powerful if it can show the parent domains. > > The use case is a website with URLs like pseudo.example.org. Storage is done on > example.org in order to access it on every subdomains (by changing the > document.domain property). When on pseudo.example.org, the web inspector should > list storages on pseudo.example.org and example.org. > Do you have a URL to a test case that I could use? I could not create a test case in which WebKit used the parent url instead of the page url. thanks!
Created attachment 27518 [details] Testcase Creating the testcase, I've seen a related bug. When you open the inspector, it uses the actual document.domain (that can be modified with JS) to chose which localStorage is viewed. I think the best is to show every subdomain possible.
According to Anne Van Kesteren (I asked on IRC), localStorage should not be affected by document.domain. It was my mistake to get the host name from the Security Origin instead of the URL. I will fix that shortly. The same should be for databases.
Created attachment 28120 [details] Use securityOrigin->host() instead of securityOrigin->domain() for display databases, localStorage and sessionStorage are all grouped by databaseIdentifier. And that is based on the host, scheme and port, it is more accurate to display the host, and not the domain.
Landed in r41334.