[webkit-reviews] review requested: [Bug 63236] [Qt] Fix tst_QWebFrame::renderGeometry() API test : [Attachment 99384] We need a proper security origin in order to load local resources, so specified a local file to be its baseUrl.

[bugzilla-daemon at webkit.org]

Rafael Brandao <rafael.lobo at openbossa.org> has asked  for review:
Bug 63236: [Qt] Fix tst_QWebFrame::renderGeometry() API test
https://bugs.webkit.org/show_bug.cgi?id=63236

Attachment 99384: We need a proper security origin in order to load local
resources, so specified a local file to be its baseUrl.
https://bugs.webkit.org/attachment.cgi?id=99384&action=review

------- Additional Comments from Rafael Brandao <rafael.lobo at openbossa.org>
It took me a while, but this patch made this "bug" appears:
https://bugs.webkit.org/show_bug.cgi?id=61494. I've explained there how it is
happening, and it looks like it didn't affect the other ports. But sincerely I
think we've been using setHtml in the wrong way.

On QWebPagePrivate's constructor, you can see it's setting a SecurityOrigin
policy to allow local files and substitute data to load local resources, but
the user of the API is not aware of this (correct me if I'm wrong), and until
that patch they were able to do exactly like the test was using. And I've
already seen many other circumstances where I would think a certain behavior
would happen and then had to specify a valid baseUrl to do it (local storage
for example). So if we agree with this current behavior, then it looks like our
API docs must reflect this in a better way.

The other option to fix this is to correct what was introduced by that patch,
but still it looks awkward (for me) that we're doing this little exception here
to download local resources, and to everything else we must get a proper
security origin.

The other bug (https://bugs.webkit.org/show_bug.cgi?id=63235) could also be
fixed like this, and I could also add there a case where the user specify the
substitute data but do not provide a valid origin, so we can test both
behaviors (as the other test is actually testing substitute data with local
resources, differently from this one).

Waiting for feedback. :)