71465 2011-11-03 06:25:10 -0700 [GTK][DRT] implement FrameLoaderClient::didDetectXSS 2012-12-11 07:16:08 -0800 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 104444 Gtk, LayoutTestFailure P2 Normal --- 72166 1 pnormand webkit-unassigned mrobinson zan oldest_to_newest 495405 0 pnormand 2011-11-03 06:25:10 -0700 It was added in http://trac.webkit.org/changeset/99096 Test: http/tests/security/xssAuditor/script-tag-with-callbacks.html 496420 1 zan 2011-11-04 13:36:19 -0700 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 496431 2 mrobinson 2011-11-04 13:42:48 -0700 (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. 496461 3 zan 2011-11-04 14:13:46 -0700 (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. 496467 4 mrobinson 2011-11-04 14:22:57 -0700 (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. 499299 5 zan 2011-11-09 13:20:52 -0800 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. 676828 6 zan 2012-07-24 08:09:43 -0700 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. 788426 7 mrobinson 2012-12-11 07:16:08 -0800 *** This bug has been marked as a duplicate of bug 104444 ***