Argthtjtr

I'm seeing a lot of messages like this in my Firebug console on various sites, including one I'm trying to debug. breakOnError.js appears to be some system/Firebug file, nothing to do with any of the sites this appears for. There's nothing obvious I can see that the number 674 here might relate to, though it seems to show for multiple pages (including this very question page):

DebuggeeWouldRun: debuggee `self-hosted:674` would run        breakOnError.js (line 105, col 13)`

                                                                       <system>

Firebug's console just fills up with them if I have Break on Exceptions enabled in the Script window, sometimes even if I turn it on after the page has already loaded, at a rate of slightly more than one a second. It's yellow, like a warning message (it's not an error), but I don't know what it could be warning me about.

I can't find any intelligible information on what this is or what it means. All that comes up that is even nearly relevant is a couple of Firefox/Mozilla support issues (1249469 and 1252945 ) discussing some very fine details of the implementation of... whatever this is. No clues I can understand about what any of this actually means.

What it this and what does it mean?

I've found what looks like a possible explanation from someone I believe is a Mozilla developer, but it's very technical (intended audience = other firefox developers) and I don't really understand what it actually means. I think maybe this means that Firefox is complaining because it doesn't like the way Firebug is trying to take over break handling, and Firebug is responding to these system messages as console warnings then just keeps on doing what it was doing?

I recently landed an implementation of Debugger.DebuggeeWouldRun, which is
an
error that's thrown when debugger code attempts to re-enter debuggee code
without going through a blessed "invocation function" (currently D.F.p.eval
and D.O.p.executeInGlobal) 1. These re-entries are the cause of the
debugger
not truly able to pause the debuggee.

Currently it is not an error but a warning instead, and is to help
pinpoint sites in debugger code that attempts to re-enter debuggee code. The
intention is that once all sites are fixed, it will be an error.

...then there's this comment, which makes me think this is maybe some symptom of a Firefox quirk I don't need to worry about, but again I don't really understand what it means, particularly what it means by "self-hosted code" in this context (would an extension like Firebug count as self-hosted because it's on my machine?), and I've got no idea what "the debugee compartment" is:

One current shortcoming is that all self-hosted code in the debuggee
compartment is banned. This means some operations that should in fact be
allowed are warned against/disallowed.

Ramhound in comments suggested it might be a Firebug bug (ugghhh), and asked about the line of code referred to in the message.

Obviously if there is a bug, that's a matter for the Firebug devs, this isn't the place to try to fix it. I'm posting in case it helps anyone explain what the content of the message ('debugee', 'self-hosted:674', 'would run') actually means. This is the function around the line, I've marked line 105 with a comment:

onDebuggerPaused: function(context, event, packet)

{

    // Check the packet type, only "exception" is interesting in this case.

    var type = packet.why.type;

    if (type != "exception")

        return;



    // Reset the break-on-next-error flag after an exception break happens.

    // xxxHonza: this is how the other BON implementations work, but we could reconsider it.

    // Another problem is that the debugger breaks in every frame by default, which

    // is avoided by reseting of the flag.

    this.breakOnNext(context, false);



    // At this point, the BON flag is reset and can't be used anymore in |shouldResumeDebugger|.

    // So add a custom flag in packet.why so we know that the debugger is paused because of

    // either the Console's "Break On Next" or the Script's "Break On Exceptions" option.

    packet.why.fbPauseDueToBONError = true;



    // Get the exception object.

    var exc = DebuggerLib.getObject(context, packet.why.exception.actor);

    if (!exc)

        return;



    Trace.sysout("BreakOnError.onDebuggerPaused;", {exc: exc, packet: packet});



    // Convert to known structure, so FirebugReps.ErrorMessage.copyError() works.

    var error = {

        message: exc + "", // <<<<<<<<<<<<<<<<<<<<<<<<<<<< THIS IS LINE 105 <<<<<<<<<<<<<<<<

        href: exc.fileName,

        lineNo: exc.lineNumber

    };



    var lineNo = exc.lineNumber - 1;

    var url = exc.fileName;



    // Make sure the break notification popup appears.

    context.breakingCause =

    {

        message: error.message,

        copyAction: Obj.bindFixed(ErrorMessage.copyError, ErrorMessage, error),

        skipAction: function addSkipperAndGo()

        {

            // Create a breakpoint that never hits, but prevents BON for the error.

            var bp = BreakpointStore.addBreakpoint(url, lineNo);

            BreakpointStore.disableBreakpoint(url, lineNo);



            Debugger.resume(context);

        },

    };

},

The "debuggee" is the thing that is debugged. In case of Firefox that is JavaScript code run through the debugger, more specifically the website's JavaScript code. (It could also be browser-internal JavaScript code.)

The Firefox Debugger API is described on MDN, though it's also very technical and does not explain the terminology. There's also some description of the Debugger.DebuggeeWouldRun Exception, which clarifies things a bit if you keep the definition from above in mind:

Some debugger operations that appear to simply inspect the debuggee’s state may actually cause debuggee code to run. For example, reading a variable might run a getter function on the global or on a with expression’s operand; and getting an object’s property descriptor will run a handler trap if the object is a proxy. To protect the debugger’s integrity, only methods whose stated purpose is to run debuggee code can do so. These methods are called invocation functions, and they follow certain common conventions to report the debuggee’s behavior safely. For other methods, if their normal operation would cause debuggee code to run, they throw an instance of the Debugger.DebuggeeWouldRun exception.

So, applying this to Firebug, it means Firebug's debugger code does not only inspect a page's code but may actually (accidentally) execute the page's code.
Simple example:

<script>

var obj = {

  i: 0,  

  get counter() {

    return this.i++;

  }

}

</script>

This increases the i everytime obj.counter getter is called.
If you inspect the obj variable within Firebug's Watch side panel, for example, you'll see that the counter get's increased just because it's accessed by Firebug:

Having said that, I don't see the exceptions mentioned by you even when the preferences javascript.options.throw_on_debuggee_would_run and javascript.options.dump_stack_on_debuggee_would_run, as mentioned in the Mozilla discussion group thread, are set to true (which are set to false by default).

And I suggest you set those two preferences to false if you don't want to see those exceptions being logged to the console.