Report 2 problems related to Firefox extension development

Mike Lissner mike at
Mon Nov 6 17:32:04 UTC 2017

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"?

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?

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.

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)
 - I think I need to add a breakpoint in my code...which debugger should it
go in?
 - I'm going to have my code log to the console...which console should I
watch for it? (We had a new dev spend an hour trying to figure out why a
console.log() wasn't logging anything. The answer? He needed a second
debugger open, something he could hardly imagine.
 - OK, I read that important email from the boss and now I need to get back
to work...I have three browser windows to choose from instead of two (①My
regular browser (research and whatnot), ② The browser for debugging the
context script with the webpage loaded in it, and ③ the debugger for the
background page). This is confusing and annoying and slows down development.

Some of this is probably my fault, not knowing the difference between a
browser console, a background page console, and a webcontext console, or
whatever. But...frankly...I'm convinced this sucks, and people need to be
guided to the right path of doing this, or we need a better way, so people
like me can't go wrong.

The backend for my extension logs how many requests it gets. I crossed
1,000 debugging requests over the weekend. That's an unbelievable number of
requests to make for a fairly simple extension. I'm not a JS guy, but I was
and am shocked at how much effort this is taking. 1,000 debug requests to
the backend for one extension. 1,000!


On Mon, Nov 6, 2017 at 8:43 AM Luca Greco <lgreco at> wrote:

> On Mon, Nov 6, 2017 at 12:48 PM, wei_huang at <
> wei_huang at> wrote:
>> Dear Mozilla support team
>> This is Wei Huang, a FF extension developer.
>> I’m writing this mail to ask for your help on 2 problems I encountered
>> recently.
>> *[Basic Information]*
>> Firefox Version:
>> (1).Firefox Release Edition  56.0.2 (32-bit)
>> (2).Firefox Dev Edition 57.0b14 (64-bit)
>> *[Problems Description]*
>> #1. I happened to find that 2 strange js files, which are not belong to
>> my extension, were injected with the content script jses of my extension. (Refer
>> to attached #1.png)
>> I’m wondering what are these jses used for? Are there any impact to my
>> extension?
> Every extension has its own content script sandbox, and so the content
> scripts that are not part of your extension
> are not injected in your extension content script sandbox, but there is
> definitely an issue to fix on the debugger UI side,
> which doesn't currently show the extension uuid in the left sidebar
> outline and so it is not currently clear enough which is the related
> extension
> (the extension uuid is only partially visible when hovering with the mouse
> the filename on the opened source tabs).
>> #2. Some content script files defined in manifest.json are not injected
>> into target web page.
>> As shown in #2_1.jpg & #2_2.jpg, when accessing Facebook setting page(
>>, all the jses that match
>> "*://**" should be injected.
>> However, most of these content script files are missing on this page.
>> One interesting thing is that, the #2 issue only happens on signed xpi.
>> When I extract the xpi, and load a temporary extension in debug mode, the
>> issue is improved.
>> I have no idea what’s going on with this issue.
> If the file is not listed in the debugger panel, there could be a loading
> error (which should be listed in the Browser Console, Bug 1410932 aims to
> make this kind of errors visible in the tab developer tools as well).
> If there is no loading error related to the extension, it could be worth
> to investigate if the extension content scripts have been loaded and
> they are just not listed in the Debugger UI, e.g. by temporarily adding a
> new content script url at the end of the content scripts js array
> which just produces a "console.log" message (because the content scripts
> are loaded in the same order of the js array in the content_scripts
> manifest property and,
> at least currently, if any of the script fails to load then all the
> subsequent scripts are not going to be loaded).
> _______________________________________________
> Dev-addons mailing list
> Dev-addons at
Mike Lissner
Executive Director
Free Law Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Dev-addons mailing list