Last Comment Bug 643360 - Firebug DOM panel leads to Firefox crash
: Firebug DOM panel leads to Firefox crash
Status: RESOLVED WORKSFORME
[firebug-p3]
: crash
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- critical with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: jsd
: Jason Orendorff [:jorendorff]
Mentors:
http://githubissues.heroku.com/#280no...
Depends on: 682793
Blocks: 647636
  Show dependency treegraph
 
Reported: 2011-03-20 21:26 PDT by Steve Roussey (:sroussey)
Modified: 2015-01-22 00:15 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
stack from bp-82060978-2f55-4cb1-929a-529272110320 (177.59 KB, text/plain)
2011-03-21 05:19 PDT, Ted Mielczarek [:ted.mielczarek]
no flags Details
s/jdsc/jsdc/g (2.26 KB, patch)
2011-03-21 14:35 PDT, timeless
no flags Details | Diff | Splinter Review
untested proposal (2.34 KB, patch)
2011-03-31 17:19 PDT, timeless
sphink: review+
Details | Diff | Splinter Review

Description Steve Roussey (:sroussey) 2011-03-20 21:26:48 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

Using Firefox 4 and Firebug 1.7, Firebug issue at:
http://code.google.com/p/fbug/issues/detail?id=4245

Reproducible: Always

Steps to Reproduce:
1. Go here: http://githubissues.heroku.com/#280north/cappuccino
2. Wait for it to load.
3. Open Firebug.
4. Open the DOM panel/tab
Actual Results:  
Long pause then crash.

Expected Results:  
No crash
Comment 1 Steve Roussey (:sroussey) 2011-03-20 21:29:12 PDT
Boris, CC-ing you as it is related to Firebug, and I don't know who else to CC.

https://crash-stats.mozilla.com/report/index/bp-82060978-2f55-4cb1-929a-529272110320
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-03-20 21:43:49 PDT
Steps in comment 0 don't crash for me, but I have no idea whether I'm using the same "Firebug 1.7" as you are (I think I got 1.7b3 off getfirebug.com).

The incident report claims stack overflow, but doesn't have any obviously long stacks...

Steve, I assume you see this in a clean profile in which you've done nothing other than install Firebug?
Comment 3 John J. Barton 2011-03-20 22:06:22 PDT
See also from Steve:
https://crash-stats.mozilla.com/report/index/bp-d4483a31-0993-45ad-8a67-84a712110320

When I try the case I don't crash but I do get "too much recursion" and some funky jsd hook error
Success arg 0 [jsdIStackFrame.script]"
The oldest frame is:
jsds_ErrorHookProc
so I guess the long stack is somehow on the other side of jsd. (But it is a long JS stack, not a long C++ one, so maybe this has nothing to do with it.).

Steve, we'll need you to figure out what is different in your environment.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-03-20 22:10:23 PDT
John, were you testing on Windows?  Note that I was testing on Mac.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-03-20 22:12:55 PDT
And note that I don't get John's exception either....
Comment 6 Steve Roussey (:sroussey) 2011-03-20 22:13:42 PDT
Clean? Cough. Cough. Well, I did try with other extensions disabled.

So... clean profile. First try didn't crash. I enabled the script panel and hit reload. After it loaded, I went to the DOM panel. Then it crashed. Perhaps JSD had to be enabled?

https://crash-stats.mozilla.com/report/index/bp-b12bbdca-5274-497b-999d-556b12110320

Now I had one like that before (see the Firebug issue for a longer list of crash reports), but most were different. This is being repeatable, but with sprintf instead of the security one. Another:

https://crash-stats.mozilla.com/report/index/bp-52668ff8-eccf-4616-bc99-2f67d2110320
Comment 7 Steve Roussey (:sroussey) 2011-03-20 22:24:34 PDT
Well Clean as in Brand New. Seems like Java and FiddlerHook reinstalled themselves. I disabled them and all is the same:

https://crash-stats.mozilla.com/report/index/bp-0f5d0119-b9ff-428e-b8f1-e39962110320

Now enabling Console as well:

https://crash-stats.mozilla.com/report/index/bp-91984d92-5e13-4871-8f61-d49662110320

That made it look different. Now with Net enabled also (and reload):

https://crash-stats.mozilla.com/report/index/d38d3f85-c8e5-4188-ae49-fb6e72110320

