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.
Created attachment 93019 [details] This creates a test case that shows this bug happening.
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?
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?
(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 :)
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.
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
Closing it as 'invalid'.