[Webkit-unassigned] [Bug 92429] Web Inspector: Add support for debugging Inspector LayoutTests w/Inspector

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=92429





--- Comment #3 from johnjbarton <johnjbarton at chromium.org>  2012-07-27 10:09:33 PST ---
(In reply to comment #2)
> I like the general idea of enabling debugging of layout tests, but in my view, this particular approach is too much of a hack to expose even as an experiment. 

I agree that this looks hacky at first, but only because we are calling eval() on something sent to us. The eval() is a consequence of how LayoutTests work; I guess all solutions will require eval(). We might have other ways to send the script but this one gives a high degree of security. 

One small improvement I thought about this morning would 
  1) add a function to ExtensionServer to check if a URL is a registered extension,
  2) move the eval() into a separate onmessage handler in another small .js file and have it check the origins using the new function from #1.
Would this be better?

>How about requiring a remote front-end for debugging layout tests? This way, it will run as a "normal" web page and you'll be able to inject scripts there with your extension. This could even be taken further -- your mock test runner, upon a call to showWebInspector() could request the background page to open a new tab and navigate it to the (remote) front-end and inject the code that install a listener for the message event on window. Perhaps, you could also monkey-patch the InspectedFrontendHostStub to have its sendMessageToBackend() to actually send message to background page, which would relay it to back-end through chrome.debugger API -- this way, one wouldn't event have to explicitly enable remote debugging ws server.
> Actually, many other methods of InspectedFrontendHost may be implemented via an extension, which would allow for a nearly full-functional remote front-end -- quite useful beyond the scope of debugging, I think.

Yes, I agree this would be a great idea, but I've already tried all of the combinations like this I can think up.  I have a functional inspector/front_end in a chrome extension operating over chrome.debugger and I can monkey-patch it to accomplish the same thing as we have here. (https://github.com/johnjbarton/sirius)

However this solution requires 
   a) changes to devtools extensions because there is no way to inject the chrome.devtools API,
   b) synchronization of the extension copy of inspector/front_end with trunk (I do that myself but it would put a big barrier for others to do).
   c) adoption/learning of the extension by other devs

 Note that the extension solution is much less attractive after you realize:
  1) content-scripts can only act on https://, not chrome:// or chrome-extension://,
  2) devtools extensions need to be tested and devtools need be tested with extensions installed,
  3) devtools-extensions only function properly when loaded via normal devtools operation.

However, perhaps I don't understand what you have in mind?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.