Same as the previous.
Comment 8 Steve Roussey (:sroussey) 2011-03-20 22:37:59 PDT
BTW: Be sure that there are actually issues loaded in the view on the web page. Often the fist time in a new profile it fails. Just reload.

So another new profile this time using the xpi instead of the "file link" method.

Again, no crash first time with all panels disabled. Then enabled Script panel, reloaded, and after the page is finished loading, I switch to DOM panel. Crashed again.

Again in dosprintf:

https://crash-stats.mozilla.com/report/index/bp-e5c3d02a-b0f0-46ee-8b39-2c8582110320

I enable the console (and script) panels and I get this crash:

https://crash-stats.mozilla.com/report/index/bp-8b04d72f-9af5-4ea2-a203-13d352110320
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-03-20 22:43:33 PDT
Ah, that Script panel part is key.

Now I get these errors in the console:

  FTS0: Error in hook: InternalError: too much recursion  
   obj: InternalError: too much recursion

The stack looks somewhat like this: 

#914 0x044ca2f2 in js_TryMethod (cx=0x60b4010, obj=0x2c56c3f0, atom=0x67009c0, argc=0, argv=0x0, rval=0xbffe9920) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsobj.cpp:6355
#915 0x044ca474 in js::DefaultValue (cx=0x60b4010, obj=0x2c56c3f0, hint=JSTYPE_STRING, vp=0xbffe9960) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsobj.cpp:5972
#916 0x0454c7f0 in js_ValueToString (cx=0x60b4010, arg=@0x17800b28) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsstr.cpp:3677
#917 0x04550dbb in js_String (cx=0x60b4010, argc=1, vp=0x17800b18) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsstr.cpp:3301
#918 0x044a4c0a in js::CallJSNative (cx=0x60b4010, native=0x4550d8d <js_String(JSContext*, unsigned int, js::Value*)>, argc=1, vp=0x17800b18) at jscntxtinlines.h:701
#919 0x04493fe3 in js::Interpret () at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsinterp.cpp:4799
#920 0x044a8a72 in js::RunScript (cx=0x60b4010, script=0x1f917790, fp=0x17800ae8) at jsinterp.cpp:653
#921 0x044a91e7 in js::Invoke (cx=0x60b4010, argsRef=@0xbffea910, flags=0) at jsinterp.cpp:740
#922 0x044a9abd in js::ExternalInvoke (cx=0x60b4010, thisv=@0xbffea970, fval=@0xbffea978, argc=0, argv=0x0, rval=0xbffea9d0) at jsinterp.cpp:863
#923 0x044ca2f2 in js_TryMethod (cx=0x60b4010, obj=0x2c56c3f0, atom=0x67009c0, argc=0, argv=0x0, rval=0xbffea9d0) at /Users/bzbarsky/mozilla/vanilla/mozilla/js/src/jsobj.cpp:6355

etc.  The js_TryMethod is being passed "toString" as the method, of course.

In js::ExternalInvoke the fval is the same Function object all the time.  Its script claims to be line 3316 of http://githubissues.heroku.com/Frameworks/Objective-J/Objective-J.js which seems slightly dubious.  There _are_ a bunch of toString definitions in that file; just not on or near that line...

cx->fp()->script() also claims to be the same thing when we hit the over-recursion exception.

In any case, the entry point in JS to this long rsecursive stack is this code in safeToString in firebug's lib.js:

        if (ob && (typeof (ob['toString']) == "function") )
            return ob.toString();

At a guess, there's a buggy toString function on the page somewhere that just calls itself, and all that's happening is that for some reason our recursion protection on Windows is not catching this (due to bigger stack frames because of pgo or something?)
Comment 10 Andreas Gal :gal 2011-03-20 22:50:42 PDT
js_TryMethod has a recursion check for sure. That not hitting is worrisome.
Comment 11 Steve Roussey (:sroussey) 2011-03-20 22:52:19 PDT
Can you try getting the stack also with the Console panel enabled?

I'm at a loss as to why having the Script panel disabled somehow avoids the too much recursion problem.

Now that you mention it, I haven't seen the recursion protection prompt (I'm on Windows7) in a while...
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-03-20 22:58:40 PDT
> I'm at a loss as to why having the Script panel disabled somehow avoids the too
> much recursion problem.

