When using executeScript() and submitting a file with a source map, the source map does not appear to be used in stacktraces. Because sourcemap-related errors are fairly silent I'm not confident I haven't done something wrong in generating a sourcemap, but my many attempts to tweak have not been successful. In Screenshots we have a series of bugs related to the raciness of executing multiple scripts in series (e.g., https://github.com/mozilla-services/screenshots/issues/3097), but lack of sourcemaps means that concatenating the files (which would solve these issues) would make our stacktraces difficult to interpret.

I think this is may be a more general issue of not reporting the location of the exception when running via executeScript. I have made a test extension with a choice of errors, and I get the following results on the external Developer Tools console (accessed with about:debugging "Load Temporary Add-On" and clicking "Debug"): 1. Error in main plugin .js: file name, line and column 2. Error in string directly executed by executeScript: ExtensionContent.jsm 3. Error in executeScript of a file: only file name 4. Error in code loaded with executeScript, run by way of a message from main plugin .js: undefined I tested with some sourcemaps from the Closure compiler, with these results: 5. Error in main plugin .js: original source file name, line and column are correct 6. Error in executeScript of a file: only (compiled) file name 7. Error in executeScript run via message: undefined I suspect the sourcemaps aren't even being acknowledged for the executeScript files, though, as a) I get an error if the main plugin js source map is inaccessible b) I don't get that error if the executeScript file is inaccessible. The same results are visible in the Browser Console except for 5, where the file, line and column are for the compiled script.

unzip and load the manifest.json with about:debugging, the popup menu has options for each error type discussed in comment 1. The source maps are hosted "permanently" on pastebin.mozilla.org as they didn't seem to load properly from the filesystem (perhaps I got the sourceMappingURL wrong?)

As briefly discussed with Adam, there are a number of underlying issue related to the source maps not used on the errors logged by the attached test extensions: The content scripts (as well as the code or extension urls executed using browser.tabs.executeScript) are running: - in the content process (the same process where the webpages are running when the browser has the e10s mode enabled) - in a Sandbox instance which has the related webpage window as its prototype The errors produced by a content scripts should be logged in the tab's webconsole, which is the same devtools toolbox where the content scripts sources are listed in the tab's debugger panel (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Debugging#Debugging_content_scripts), but they are currently associated to the wrong innerWindowID and so the tab's webconsole panel is currently ignoring them. Locally I've investigated and applied some changes to ensure that these errors appears in the tab's webconsole and I've verified that the source maps are correctly loaded and applied to the error's stack trace. The same errors are currently visible also: - from the Browser Console, this is expected (because this console is supposed to show every error that is logged in the browser, from the main process but also from the content processes), unfortunately (at least currently) the Browser Console doesn't seem to fetch and apply the source maps to the logged errors - from the Addon Debugging window's console, when connected to an extension that is not running in oop mode, is currently showing all the errors logged as a side-effect of: - being connected to the browser main process (like the Browser Console) - the errors not related to the extension pages are not currently filtered out (which is what I would like to introduce with Bug 1006102) but the content script errors are not supposed to be logged in this toolbox's webconsole and this toolbox can't list these source files in the debugger panel, because they have never been loaded in the main process (nor they will be loaded in the extension process) A separate issue is related to the source map support in the Addon Debugging window, which is currently not working because the Addon Debugging window runs in its own process and Firefox profile (like the Browser Toolbox)and so it is currently unable to fetch the source map urls from a "moz-extension:" url installed in the remote target. I'm going to break down this issue in the following smaller and more focused bugs on bugzilla: - Content Script errors and source maps: - "Content script errors synchronously raised while executing should be logged in the tab's webconsole" (with the draft patch that I've been experimenting locally attached to the issue) - "Content Script errors asynchronously raised from extension code should be logged in the tab’s webconsole" (with the draft patch that I've been experimenting locally attached to the issue) - "Filter out non-extension pages errors from the Addon Debugging Window" (Bug 1006102 has some draft patches related to this) - Extension Pages source maps: - "A DevTools toolbox connected to a remote target is unable to fetch Source Maps from a moz-extension URL" (which is not related to support the source maps for the "moz-extension:" urls related to the extension pages) (I've also took more notes about the issues described here, related to Addon errors and source maps, and I've organized them into the following google doc: https://docs.google.com/document/d/1lnrhOs4IHW9W6vxCG_96f553GAaudsLIKwuVJ3Wd5pY)

(In reply to Luca Greco [:rpl] from comment #4) > - from the Browser Console, this is expected (because this console is > supposed to show every error that is logged in the browser, from the main > process but also from the content processes), unfortunately (at least > currently) the Browser Console doesn't seem to fetch and apply the source > maps to the logged errors I believe the issue here is that the console needs the source actors in order to successfully source map. This is a bit hidden in the "source map URL service", which is https://dxr.mozilla.org/mozilla-central/source/devtools/client/framework/source-map-url-service.js The source actors are needed because they carry the sourceMappingURL information. I think the source actors for the content aren't available to the browser console. Maybe we could make this information available some other way; done properly it would also help things like sourceURL handling in <script> and <style> elements. However, it's tricky.

Are there any updates on this? (Picking on you, Adam, since you are assignee :)

Sorry for the delay, I don't have anything to report on this, maybe rpl has a better idea?

As described in more detail in comment 4, there are different underlying issues that are preventing the sourceMaps to work correctly for all the extension sources (based on which is the process where the source is working on and if the target of the toolbox used to debug the extension sources is local, e.g. the developer toolbox for a tab used to debug a content script, or remote, e.g. the toolbox from the "Addon Debugging window" which is running in a different process and Firefox profile connected over TCP to the Firefox instance where the extension is actually running). I investigated the ones specifically related to the "content scripts and tabs.executeScript", and then prepared and attached a set of patches on Bug 1410932 (which is also been added as a blocker of this issue). I've got a first round of feedback for that set of patches and applied some changes accordingly, but it is still blocked on the feedback request related to the last round of changes applied.