Web Inspector: implement Jsonp. We need a cross-domain communication channel in front-end for loading source mappings and source files from arbitrary locations. Jsonp seems to be the most suitable way to do it.
Created attachment 93784 [details] Patch.
Comment on attachment 93784 [details] Patch. View in context: https://bugs.webkit.org/attachment.cgi?id=93784&action=review > Source/WebCore/WebCore.vcproj/WebCore.vcproj:66884 > - RelativePath="..\inspector\front-end\UglifyJS\JavaScriptFormatter.js" > + RelativePath="..\inspector\front-end\Jsonp.js" it is not clear why this line was changed.
(In reply to comment #2) > (From update of attachment 93784 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=93784&action=review > > > Source/WebCore/WebCore.vcproj/WebCore.vcproj:66884 > > - RelativePath="..\inspector\front-end\UglifyJS\JavaScriptFormatter.js" > > + RelativePath="..\inspector\front-end\Jsonp.js" > > it is not clear why this line was changed. front-end/UglifyJS/JavaScriptFormatter.js was moved to front-end/JavaScriptFormatter.js long time ago. It's just a drive-by fix of vcproj file.
Comment on attachment 93784 [details] Patch. View in context: https://bugs.webkit.org/attachment.cgi?id=93784&action=review > Source/WebCore/inspector/front-end/Jsonp.js:31 > +WebInspector.Jsonp = function() We use upper case for abbreviations (WebInspector.JSONP). Also, it is not clear how this class is going to be used.
Created attachment 107041 [details] Patch
(In reply to comment #4) > (From update of attachment 93784 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=93784&action=review > > > Source/WebCore/inspector/front-end/Jsonp.js:31 > > +WebInspector.Jsonp = function() > > We use upper case for abbreviations (WebInspector.JSONP). Also, it is not clear how this class is going to be used. JSONP.loadData loads json data from arbitrary location. This will be used for loading source mappings and source code from inspector page.
Created attachment 107044 [details] Patch
Comment on attachment 107044 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=107044&action=review > Source/WebCore/inspector/front-end/JSONP.js:40 > + var requestId = Math.random(); Is there a general consensus that it should be implemented using jsonp? JSONp calls will compromise inspector front-end. Can we isolate them?
(In reply to comment #8) > (From update of attachment 107044 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=107044&action=review > > > Source/WebCore/inspector/front-end/JSONP.js:40 > > + var requestId = Math.random(); > > Is there a general consensus that it should be implemented using jsonp? I think JSONP is the easiest and safest way to implement this. We discussed that a while ago, and decided to use JSONP. > JSONp calls will compromise inspector front-end. Can we isolate them? I believe it is isolated, could you please provide an example of how inspector could be compromised?
Comment on attachment 107044 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=107044&action=review >>> Source/WebCore/inspector/front-end/JSONP.js:40 >>> + var requestId = Math.random(); >> >> Is there a general consensus that it should be implemented using jsonp? JSONp calls will compromise inspector front-end. Can we isolate them? > > I think JSONP is the easiest and safest way to implement this. We discussed that a while ago, and decided to use JSONP. Is there a general consensus that it should be implemented using jsonp? JSONp calls will compromise inspector front-end. Can we isolate them?
(In reply to comment #10) > Is there a general consensus that it should be implemented using jsonp? JSONp calls will compromise inspector front-end. Can we isolate them? I'm not terribly happy with a JSONP story. I guess I'd like to see how this is to be used, in the context of source files/maps. I don't suppose there's any way we can make use of the File APIs? Since they seem to gateway through user action (drag/drop, form prompter), would require user action at least once every time the user debugged, to get the files read. Don't think we'd want to just cache them - we don't have a way to validate them later without a prompter. So doesn't seem like File will work, but thought I'd mention it. May not be a great idea to assume the source/map files are on a local disk anyway :-) Have we considered asking the back-end to provide the source files/maps? If this is all on the front-end, then I guess the assumption is that you're running a local HTTP server, and for the current 9/12 patch, one that supports sending content as JSOP if it's passed "callback=parseResponse" in the query string. Ick. If that local source file/map HTTP server has CORS support, then JSONP wouldn't be needed at all - you can XHR the source. This seems like it would be workable if you're using some kind of hosted IDE as well. Perhaps the source map folks can provide a complete scenario of how this data would be accessed by a debugger implemented in a browser. Or have they already thought this all the way through?
(In reply to comment #11) > (In reply to comment #10) > > Is there a general consensus that it should be implemented using jsonp? JSONp calls will compromise inspector front-end. Can we isolate them? > > I'm not terribly happy with a JSONP story. I guess I'd like to see how this is to be used, in the context of source files/maps. > > I don't suppose there's any way we can make use of the File APIs? Since they seem to gateway through user action (drag/drop, form prompter), would require user action at least once every time the user debugged, to get the files read. Don't think we'd want to just cache them - we don't have a way to validate them later without a prompter. > > So doesn't seem like File will work, but thought I'd mention it. May not be a great idea to assume the source/map files are on a local disk anyway :-) > > Have we considered asking the back-end to provide the source files/maps? It will require implementing XHR-like interface in protocol, and then sending requests from either native code (scary) or inspected page context (subject to SOP, consider production server + local mappings). JSONP looks like a light weight and easy to implement alternative. And we may always return to back-end solution if needed. > > If this is all on the front-end, then I guess the assumption is that you're running a local HTTP server, and for the current 9/12 patch, one that supports sending content as JSOP if it's passed "callback=parseResponse" in the query string. Ick. > If you have map+sources locally, chances are you need a local HTTP server anyway as we don't want to allow access to local files (or ask user to allow it). JSONP implementation in Python is just three lines of code atop of a simple HTTP server. > If that local source file/map HTTP server has CORS support, then JSONP wouldn't be needed at all - you can XHR the source. This seems like it would be workable if you're using some kind of hosted IDE as well. > > Perhaps the source map folks can provide a complete scenario of how this data would be accessed by a debugger implemented in a browser. Or have they already thought this all the way through? CORS wouldn't allow us to load maps from front-end page.
(In reply to comment #12) > > Have we considered asking the back-end to provide the source files/maps? > > It will require implementing XHR-like interface in protocol, and then sending requests from either native code (scary) or inspected page context (subject to SOP, consider production server + local mappings). JSONP looks like a light weight and easy to implement alternative. And we may always return to back-end solution if needed. Yes, would require a multi-state exchange to get the source files/maps from the backend. Especially if you wanted to do something like cache the source files/maps in the front-end (which you probably do). How can sending a request from native code be scary? Well, I know how it can be scary, but really, this shouldn't be a huge burden on the back end, should it? That's one of it's main purposes in life (the browser engine, that is). > > If this is all on the front-end, then I guess the assumption is that you're running a local HTTP server, and for the current 9/12 patch, one that supports sending content as JSOP if it's passed "callback=parseResponse" in the query string. Ick. > > > If you have map+sources locally, chances are you need a local HTTP server anyway as we don't want to allow access to local files (or ask user to allow it). JSONP implementation in Python is just three lines of code atop of a simple HTTP server. My experience is, from weinre, that making the casual "run a server" is really too much to ask. Having a server-free story is the best answer. But perhaps unavoidable, for now. > > If that local source file/map HTTP server has CORS support, then JSONP wouldn't be needed at all - you can XHR the source. This seems like it would be workable if you're using some kind of hosted IDE as well. > > > CORS wouldn't allow us to load maps from front-end page. I'm confused. Why wouldn't CORS let you do this? Somehow the back-end sends the front-end the source file and source map URLs, the front-end XHR's these, the server those URLs point to serves the resources with appropriate CORS headers, front-end gets the resource data. What am I missing?
> > > If that local source file/map HTTP server has CORS support, then JSONP wouldn't be needed at all - you can XHR the source. This seems like it would be workable if you're using some kind of hosted IDE as well. > > > > > CORS wouldn't allow us to load maps from front-end page. > > I'm confused. Why wouldn't CORS let you do this? Somehow the back-end sends the front-end the source file and source map URLs, the front-end XHR's these, the server those URLs point to serves the resources with appropriate CORS headers, front-end gets the resource data. What am I missing? I don't think front-end would be able to send XHR. Front-end page has unique security origin so webcore will just block any request from it.
For Eclipse Orion (web-based dev tools) we looked at JSONP as a mechanism to let us do general cross-domain communication but ultimately decided against using it because of concerns that a malicious JSONP payload compromises the client (e.g. parent.alert("You're toast");parseResponse(...)). Instead to support cross-domain communication what we're doing is putting a special HTML file on the "other" server and loading this file in an invisible IFrame. Things are then setup so we can have a data-only conversation between the IFrame and Client using window.postMessage. Because the IFrame document is on the "other" domain it can can XHR its host without running into SOP issues. Another added benefit is you can do this without server-side python, java, etc. -- a basic HTTP Server will do. The same approach works for a webworker if you want to host a JS file instead of an HTML file. The approach is not terribly complex and you could certainly code up your own implementation. Orion has a BSD licensed version if you want to take a look also. If you're at all interested here let me know as we'd help. We're looking at building a debug front-end for Orion and this is the sort of interface we need.
(In reply to comment #15) > For Eclipse Orion (web-based dev tools) we looked at JSONP as a mechanism to let us do general cross-domain communication but ultimately decided against using it because of concerns that a malicious JSONP payload compromises the client (e.g. parent.alert("You're toast");parseResponse(...)). We load JSONP scripts to a separate iframe which don't have access to inspector page, so I believe we are perfectly safe here. > > Instead to support cross-domain communication what we're doing is putting a special HTML file on the "other" server and loading this file in an invisible IFrame. Things are then setup so we can have a data-only conversation between the IFrame and Client using window.postMessage. Because the IFrame document is on the "other" domain it can can XHR its host without running into SOP issues. Another added benefit is you can do this without server-side python, java, etc. -- a basic HTTP Server will do. The same approach works for a webworker if you want to host a JS file instead of an HTML file. > > The approach is not terribly complex and you could certainly code up your own implementation. Orion has a BSD licensed version if you want to take a look also. > > If you're at all interested here let me know as we'd help. We're looking at building a debug front-end for Orion and this is the sort of interface we need. You may generate JSONP files instead of JSON and serve them from basic HTTP server as well. So as I see it, we have two alternatives: 1) Source map provider serves tiny HTML document that can be embedded as invisible iframe to inspector page. This HTML document implements simple protocol for retrieving source map file and source code from source map server by means of postMessage. 2) Source map provider serves JSONP scripts with source map and source files. Inspector embeds invisible iframe and retrieves the data by means of postMessage. There is no huge difference, but the first approach is maybe somewhat cleaner since there is no need to touch source map files.
Injected iframe solution is preferable from source map provider point of view. See https://bugs.webkit.org/show_bug.cgi?id=69423.