Summary: | Web Inspector: sendMessageToFrontend implementation required. | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ilya Tikhonovsky <loislo> | ||||||||||||||||||||
Component: | Web Inspector (Deprecated) | Assignee: | Nobody <webkit-unassigned> | ||||||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||||||
Severity: | Normal | CC: | abarth, bweinstein, eric, gustavo, joepeck, keishi, mike, pfeldman, pmuellr, rik, timothy, webkit-ews, webkit.review.bot, xan.lopez, yurys | ||||||||||||||||||||
Priority: | P2 | ||||||||||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||||||||
Hardware: | All | ||||||||||||||||||||||
OS: | All | ||||||||||||||||||||||
Bug Depends on: | 40365 | ||||||||||||||||||||||
Bug Blocks: | |||||||||||||||||||||||
Attachments: |
|
Description
Ilya Tikhonovsky
2010-06-03 11:39:17 PDT
Created attachment 57799 [details]
[patch] initial version.
This is the second step on the way to the remote debugging.
The first one was InspectorValues classes for native serialization to JSON.
This step is a transport for WebInspector data in JSON format between inspected page and a front-end.
Attachment 57799 [details] did not build on gtk: Build output: http://webkit-commit-queue.appspot.com/results/2995042 Created attachment 57805 [details]
[patch] second iteration. With fixed gtk build and other minor changes.
Comment on attachment 57799 [details] [patch] initial version. > +++ b/WebCore/inspector/InspectorFrontend.cpp > +InspectorFrontend::InspectorFrontend(ScriptObject webInspector, InspectorClient* inspectorClient) > + : m_webInspector(webInspector), m_inspectorClient(inspectorClient) I think the usual style for this is: : m_a(a) , m_b(b) > - ASSERT(frontend); Should we change this to ASSERT(webInspector)? Or will this be expected to handle a case of a null ScriptCobject. > +++ b/WebCore/inspector/InspectorFrontend.h > +#include <wtf/RefPtr.h> > ... > + void addRecordToTimeline(const RefPtr<InspectorObject>&); Is this used in this patch? If not, I would say leave this out for the next patch. > + InspectorClient* m_inspectorClient; Likewise this is added and included in the constructor above but it isn't used yet. I have an idea how it will be used, but I think before this patch lands there should be another patch showing an example usage, even if its trivial. > +++ b/WebCore/inspector/InspectorClient.h > + virtual bool sendMessageToFrontend(const String& message) = 0; It might be worth mentioning what the bool return value here means. If not a comment then certainly something in the ChangeLog. Great work on this so far! (In reply to comment #4) > (From update of attachment 57799 [details]) > > +++ b/WebCore/inspector/InspectorFrontend.cpp > > +InspectorFrontend::InspectorFrontend(ScriptObject webInspector, InspectorClient* inspectorClient) > > + : m_webInspector(webInspector), m_inspectorClient(inspectorClient) > > I think the usual style for this is: > > : m_a(a) > , m_b(b) ok > > - ASSERT(frontend); > > Should we change this to ASSERT(webInspector)? Or will this be > expected to handle a case of a null ScriptCobject. as far as it is transfered by ref we don't need to check that. > > +++ b/WebCore/inspector/InspectorFrontend.h > > +#include <wtf/RefPtr.h> > > ... > > + void addRecordToTimeline(const RefPtr<InspectorObject>&); > > Is this used in this patch? If not, I would say leave this out > for the next patch. Already fixed this in the second iteration. > > + InspectorClient* m_inspectorClient; > > Likewise this is added and included in the constructor above > but it isn't used yet. I have an idea how it will be used, but > I think before this patch lands there should be another patch > showing an example usage, even if its trivial. I'm trying to keep the patches small and the next patches will use m_inspectorClient for the real transfer data. As result I think we don't need a special example of usage. > > +++ b/WebCore/inspector/InspectorClient.h > > + virtual bool sendMessageToFrontend(const String& message) = 0; > > It might be worth mentioning what the bool return value here > means. If not a comment then certainly something in the ChangeLog. ok. > Great work on this so far! thanks. Comment on attachment 57805 [details]
[patch] second iteration. With fixed gtk build and other minor changes.
WebCore/ChangeLog:5
+ WebInspector: It should be possible to transfer timeline/dom/etc data from inspected page side to the front-end side in serialized format.
Please wrap it at 80 chars or so.
WebCore/inspector/InspectorController.cpp:429
+ void InspectorController::connectFrontend(const ScriptObject& webInspector)
I think "attach" would be a better name. Also I would leave a comment saying that webInspector parameter is going to go away once we migrate to the new schema.
WebKit/mac/WebCoreSupport/WebInspectorClient.mm:107
+ return m_webInspectorFrontendClient->dispatchMessageToFrontend(message);
This one is I think wrong. You are telling client of the inspected page (InspectorClient) to dispatch message on the frontend via the InspectorFrontend's client. But methods on client are to be called by WebCore, not WebKit. You should simply get a pointer to the Page and dispatch the JS call there.
WebCore/WebCore.Inspector.exp:24
+ __ZN7WebCore28InspectorFrontendClientLocal25dispatchMessageToFrontendERKNS_6StringE
This one should not be visible to WebKit. In fact, this entire InspectorFrontendClientLocal class should go away since it exposes a way too rich WebCore API to the WebKit.
WebKit/qt/WebCoreSupport/InspectorClientQt.cpp:165
+ return false;
You plan on implementing these prior to landing, right?
Created attachment 57915 [details]
[patch] third iteration
Safari specific code for sendMessage was moved to new class InspectorClientLocal.
We have attachFrontend/disconnectFrontend pair and that was inconsistent.
Now it is consistent and I think there is no principal difference between connect/disconnect and attach/detach pairs.
I can use any.
Qt implementation was added.
Attachment 57915 [details] did not build on qt: Build output: http://webkit-commit-queue.appspot.com/results/3104031 Comment on attachment 57915 [details]
[patch] third iteration
WebKit/mac/WebCoreSupport/WebInspectorClient.mm:99
+ m_frontendPage = core([windowController.get() webView]);
Here and in other clients m_frontendPage should be cleared when the frontend is destroyed.
Comment on attachment 57915 [details]
[patch] third iteration
WebKit/chromium/src/InspectorClientImpl.cpp:110
+ if (!devToolsAgent)
is this code reachable? if not, put ASSERT_NOT_REACHED(); here
Created attachment 58040 [details]
[patch] fourth iteration.
Attachment 58040 [details] did not build on qt: Build output: http://webkit-commit-queue.appspot.com/results/3133197 Comment on attachment 58040 [details]
[patch] fourth iteration.
WebCore/inspector/InspectorClient.h:53
+ virtual bool sendMessageToFrontend(const String& message) = 0;
const String& (no 'message')
WebCore/inspector/InspectorController.h:139
+ // transport via InspectorClient. After finish webInspector parameter should
... After migration, WebInspector parameter should ...
WebKit/cf/WebCoreSupport/WebInspectorClientCF.cpp:116
+ String dispatchToFrontend("WebInspector.dispatchMessageToFrontend(");
String::format
WebKit/gtk/WebCoreSupport/InspectorClientGtk.cpp:91
+ m_frontendPage = 0;
What happens when page->inspectorController()->close() is called?
WebKit/gtk/WebCoreSupport/InspectorClientGtk.cpp:127
+ String dispatchToFrontend("WebInspector.dispatchMessageToFrontend(");
Should we format this message using utility method in WebCore?
WebKit/mac/WebCoreSupport/WebInspectorClient.h:46
+
no need in blank lines here and below.
WebKit/mac/WebCoreSupport/WebInspectorClient.h:66
+ virtual bool sendMessageToFrontend(const WebCore::String& key);
key -> message (or even better, remove it!)
WebCore/inspector/InspectorController.cpp:535
+ m_client->closeInspectorFrontend();
disconnectFrontend is being called by the WebKit layer. After this call, InspectorController should not do any attempts to talk to its frontend. You don't need to call WebCore's disconnectFrontend from WebKit in order to get immediately back to WebKit and execute closeInspectorFrontend...
Created attachment 58119 [details]
[patch] Fifth version. Just try to get qt build happy.
Attachment 58119 [details] did not pass style-queue:
Failed to run "['WebKitTools/Scripts/check-webkit-style', '--no-squash']" exit_code: 1
WebKit/qt/WebCoreSupport/InspectorClientQt.cpp:43: Alphabetical sorting problem. [build/include_order] [4]
Total errors found: 1 in 37 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 58139 [details]
[patch] sixth iteration.
Attachment 58139 [details] did not build on gtk: Build output: http://webkit-commit-queue.appspot.com/results/3181043 Comment on attachment 58139 [details] [patch] sixth iteration. > WebKit/efl/WebCoreSupport/InspectorClientEfl.cpp > +bool InspectorClientEfl::sendMessageToFrontend(const String&) > +{ > + notImpelemented(); > + return false; > +} Eek, typo. s/notImpelemented/notImplemented/ > WebKit/mac/WebCoreSupport/WebInspectorClient.h > +namespace WebCore { > + > +class Page; > + > +} All other forwarding headers like this in WebKit/mac are formatted like so: namespace WebCore { class Page; } > WebKit/win/WebCoreSupport/WebInspectorClient.h > +namespace WebCore { > + > +class Page; > + > +} Ditto. As you know Pavel's comments are still to be addressed as well. But its looking good. Comment on attachment 58139 [details]
[patch] sixth iteration.
WebCore/inspector/InspectorClient.h:45
+ virtual void closeInspectorFrontend() = 0;
This one is no longer used and can go away, right?
WebCore/inspector/front-end/inspector.js:575
+ WebInspector.dispatchMessageToFrontend = function(arguments)
Nit: I'd call it dispatchMessageFromBackend. Also, we might want to have try / catch here for the transition phase that would log into WebInspector.log.
WebCore/loader/EmptyClients.h:483
+ virtual void closeInspectorFrontend() { }
Remove this?
WebKit/chromium/src/InspectorClientImpl.cpp:70
+ void InspectorClientImpl::closeInspectorFrontend()
Unused?
WebKit/efl/WebCoreSupport/InspectorClientEfl.cpp:41
+ void InspectorClientEfl::closeInspectorFrontend()
Remove?
WebKit/efl/WebCoreSupport/InspectorClientEfl.h:47
+ virtual void closeInspectorFrontend();
ditto
Pushed wrong button half-review. To be continued. Comment on attachment 58139 [details]
[patch] sixth iteration.
One minor cleanup and we are good to land!
WebKit/gtk/WebCoreSupport/InspectorClientGtk.cpp:168
+ m_inspectorClient->closeInspectorClient();
closeInspectorFrontend() ? Also, I'd name it "releaseFrontendPage" since it better reflects what it does.
WebKit/haiku/WebCoreSupport/InspectorClientHaiku.cpp:50
+ void InspectorClientHaiku::closeInspectorFrontend()
nuke it
WebKit/haiku/WebCoreSupport/InspectorClientHaiku.h:46
+ virtual void closeInspectorFrontend();
ditto
WebKit/mac/WebCoreSupport/WebInspectorClient.h:58
+ virtual void closeInspectorFrontend();
same recommendation on the name...
WebKit/qt/WebCoreSupport/InspectorClientQt.cpp:113
+ void InspectorClientQt::closeInspectorFrontend()
ditto
WebKit/wx/WebKitSupport/InspectorClientWx.cpp:55
+ void InspectorClientWx::closeInspectorFrontend()
nuke
Created attachment 58238 [details]
[patch] seventh iteration.
Comment on attachment 58238 [details]
[patch] seventh iteration.
Nit: could you please work on the changelog entry to make our plans more clear?
http://trac.webkit.org/changeset/60891 might have broken GTK Linux 32-bit Debug The following changes are on the blame list: http://trac.webkit.org/changeset/60890 http://trac.webkit.org/changeset/60891 http://trac.webkit.org/changeset/60892 Created attachment 58390 [details]
[patch] next iteration with fixes for gtk
Comment on attachment 58390 [details]
[patch] next iteration with fixes for gtk
WebKit/gtk/WebCoreSupport/InspectorClientGtk.h:50
+ ~InspectorFrontendClient()
Does it compile? Should be ~InspectorClient() I suppose
Comment on attachment 58390 [details]
[patch] next iteration with fixes for gtk
WebKit/gtk/WebCoreSupport/InspectorClientGtk.cpp:174
+ if (m_inspectorClient)
I see m_inspectorClient cleared only in the destructor, do you really need this check?
(In reply to comment #27) > (From update of attachment 58390 [details]) > WebKit/gtk/WebCoreSupport/InspectorClientGtk.cpp:174 > + if (m_inspectorClient) > I see m_inspectorClient cleared only in the destructor, do you really need this check? Really we have no guaranties about the order of deleting the InspectorClient and InspectorFrontend. Attachment 58390 [details] did not build on gtk: Build output: http://webkit-commit-queue.appspot.com/results/3177153 Created attachment 58454 [details]
[patch] next iteration.
Comment on attachment 58454 [details]
[patch] next iteration.
Best to land manually.
Committing to http://svn.webkit.org/repository/webkit/trunk ... M WebCore/ChangeLog M WebCore/inspector/InspectorClient.h M WebCore/inspector/InspectorController.cpp M WebCore/inspector/InspectorController.h M WebCore/inspector/InspectorFrontend.cpp M WebCore/inspector/InspectorFrontend.h M WebCore/inspector/InspectorFrontendClientLocal.cpp M WebCore/inspector/InspectorValues.cpp M WebCore/inspector/front-end/inspector.js M WebCore/loader/EmptyClients.h M WebKit/ChangeLog M WebKit/cf/ChangeLog M WebKit/cf/WebCoreSupport/WebInspectorClientCF.cpp M WebKit/chromium/ChangeLog M WebKit/chromium/src/InspectorClientImpl.cpp M WebKit/chromium/src/InspectorClientImpl.h M WebKit/chromium/src/WebDevToolsAgentImpl.cpp M WebKit/efl/WebCoreSupport/InspectorClientEfl.cpp M WebKit/efl/WebCoreSupport/InspectorClientEfl.h M WebKit/gtk/ChangeLog M WebKit/gtk/WebCoreSupport/InspectorClientGtk.cpp M WebKit/gtk/WebCoreSupport/InspectorClientGtk.h M WebKit/haiku/ChangeLog M WebKit/haiku/WebCoreSupport/InspectorClientHaiku.cpp M WebKit/haiku/WebCoreSupport/InspectorClientHaiku.h M WebKit/mac/ChangeLog M WebKit/mac/WebCoreSupport/WebInspectorClient.h M WebKit/mac/WebCoreSupport/WebInspectorClient.mm M WebKit/qt/ChangeLog M WebKit/qt/WebCoreSupport/InspectorClientQt.cpp M WebKit/qt/WebCoreSupport/InspectorClientQt.h M WebKit/win/ChangeLog M WebKit/win/WebCoreSupport/WebInspectorClient.cpp M WebKit/win/WebCoreSupport/WebInspectorClient.h M WebKit/wx/ChangeLog M WebKit/wx/WebKitSupport/InspectorClientWx.cpp M WebKit/wx/WebKitSupport/InspectorClientWx.h Committed r61113 Flaky inspector tests fix for gtk. Committing to http://svn.webkit.org/repository/webkit/trunk ... M WebKit/gtk/ChangeLog M WebKit/gtk/WebCoreSupport/InspectorClientGtk.cpp Committed r61124 |