Bug 60589

Summary: [Qt] REGRESSION(r84099): some pages loaded by setHtml cannot use local storage
Product: WebKit Reporter: Rafael Brandao <rafael.lobo>
Component: WebKit QtAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: benjamin, rafael.lobo
Priority: P5 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
This creates a test case that shows this bug happening. none

Rafael Brandao
Reported 2011-05-10 15:08:38 PDT
Since r84099, pages loaded by QWebFrame::setHtml with blank URLs (empty or "about:blank"), won't be able to use local storage as they now have a globally unique security origin. When the user loads a page with that, wouldn't be desired by him that local storage is accessible in such cases? Actually it may be expected that, no matter what url is defined, the user should still be able to use local storage as he is the one setting the html content. The attachment provides a test case that shows this bug happening. I found it while investigating this bug (https://bugs.webkit.org/show_bug.cgi?id=58847), but I think the discussion of how this should work should be moved to here.
Attachments
This creates a test case that shows this bug happening. (1.69 KB, patch)
2011-05-10 15:09 PDT, Rafael Brandao 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Rafael Brandao
Comment 1 2011-05-10 15:09:28 PDT
Created attachment 93019 [details] This creates a test case that shows this bug happening.
Benjamin Poulain
Comment 2 2011-05-10 16:04:00 PDT
I don't really agree with the expected behavior you suggest. The spec of local storage is making strong assumption about the origin, for security or for data consistency. I think it is reasonable that the API force you to define clearly the origin in order to use local storage. I would say this bug is invalid, and the patch you made for 58847 might be the right solution for the failing test. Any opinion?
Rafael Brandao
Comment 3 2011-05-11 14:11:24 PDT
I think you're correct. The least that could be done, I guess, is to change QWebFrame documentation about this method. Now it says: "(...) baseUrl is optional and used to resolve relative URLs in the document, such as referenced images or stylesheets. (...)". Shouldn't we mention that it is important to determine its security origin or at least mention that he should provide a "valid url" if he wants to use local storage?
Benjamin Poulain
Comment 4 2011-05-11 14:31:08 PDT
(In reply to comment #3) > Shouldn't we mention that it is important to determine its security origin or at least mention that he should provide a "valid url" if he wants to use local storage? That could be good if that does not mean a much more complicated documentation. If you document that, you should keep it generic. Quite a few HTML 5 features depend on a valid origin (geolocation's authorizations for example). If you find some good way to express the issue in the doc, I am all for it :)
Rafael Brandao
Comment 5 2011-05-12 12:11:55 PDT
I had no idea that it was also used in many other features. I'll take a look on HTML5 specs to learn more about it, but I can imagine how hard it may be to keep the documentation simple but more informative.
Rafael Brandao
Comment 6 2011-05-12 12:15:47 PDT
So this bug will be marked as invalid, but we will still have the documentation problem. Should that be reported as another bug? Not sure if we could call this a bug (in documentation). In this case I'll leave it up to you to decide. :P
Rafael Brandao
Comment 7 2011-07-22 07:09:32 PDT
Closing it as 'invalid'.
Note You need to log in before you can comment on or make changes to this bug.