This defect exists in both Chrome and other ports. The root reason is the function "InspectorFrontendHost.loadResourceSynchronously" (CompilerScriptMapping.js) is only a stub when Inspector is working in remote-mode.
Created attachment 164651 [details] Patch
Comment on attachment 164651 [details] Patch Attachment 164651 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13894394 New failing tests: http/tests/inspector/compiler-script-mapping.html
Comment on attachment 164651 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=164651&action=review > Source/WebCore/inspector/front-end/CompilerScriptMapping.js:95 > + sourceMap = this.loadSourceMapForScript(script); You should add return here for this patch to work. This means the script won't have source mapping until source map is loaded, which means stopping on breakpoint at this point would break things.
See https://bugs.webkit.org/show_bug.cgi?id=97032 also
Created attachment 164691 [details] Patch
Comment on attachment 164691 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=164691&action=review > Source/WebCore/inspector/front-end/DebuggerScriptMapping.js:57 > + if (!mapping._asyncLoadSource) I don't think this fixes the problem I mentioned. We should always have a mapping set for script which will correctly transfrom any raw location to ui location at any moment.
(In reply to comment #5) > Created an attachment (id=164691) [details] > Patch Sorry, I didn't notice comments#3 when I was uploading this patch. I'll update it according to your comments.
I don't think this is conceptually right to load source maps through the backend. You should treat the front-end as an IDE and the IDE should use its own capabilities to load resources from the web (not via the mobile device). I'd rather have an extension that does cross-origin requests.
Reopening to attach new patch.
Created attachment 164725 [details] Patch
(In reply to comment #10) > Created an attachment (id=164725) [details] > Patch This patch is updated for comments#3. I'll uploaded a new patch that also accommodate the comments#8.
Comment on attachment 164725 [details] Patch The way it should be addressed lays outside the WebCore/WebKit boundary. I would imagine it as an extension that exposes cross-origin XHRs or as CORS-enabled server serving the source maps. But it definitely should not be going via the backend / device.
(In reply to comment #12) > (From update of attachment 164725 [details]) > The way it should be addressed lays outside the WebCore/WebKit boundary. I would imagine it as an extension that exposes cross-origin XHRs or as CORS-enabled server serving the source maps. > But it definitely should not be going via the backend / device. Thx for the tips. I'll try it. My port really needs this feature to work.
The reason of this bug is obviously, but really hard to fix: if we can support CROSS-ORIGIN "InspectorFrontendHostStub.loadResourceSynchronously" in remote inspecting mode, we'll resolve it. As https://bugs.webkit.org/show_bug.cgi?id=91528 resolved, we can use "InspectorFrontendHostStub.loadResourceSynchronously" in remote-mode, but cannot do a cross-origin request. The patch for https://bugs.webkit.org/show_bug.cgi?id=73959 is trying to make that function cross-origin, but denied due to security concern. Maybe I should try to fix bug#73959 firstly.