Presumably because safeToString is never hit then?

There is no recursion protection prompt.  There's just an exception that gets thrown on too much recursion.
Comment 13 Steve Roussey (:sroussey) 2011-03-20 23:47:10 PDT
> Presumably because safeToString is never hit then?

No dice.

I turned Firebug's tracing on and see that it gets the errors there (see below) without Chromebug installed (it will always turn on JSD). So I guess that when the recursion error hits, *and* JSD is on, then problems mount and crash Firefox. So it doesn't avoid the recursion error, it just gets handled wrong with JSD enabled. So I don't see too many people hitting this crash of JSD preventing recursion checking.


FBTRACE (DBG_ERRORS on):

1
		
safeToString FAILS InternalError: too much recursion
2
		
safeToString FAILS InternalError: too much recursion
3
		
safeToString FAILS InternalError: too much recursion
4
		
safeToString FAILS InternalError: too much recursion
StackExceptionPropertiesObject
message
	"too much recursion"
stack
	"()@http://githubissues....bjective-J.js:3320\n@:0\n"
fileName
	"http://githubissues.her...ective-J/Objective-J.js"
lineNumber
	3320
name
	"InternalError"
isa
	CPException { isa=CPObject, version=0, more...}
isa
	CPObject { isa=CPObject, version=0, more...}
version
	0
super_class
	CPObject { isa=CPObject, version=0, more...}
sub_classes
	[]
name
	"CPException"
info
	1
ivar_list
	[Object { name="_userInfo"}]
ivar_store
	function()
ivar_dtable
	Object { _userInfo={...}}
method_list
	[Object { name="initWithName:reason:userInfo:"}, Object { name="name"}, Object { name="reason"}, 7 more...]
method_store
	function()
method_dtable
	Object { initWithName:reason:userInfo:={...}, name={...}, more...}
allocator
	function()
_UID
	2414
toString
	function()
_userInfo
	null
Comment 14 Steve Roussey (:sroussey) 2011-03-20 23:49:16 PDT
Umm... and bugzilla needs a way to edit a comment. What kind of English was that? I'm exhausted, and going to sleep now...
Comment 15 Ted Mielczarek [:ted.mielczarek] 2011-03-21 05:19:53 PDT
Created attachment 520619 [details]
stack from bp-82060978-2f55-4cb1-929a-529272110320

