Report 2 problems related to Firefox extension development

Luca Greco lgreco at mozilla.com
Mon Nov 6 18:19:43 UTC 2017


On Mon, Nov 6, 2017 at 6:32 PM, Mike Lissner <mike at free.law> wrote:

> Am I understanding correctly that if one content script has, say, a syntax
> error, it just won't show up in the debugger, and it *also* won't throw
> an error except in the "browser console"?
>

Yes, Bug 1410932 is exactly about that: make the content script errors
visible in the tab developer toolbox.


> And if the script throwing the error is the first script in the manifest
> array, then the entire extension won't show up in the debugger?
>

Just the content scripts, all the other extension pages are not affected by
a loading error on a content script url.


> This explains a lot of frustration I've had if so. Things fail, and
> there's no error that I see telling me what happened. On top of this, I get
> random errors from jse files in my console that are just confusing and
> unrelated to me. Are we expected to be watching both the browser console,
> and the webcontext console at the same time? While we watch, are we
> expected to filter out the messages that are relevant to us, and ignore the
> rest somehow — that's annoying? Is the browser console available from Tools
> > Browser Console the same thing as the console you get in the debugger for
> the extension's background page? If it's different that makes three
> debuggers we have to watch.
>

The Addon Debugging workflow and tools still needs improvements, that is
true.

Once all the errors produced by the extension pages and the extension
content scripts are always associated to the related extension and window
global and logged in the expected developer toolbox (the tab developer
toolbox for all the content script errors and the addon debugging window
for all the other extension pages), the Browser Console should only be
necessary to check if an issue in the extension is related to a bug in the
WebExtensions internals.


> Two was already a lot, and this gets at another deep frustration I've had
> developing my webextension: I have to have two debuggers and consoles open
> and I need to watch them both. There's gotta be a better way to do this. It
> causes lots of trouble:
>
>  - I think a debugger paused. Which one? (this is compounded by the
> debugger not always being green when paused)
>

The extension code runs in different processes:

- the content scripts runs in the content processes (the ones where the
webpages are running)
- the extension pages runs in the extension child processes on the
platforms where it is enabled by default (currently only Windows), or in
the browser main process on the platforms where it is not enabled by
default (Linux, OSX, and also Firefox for Android that is currently running
in single process mode)

And so there will still be two debuggers that can be pauses in the two
different processes.


>  - I think I need to add a breakpoint in my code...which debugger should
> it go in?
>

Every extension pages from the same extension run in the same extension
child process (or the browser main process as described above) and the
breakpoints for them have to be set in the debugger panel from the Addon
Debugging window.

The only breakpoints that have to be set on a different debugger are the
ones on the content scripts files and the code executed using
tabs.executeScript
(
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/executeScript
which, as mentioned on MDN, executes the given code in the content script
context, in the child content processes).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/dev-addons/attachments/20171106/dfccba8b/attachment.html>


More information about the Dev-addons mailing list