Bug 97065 – Web Inspector: Source Mapping doesn't work when inspector is in remote-mode

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Peter Wang]

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.

[Peter Wang]

Created attachment 164651 [details]
Patch

[WebKit Review Bot]

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

[Vsevolod Vlasov]

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.

[Vsevolod Vlasov]

See https://bugs.webkit.org/show_bug.cgi?id=97032 also

[Peter Wang]

Created attachment 164691 [details]
Patch

[Vsevolod Vlasov]

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.

[Peter Wang]

(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.

[Pavel Feldman]

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.

[Peter Wang]

Reopening to attach new patch.

[Peter Wang]

Created attachment 164725 [details]
Patch

[Peter Wang]

(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.

[Pavel Feldman]

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.

[Peter Wang]

(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.

[Peter Wang]

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.