Bug 60589 – [Qt] REGRESSION(r84099): some pages loaded by setHtml cannot use local storage

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Qt

[Rafael Brandao]

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.

[Rafael Brandao]

Created attachment 93019 [details]
This creates a test case that shows this bug happening.

[Benjamin Poulain]

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]

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]

(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]

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]

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]

Closing it as 'invalid'.