| Summary: | Web Inspector: clicking in console on user script error fails to jump to resource | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Antoine Quint <graouts> | ||||
| Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | graouts, inspector-bugzilla-changes, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
Arg. This is unfortunate. We could probably fix this in the front-end, but a clean fix would be to have JavaScriptCore understand sourceURL per-Script. |
Created attachment 234503 [details] screenshot of prompt to search App Store I have a Cocoa app on Yosemite (14A283o) using the Modern WebKit API (WKWebView) to inject user scripts with the WKUserContentController.addUserScript() method. In the injected script source, I use a `//# sourceURL=foo.js` comment to customise the name of the resource in the Resource sidebar, which works fine. However, when I inspect my WKWebView using Safari 8's OS X remote inspection feature, I can see errors in this user script, but the URL for the error is "user-script:1:90" instead of using the name "foo.js" and clicking on the error shows a dialog saying "There is no application set to open the URL user-script:1." offering to search the App Store for a compatible app.