Bug 71465 – [GTK][DRT] implement FrameLoaderClient::didDetectXSS

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKitGTK

[Philippe Normand]

It was added in http://trac.webkit.org/changeset/99096
Test: http/tests/security/xssAuditor/script-tag-with-callbacks.html

[Zan Dobersek]

Looking around this test, I've seen that FrameLoaderClient::didDetectXSS is called, so the line containing 'didDetectXSS' should be written into output, but the problem occurs when transporting this information to DumpRenderTree.

When bringing up layout tests support for Clutter's port of WebKit, I created a DRTSupportGObject singleton structure[1][1.1]. Its purpose is to hold various signals that could easily be emitted from WebKit library[2] and to which it would be simple to connect[3] and then output the gathered information[4].

I propose the same kind of approach to be utilized in the Gtk port. Of course, in a different bug.


[1] https://gitorious.org/webkit-clutter/webkit-clutter/blobs/master/Source/WebKit/gobject/WebCoreSupport/DumpRenderTreeSupportGObject.cpp
[1.1] https://gitorious.org/webkit-clutter/webkit-clutter/blobs/master/Source/WebKit/clutter/WebCoreSupport/DumpRenderTreeSupportClutter.cpp#line85
[2] https://gitorious.org/webkit-clutter/webkit-clutter/blobs/master/Source/WebKit/gobject/WebCoreSupport/FrameLoaderClientGObject.cpp#line803
[3] https://gitorious.org/webkit-clutter/webkit-clutter/blobs/master/Tools/DumpRenderTree/clutter/DumpRenderTree.cpp#line799
[4] https://gitorious.org/webkit-clutter/webkit-clutter/blobs/master/Tools/DumpRenderTree/clutter/DumpRenderTree.cpp#line732

[Martin Robinson]

(In reply to comment #1)
> Looking around this test, I've seen that FrameLoaderClient::didDetectXSS is called, so the line containing 'didDetectXSS' should be written into output, but the problem occurs when transporting this information to DumpRenderTree.

Do other ports expose this in their API? It might be useful to just add the signal.

[Zan Dobersek]

(In reply to comment #2)
> (In reply to comment #1)
> > Looking around this test, I've seen that FrameLoaderClient::didDetectXSS is called, so the line containing 'didDetectXSS' should be written into output, but the problem occurs when transporting this information to DumpRenderTree.
> 
> Do other ports expose this in their API? It might be useful to just add the signal.

Chromium and Mac seem to do so, while Win doesn't implement it yet and Qt only outputs 'didDetectXSS' if in test mode.

This seems to be a worthy candidate for exposing it in our API. With some further direction -- where (object-wise) and how (method-wise, signal probably) to put it -- I can put a patch together.

Still, spare a thought for that DRTGObject. I find it to be an efficient way of translating information towards DumpRenderTree, especially in cases when decisions haven't yet been made about APIs or if the information is for testing purposes only.

[Martin Robinson]

(In reply to comment #3)

> Still, spare a thought for that DRTGObject. I find it to be an efficient way of translating information towards DumpRenderTree, especially in cases when decisions haven't yet been made about APIs or if the information is for testing purposes only.

It sounds like a decent idea to me. Currently we try to hide signals like this by simply not documenting them. That isn't a great method. If we go this route I'd prefer to move all of DumpRenderTreeSupport to this object. We'd also need to be sure to hide it from gtkdoc.

[Zan Dobersek]

Marked this bug to depend on #71948.

The work in #71948 will also include implementation of FrameLoaderClientGtk::didDetectXSS. When this function will be called, a signal will be emitted on WebKitWebFrame on which we should be able to connect in DumpRenderTree and then properly show that the signal was received as needed.

[Zan Dobersek]

Given the focus is now shifting towards WebKit2 APIs and WebKit2 in general, meaning new API additions to WebKit1 don't really make sense, I'm going to close this bug as a WONTFIX.

[Martin Robinson]

*** This bug has been marked as a duplicate of bug 104444 ***