RESOLVED FIXED Bug 116225
[GTK] Remote Web Inspector sometimes won't serve any content
https://bugs.webkit.org/show_bug.cgi?id=116225
Summary [GTK] Remote Web Inspector sometimes won't serve any content
Simon Pena
Reported 2013-05-16 08:11:47 PDT
Accessing the remote web inspector sometimes results in an empty page, as it won't serve any content. With WebKit built but not installed, and the environment variable WEBKIT_INSPECTOR_SERVER pointing to a valid address (e.g. 127.0.0.1:2999), launch MiniBrowser and then try to access the access given from a different browser. In my research, this is caused by the WebInspectorServerGtk not finding the needed resources in the expected path. It could probably be fixed by providing an environment variable (in the same fashion done in the InspectorClientGtk) so users can provide their own inspector resources. (Other, maybe more sophisticated, methods could try to guess where this content is stored).
Attachments
Patch (3.62 KB, patch)
2013-05-16 10:04 PDT, Anton Obzhirov
no flags
Patch (3.64 KB, patch)
2013-05-21 09:02 PDT, Anton Obzhirov
no flags
Patch (3.40 KB, patch)
2013-05-22 03:03 PDT, Anton Obzhirov
no flags
Anton Obzhirov
Comment 1 2013-05-16 08:15:02 PDT
OK, I'll fix it. I think someone complained about it last year as well.
Anton Obzhirov
Comment 2 2013-05-16 10:04:33 PDT
Simon Pena
Comment 3 2013-05-17 07:44:26 PDT
CCing Gustavo, who reviewed the initial implementation of GTK's remote web inspector in #88094
Gustavo Noronha (kov)
Comment 4 2013-05-20 10:42:40 PDT
Comment on attachment 201967 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=201967&action=review > Source/WebKit2/ChangeLog:3 > + [GTK] Remote Web Inspector sometimes won't serve any content I feel this bug title is a bit misleading, perhaps it should say that the remote inspector is only able to serve files from the configured install path.
Gustavo Noronha (kov)
Comment 5 2013-05-20 10:44:03 PDT
Comment on attachment 201967 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=201967&action=review > Source/WebKit2/UIProcess/InspectorServer/WebInspectorServer.h:76 > + GOwnPtr<gchar> m_inspectorServerFilesPath; Oh, actually, why not just use CString?
Anton Obzhirov
Comment 6 2013-05-21 01:55:24 PDT
Well, in this case I just wanted smart pointer to own char string. Didn't really need other functionality of CString. Seems to be safer to use GOwnPtr. I think in similar code in InspectorClientGtk they use smart pointer as well.
Gustavo Noronha (kov)
Comment 7 2013-05-21 05:41:04 PDT
We used char pointers a lot in the early days of webkitgtk, but we have mostly switched to using CString for storing strings in more recent times to avoid allocation churn and make the code simpler. I don't feel too strongly about this, but I think using a smart pointer is unnecessary in this case.
Anton Obzhirov
Comment 8 2013-05-21 07:25:16 PDT
ok, point taken. I will resubmit the patch.
Anton Obzhirov
Comment 9 2013-05-21 09:02:30 PDT
Gustavo Noronha (kov)
Comment 10 2013-05-21 10:13:52 PDT
Comment on attachment 202438 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=202438&action=review > Source/WebKit2/UIProcess/InspectorServer/WebInspectorServer.h:75 > + const char* inspectorServerFilesPath(); I think it doesn't make sense to use a char pointer just here, just return the CString? In fact, you can just use WTFString and avoid the other include IMO.
Anton Obzhirov
Comment 11 2013-05-22 03:03:36 PDT
Anton Obzhirov
Comment 12 2013-05-22 03:06:23 PDT
I used webkit-patch apply-from-bug script option. So it still shows Gustavo as a reviewer.
Gustavo Noronha (kov)
Comment 13 2013-05-23 05:24:15 PDT
Comment on attachment 202514 [details] Patch Thanks!
WebKit Commit Bot
Comment 14 2013-05-23 05:45:36 PDT
Comment on attachment 202514 [details] Patch Clearing flags on attachment: 202514 Committed r150582: <http://trac.webkit.org/changeset/150582>
WebKit Commit Bot
Comment 15 2013-05-23 05:45:39 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.