Bug 59972 – [Qt] QtWebKit bridge assignToHTMLImageElement() results in Image with different SecurityOrigin

• Component: WebKit Qt
• Status: RESOLVED INVALID

[Andrew Wason]

Created attachment 91999 [details]
sample Qt app that demonstrates the problem

Attached sample app installs a context object in a QWebPage which has a method that returns a QImage. In the loaded HTML, this image is assigned to a JavaScript Image object then drawn into an HTML canvas via drawImage(). Then getImageData() is called on the canvas.

getImageData() raises an exception "SECURITY_ERR: DOM Exception 18: An attempt was made to break through the security policy of the user agent."

This seems to be because the JS Image contains a CachedImage with no URL, and Source/WebCore/html/canvas/CanvasRenderingContext.cpp CanvasRenderingContext::checkOrigin(HTMLImageElement*) calls checkOrigin(cachedImage->response().url()) and the empty url isValid() is false so it uses a unique SecurityOrigin with an empty KURL(), which is different than the pages SecurityOrigin.

I think images created by the hosting app via the bridge should adopt the SecurityOrigin of the page. Or maybe a QWebSetting should be provided to disable this origin checking? Setting QWebSettings::LocalContentCanAccessRemoteUrls doesn't help.

Build the attached app then run "./origin $PWD/canvas.html"

[Andrew Wason]

Setting the documents URL on the CachedImage (as discussed in bug #60770) does not fix this because the StillImage the bridge creates returns false from Image::hasSingleSecurityOrigin().

So even when the CachedImage::response().url() passes checks in CanvasRenderingContext::checkOrigin(KURL&), we still end up tainting the canvas in CanvasRenderingContext::checkOrigin(HTMLImageElement*):

    if (canvas()->originClean() && !cachedImage->image()->hasSingleSecurityOrigin())
        canvas()->setOriginTainted();

Should StillImage override hasSingleSecurityOrigin() to return true like BitmapImage does?

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.