(In reply to comment #1)
> Boris, CC-ing you as it is related to Firebug, and I don't know who else to CC.
> 
> https://crash-stats.mozilla.com/report/index/bp-82060978-2f55-4cb1-929a-529272110320

Loading this in VC++ gives a slightly longer stack, see attached.
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2011-03-21 05:30:19 PDT
That's much more interesting.  It shows recursion like this:

 	xul.dll!jsd_DebugErrorHook(JSContext * cx=0x03e41140, const char * message=0x2324f220, JSErrorReport * report=0x00145028, void * closure=0x00642390)  Line 400 + 0x11 bytes	C
 	mozjs.dll!ReportError(JSContext * cx=0x03e41140, const char * message=0x2324f220, JSErrorReport * reportp=0x00145028, const JSErrorFormatString * (void *, const char *, const unsigned int)* callback=0x5b1cd9a0, void * userRef=0x00000000)  Line 1293 + 0x9 bytes	C++
 	mozjs.dll!js_ReportErrorNumberVA(JSContext * cx=0x03e41140, unsigned int flags=0, const JSErrorFormatString * (void *, const char *, const unsigned int)* callback=0x5b1cd9a0, void * userRef=0x00000000, const unsigned int errorNumber=26, int charArgs=1, char * ap=0x00145090)  Line 1639 + 0x15 bytes	C++
 	mozjs.dll!JS_ReportErrorNumber(JSContext * cx=0x03e41140, const JSErrorFormatString * (void *, const char *, const unsigned int)* errorCallback=0x5b1cd9a0, void * userRef=0x00000000, const unsigned int errorNumber=26, ...)  Line 5779 + 0x1d bytes	C++
 	mozjs.dll!JSCompartment::wrap(JSContext * cx=0x03e41140, js::Value * vp=0x001450c8)  Line 194 + 0x29 bytes	C++
 	mozjs.dll!JSContext::wrapPendingException()  Line 2039 + 0x23 bytes	C++
 	mozjs.dll!js::AutoCompartment::enter()  Line 394	C++
 	mozjs.dll!JS_GetFrameThis(JSContext * cx=0x03e41140, JSStackFrame * fp=0x048e0650, unsigned __int64 * thisv=0x0014518c)  Line 1434 + 0x5e bytes	C++
 	xul.dll!jsd_NewThreadState(JSDContext * jsdc=0x00642390, JSContext * cx=0x03e41140)  Line 138 + 0xe bytes	C
 	xul.dll!jsd_CallExecutionHook(JSDContext * jsdc=0x00642390, JSContext * cx=0x03e41140, unsigned int type=1, unsigned int (JSDContext *, JSDThreadState *, unsigned int, void *, unsigned __int64 *)* hook=0x5830b8ad, void * hookData=0x00000000, unsigned __int64 * rval=0x001451f0)  Line 165 + 0x1a bytes	C
 	xul.dll!jsd_DebugErrorHook(JSContext * cx=0x03e41140, const char * message=0x2322f180, JSErrorReport * report=0x00145258, void * closure=0x00642390)  Line 400 + 0x11 bytes	C
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2011-03-21 05:34:32 PDT
And that's showing that we end up throwing a "too much recursion" exception inside wrap() while trying to report just such an exception to jsd, and recurse infinitely...

The odd part is that I don't see that happen on Mac.  The exception _is_ thrown from wrap(), but that does NOT reenter jsd code.  I have no idea why.

jsd does have recursion protection, but it's at a higher level than the above; it's activated right before calling into the user-level hook, but we never get that far here.
Comment 18 Steve Roussey (:sroussey) 2011-03-21 10:19:20 PDT
OK, anything else you need from me to help?
Comment 19 timeless 2011-03-21 14:35:01 PDT
Created attachment 520755 [details] [diff] [review]
s/jdsc/jsdc/g

so, this would probably be rather unfortunate, and i haven't fed it to a compiler, but at least in theory it could do something useful.
Comment 20 timeless 2011-03-31 17:19:48 PDT
Created attachment 523469 [details] [diff] [review]
untested proposal

i think this compiles.. if someone could test it and confirm it does what they need, that'd be great.
Comment 21 Steve Fink [:sfink] [:s:] 2011-04-01 17:33:17 PDT
Argh. When I first tried this, I could reproduce the crash. Then I foolishly updated my tree before applying the patch, and instead just get the "too much recursion" error messages. A printout added to the isBusy case doesn't trigger.

I think I may be able to recover which version I had before. I'll try that next.
Comment 22 John J. Barton 2011-04-04 09:20:44 PDT
See also Bug 647636, another stack over flow involving error handler.
Comment 23 timeless 2011-04-04 14:15:57 PDT
john: spin up a try server build and see if the patch fixes your crashes.
Comment 24 John J. Barton 2011-04-05 22:13:03 PDT
Unfortunately I am not able to help on this at this time.
Comment 25 Steve Fink [:sfink] [:s:] 2011-04-06 12:45:27 PDT
Sorry for the delay, but I will probably continue to be slow for the next week.

The thing that bothers me about this patch is that I feel like it's blaming the victim. The JSD code here is a legitimate user of JSAPI, even if it's a strictly debugging-related portion of it. If the JS engine is in a state where calling additional JS code is going to fail because the stack is exhausted, then why is it ok for it to invoke a callback that is likely to do exactly that?

Which is not to say that this patch is a bad idea. Being defensive is good. But I feel there's an additional bug within the JS engine that would be more important to fix, and a fix could conceivably be general enough to work for additional users.

To be specific, I will r+ this patch once I convince myself it solves the problem in question, but I've also opened bug 648088.
Comment 26 timeless 2011-04-06 13:24:59 PDT
Please note that I'm not claiming that I like this approach. I'm incredibly uneasy about it. But I'd like to know if it happens to cause the crash to not happen.

Even with a module hat on, I'm not sure I'd want to commit this knowing it works....
Comment 27 Steve Roussey (:sroussey) 2011-04-06 20:04:35 PDT
If someone points me to a download link I can try it...
Comment 28 Steve Fink [:sfink] [:s:] 2011-04-07 16:09:36 PDT
You can get builds at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/sfink@mozilla.com-80c00c19970c
Comment 29 David Mandelin [:dmandelin] 2011-04-26 16:07:51 PDT
What's the status here? What needs to happen next?
Comment 30 Steve Roussey (:sroussey) 2011-04-26 17:21:32 PDT
Sorry, I need a new download link to try.
Comment 31 timeless 2011-04-26 21:11:21 PDT
dmandelin:
1. someone needs to own the bug (this could be you)
2. someone needs to decide that the patch works (this could be sroussey)
3. to decide that the patch works, someone probably needs to provide a try build (this could be you, and would help with 2)
4. someone needs to review the patch (this might be sfink or it could be someone else)
5. someone needs to push a fix

more or less.
Comment 32 David Mandelin [:dmandelin] 2011-04-27 09:27:12 PDT
(In reply to comment #31)
> dmandelin:
> 1. someone needs to own the bug (this could be you)
> 2. someone needs to decide that the patch works (this could be sroussey)
> 3. to decide that the patch works, someone probably needs to provide a try
> build (this could be you, and would help with 2)
> 4. someone needs to review the patch (this might be sfink or it could be
> someone else)
> 5. someone needs to push a fix
> 
> more or less.

Thanks. I'm going to be out for a few days, so I won't squat on it in the meantime, but if it's still here when I get back, I can take it then.
Comment 33 Steve Fink [:sfink] [:s:] 2011-04-27 16:47:40 PDT
I've been trying to write a testcase for this, but it's a tricky one to reproduce.

First, you need a mixed-compartment stack (otherwise the wrap() during JS_GetFrameThis is a no-op), so you can't reproduce with straight HTML/JS.

Next, most of the easier ways of setting this up involve using debugger callbacks that Pause() debugging while they're running, so the infinite recursion can't happen.

Now I am trying to make onError return false so that the debugHook will be invoked, but the onError callback uses the stack for argument marshalling and so it hits the recursion limit itself and returns a nonzero value, preventing debugHook from running. (jsd.debugHook aka jsdc->debugBreakHook is what constructs a stack trace, which is where JS_GetFrameThis gets called. onError does not, so it won't trigger a "too much recursion" exception and even if it did, it Pause()s debugging.)

I'm not sure what's different about my test case and the real problem. Maybe the C++ stack frames pushed for the onError argument marshalling are thinner than the wrap() goop, and I'm getting unlucky with the exact addresses? I can't really compare, since I've only managed to see the crash once, long ago. (The "too much recursion" exception is easy to reproduce with the original URL. I can't get the within-JSD loop to happen.)
Comment 34 Steve Fink [:sfink] [:s:] 2011-04-27 21:15:57 PDT
New set of builds: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/sfink@mozilla.com-96f20f9c9291/

(That has some other hopefully irrelevant changes as well.)

Whoa... bugzilla is flipping out and changing random fields. Or maybe it's bz4.0 + bugzilla-tweaks?
Comment 35 Steve Fink [:sfink] [:s:] 2011-04-28 09:52:37 PDT
Comment on attachment 523469 [details] [diff] [review]
untested proposal

I feel like I understand the problem well enough, and the patch is straightforward enough, to r+.

One open issue is that this prevents any nesting of execution or call hooks -- so, for example, you can't stop at a breakpoint, spin a nested event loop, and stop at a |debugger| statement within it. I played with Firebug to see if I could get it to do this, and didn't see any way: normally, it resumes from the nested event loop whenever it can, so when you continue from a breakpoint you leave that execution hook, and it doesn't let you debug a tab while you're stopped at a breakpoint in a different tab. But I'm adding an f? for jjb to confirm this.
Comment 36 John J. Barton 2011-04-28 10:08:13 PDT
According to Boris, jsd's pause feature was designed to disable jsd while the event loop spins and Firebug uses pause in this way. That is we always pause jsd while we are in the nestedEventLoop. So your experiments confirm what we expect based on our code.

We have circumvented our pause feature in experimental code, in an effort to support debugging Firebug from Chromebug when Firebug is on a breakpoint. It works but we'd need more work on our side to make it useful. In general messing with jsd while you are running on a call stack passing through jsd is confusing. However, we'd love to be able to do this, and it does not seem from the outside that it should be impossible, but we don't rely on it now.
Comment 37 Steve Fink [:sfink] [:s:] 2011-04-29 12:08:21 PDT
(In reply to comment #36)
> According to Boris, jsd's pause feature was designed to disable jsd while the
> event loop spins and Firebug uses pause in this way. That is we always pause
> jsd while we are in the nestedEventLoop. So your experiments confirm what we
> expect based on our code.

Ok. The pause that I was talking about is called automatically by the JSD code when processing any jsdIExecutionHook or jsdICallHook, so the question isn't just limited to situations where firebug explicitly invokes jsd.pause. But your answer is still relevant:

> We have circumvented our pause feature in experimental code, in an effort to
> support debugging Firebug from Chromebug when Firebug is on a breakpoint. It
> works but we'd need more work on our side to make it useful. In general messing
> with jsd while you are running on a call stack passing through jsd is
> confusing. However, we'd love to be able to do this, and it does not seem from
> the outside that it should be impossible, but we don't rely on it now.

timeless: this sounds problematic. Unless ChromeBug and Firebug have different JSDContexts, but turning on the debugger is JSRuntime-wide.
Comment 38 timeless 2011-05-12 03:17:22 PDT
So, from jsdb (an experimental thing), the right approach is for each debugger to have its own JSRuntime which enables it to be very independent of the things with which it is managing. This of course was simpler for jsdb since its entire ui was a shell prompt >, and while it did support threads, it didn't really care much about them. The deepest debugger controlled the entire "ui". That part of the model isn't likely to work as well for a XUL system.

jsd-xpc does not provide for such a thing, and i'm not sure how well xpconnect would deal with it.

Of note, jetpack seems to have its own runtime....

At the very least, each content process has its own JSRuntime, which means that when someone tries to deal w/ content processes things will have to tolerate multiple JSRuntimes anyway.

jsd-xpc already has some pieces of this:

jsdIDebuggerService.activateDebugger(in JSRuntime rt);

I believe it's /probably/ a bug that jetpack doesn't call this, but right now it won't do anything useful because jsdService::ActivateDebugger treats rt as a singleton (this needs to be fixed eventually) - it's probably actually a good stepping stone to other things.

I'm also not sure how much this would help.

It should mean that the debugger core would be in its own runtime. This should enable a debugger to debug that debugger. However if you're actually debugging the UI and not the debugger core then you're probably back to the main xpconnect runtime instead of your debugger runtime.

I guess what it would mean is that you could pause incoming events to Firebug while still getting events which go to Chromebug, but they'd only be events for the core runtime, which is usually not what you're debugging (it'd be more like DebuggerBug).

As for JSDContexts...
The underlying jsdebug apis are actually pretty powerful and certainly could allow for multiple debuggers looking at different things at the same time (some of that happened w/in the last 2 years), jsd has limited support for it, jsd-xpc didn't get any.

I /think/ the right design for ChromeBug is that it finds the current jsdI consumer (Firebug), replaces it with itself, and chains events to it. Ideally ChromeBug could do this in some way so that when Firebug tries to 'pause', instead of triggering jsd-xpc's pause, it trigger's ChromeBug's pause which ChromeBug uses to decide to stop sending events to Firebug.

For a c++ impl of ChromeBug, this is technically possible by providing a replacement contract for jsdIDebuggerService (same contract, new CID), and a second contract (new contract which gets access to the real jsdIDebuggerService, either using the original CID or with another new CID which just chains everything directly to the original service accessed by its CID). I'm not sure if this is possible anymore, it certainly was doable before the great nsIModule=>manifest rewrite, where you could step on other people's contracts.
- It might be possible to cheat differently, by having Firebug first check to see if a @chromebug/debugger-service;1 exists, and if it does, get that instead of the standard service. The chromebug service would implement the same interface as the underlying service, and work more or less as I describe above.


---------------
tl;dr: i don't think you should worry too much about ChromeBug's implications on Firebug for this bug. If you want to push this patch, I won't cry too much.

Also, please contact me directly if you have questions, as I'm no longer actively reading bugmail.
Comment 39 Sebastian Zartner [:sebo] 2013-12-09 00:38:11 PST
FWIW I tested this right now using FF 25.0.1 + FB 1.12.5 under Win7 and I don't see any crash.

Sebastian
Comment 40 Sebastian Zartner [:sebo] 2015-01-22 00:15:36 PST
As of comment 39 I finally close this issue.

Sebastian

Note You need to log in before you can comment on or make changes to this bug.