422767 - Get Chromebug to work with FF3

Status: RESOLVED FIXED

(Firefox :: Extension Compatibility, defect)

Description

[John J. Barton]

Tracking for Mozilla/Gecko/FF issues hit by chromebug

Comment 1

[John J. Barton]

Current status: 
  Chromebug works on FF3b4 and FF2.0.0.12. Its not functional on b5pre because of 246699.

Comment 2

[John J. Barton]

Today FF3b4 crashes sometime after chromebug opens firefox with window.open(),
http://crash-stats.mozilla.com/report/index/a400df3d-f250-11dc-9001-001a4bd43ed6?date=2008-03-15-05

The nightly FF3b5pre updated but still blocked by 246699.

Comment 3

[John J. Barton]

On FF3b4 I tried to isolate crash point. Tried to load version of chromebug and firebug1.2 from getfirebug.com. after running FF3b5pre and FF2, and other stuff, I got back to 3b4: no crash. Also my bookmarks were gone.  So something in the profile state is related to the crash? I wonder if this could be related to 410060 or 421392, both startup problems.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #1)
> Current status: 
>   Chromebug works on FF3b4 and FF2.0.0.12. Its not functional on b5pre because
> of 246699.

Why bug 246699 doesn't break firebug in FF3b4 or FF2?

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

How does 246699 break things?  If you're getting that lame error string you're hitting a security veto, but you'll hit the same security veto even if you get a better error report.

And if you mean that the _fix_ for 246699 breaks you, I don't really understand -- in what case are you now failing that you weren't before?

Comment 6

[John J. Barton]

(In reply to comment #5)
> How does 246699 break things?  If you're getting that lame error string you're

I get a number of messages described in 246699:
Permission denied to get property UnnamedClass.classes

But I don't know which of my 12,000 lines of code might have triggered the message.  Furthermore I have no code that needs to access property "UnnamedClass.classes", even if this identifier was a legal Javascript property identifier, which it is not.

> hitting a security veto, but you'll hit the same security veto even if you get
> a better error report.

Ok, well that's some news.  What's a security veto and which statements in my code have to be changed?

Other than these issues I have no problem with 246699...

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(In reply to comment #6)
> But I don't know which of my 12,000 lines of code might have triggered the
> message.  Furthermore I have no code that needs to access property
> "UnnamedClass.classes", even if this identifier was a legal Javascript property
> identifier, which it is not.

False, clearly:

o = {}; o["UnnamedClass.classes"] = "hello"; alert(o["UnnamedClass.classes"]);

but that error message gives the class and property both.  I suspect it means Components.classes (where Components doesn't have a name that's accessible to that code).

> > hitting a security veto, but you'll hit the same security veto even if you get
> > a better error report.
> 
> Ok, well that's some news.  What's a security veto and which statements in my
> code have to be changed?

I don't know which statements need to be changed, though possibly ones that reference "classes" -- provide a test case that's shorter than the 12,000 lines of code you reference above, and I might be able to help narrow it down.

But still: the _behaviour_ of chromebug should be identical whether you get the old message or the new one, so I feel like we're still just blaming the messenger.  With 246699's patch, did you not get a useful stack to trace, via your own debugger onError hook?

Comment 8

[John J. Barton]

(In reply to comment #7)
> (In reply to comment #6)
> > But I don't know which of my 12,000 lines of code might have triggered the
> > message.  Furthermore I have no code that needs to access property
> > "UnnamedClass.classes", even if this identifier was a legal Javascript property
> > identifier, which it is not.
> 
> False, clearly:
> 
> o = {}; o["UnnamedClass.classes"] = "hello"; alert(o["UnnamedClass.classes"]);

Wow, the oddity of this language never ceases to amaze me. I wonder if this creates a property of 'o' or 'o.UnnamedClass'?

> but that error message gives the class and property both.  I suspect it means
> Components.classes (where Components doesn't have a name that's accessible to
> that code).

Ah, more clues. This narrows it down to only a thousand or so lines ;-) So under what circumstances is chrome code not allowed to call Components.classes?

> 
> > > hitting a security veto, but you'll hit the same security veto even if you get
> > > a better error report.
> > 
> > Ok, well that's some news.  What's a security veto and which statements in my
> > code have to be changed?
> 
> I don't know which statements need to be changed, though possibly ones that
> reference "classes" -- provide a test case that's shorter than the 12,000 lines
> of code you reference above, and I might be able to help narrow it down.

Yes, well I'd create a smaller test case if I knew which lines to focus on. I'd do a binary search if I had nothing better to do. Oh, wait, I do ;-)

> But still: the _behaviour_ of chromebug should be identical whether you get the
> old message or the new one, so I feel like we're still just blaming the
> messenger.  

Yep, that's exactly I am doing. The messenger is supposed to tell me what the problem is and where to look to fix it. In this case it does neither. 


> With 246699's patch, did you not get a useful stack to trace, via
> your own debugger onError hook?
> 

Well I get stuff that makes no sense to me, so I assumed it wasn't useful:
<top>
(0)chrome://firebug/content/errors.js:99-234@100
<bottom>
debugger.onError:  sees object with typeof: 'object'; object contains:
[message]=uncaught exception: Permission denied to create wrapper for object of class UnnamedClass;
[fileName]=null;
[lineNo]=0;
[pos]=0;
[flags]=2;
[errnum]=147;
[exc]=null;

The line cited is the first executable line of 
    // extends ConsoleObserver

    observe: function(object)
    {
        if(typeof(FBTrace) == "undefined") return;  /*@explore*/
        var context = FirebugContext;

This is so weird that I wonder about my code (given that I am working on the debugger that prints this).  But why doubt something that has worked in the past when a message like UnnamedClass.classes suddenly comes along?

Comment 9

[John J. Barton]

Any chance that
Permission denied to get property UnnamedClass.classes
really means:
Components is not defined in this scope?

Also I just noticed that there are two versions of the mystery message, the property version above and as in Comment 8,
Permission denied to create wrapper for object of class UnnamedClass;

Maybe your decoding ring gives different results for theses?

Comment 10

[John J. Barton]

Well this is follow up to https://bugzilla.mozilla.org/show_bug.cgi?id=246699#c15

Running tonight's build,
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031705 Minefield/3.0b5p
I get new info, a call stack.  One case is almost intelligible:
<top>
(0)XPCSafeJSObjectWrapper.cpp:445-446@445
(0)chrome://chromebug/content/ChromeBugPanel.js:487-502@490
(...stack omitted....)
<bottom>
debugger.onError:  sees object with typeof: 'object'; object contains:
[message]=Permission denied to create wrapper for object of class UnnamedClass;
[fileName]=XPCSafeJSObjectWrapper.cpp;
[lineNo]=445;

Ok, let's ignore the top of the stack. The next one is here:

    getDocShellByDOMWindow: function(domWindow)
    {
       if (domWindow instanceof Components.interfaces.nsIInterfaceRequestor)
        {
490:            var navi = domWindow.getInterface(Components.interfaces.nsIWebNavigation);
491            if (navi instanceof Components.interfaces.nsIDocShellTreeItem)
....

So is there something wrong with this code? Maybe not, because the identical error message comes out with a stack that makes no sense at all:

<top>
(0)chrome://firebug/content/bindings.xml/eval/0I8LmYwexK%2BDX8QihSLRFw%3D%3D:445-446@36
(0)chrome://chromebug/content/ChromeBugPanel.js:487-502@490
(...stack omitted...)
<bottom>
debugger.onError:  sees object with typeof: 'object'; object contains:
[message]=Permission denied to create wrapper for object of class UnnamedClass;
[fileName]=XPCSafeJSObjectWrapper.cpp;
[lineNo]=445;

Makes no sense.  So I'm sticking with "b5pre is broken". 

Comment 11

[John J. Barton]

Ok tonight the stack is gone :-(. And the message is different.

Two kinds of the UnnamedClass errors appear in the Error Console:

Error: [Exception... "'Permission denied to create wrapper for object of class UnnamedClass' when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]

Error: [Exception... "'Permission denied to get property UnnamedClass.itemType' when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]

None of them come through jsdIDebuggerService.onError(). That explains part of my confusion before. Since I have a half-dozen errors on startup coming through onError() I failed to notice that the additional half-dozen UnnamedClass errors are not.  And perhaps the confusing stack traces last night are cause by my consoleService observer reporting traces from other errors as related to the UnnamedClass error.

Comment 12

[John J. Barton]

There is a third variant, also does not come through onError:

Error: uncaught exception: Permission denied to create wrapper for object of class UnnamedClass

Since some of the stack traces pointed to my consoleService observer I removed it. No effect.

I found one call to handleEvent:
 spy.onreadystatechange.handleEvent(event);
I removed it. No effect.

Comment 13

[John J. Barton]

(In reply to comment #4)
> 
> Why bug 246699 doesn't break firebug in FF3b4 or FF2?

Because I don't get these exceptions in FF3b4 or FF2. Something was added at the beginning of FFb5pre to cause them. I think they are new security checks, I assume they are legit errors but because the reporting is so bad I can't find and fix my errors.

Comment 14

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Could you try some nightlies and see when it started happening?  That would be a huge help, and I'm still futzing with mochitests to get 246699 in landable shape.

Comment 15

[John J. Barton]

246699 happens in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030506 Minefield/3.0b5pre

246699 does not happen in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030405 Minefield/3.0b5pre

Comment 16

[John J. Barton]

Here is another FF3 problem that I don't know how to report properly. Sometimes, jsd.onError is called twice for the same error but with different call stacks. The first one is all good. The second one is called on the entry to firebug's consoleService observe(). So if you look back up to comment #8 you can see a call stack that appears to point into errors.js. Now I realize that this was probably one of these duplicate calls to onError(), perhaps the first of the pair had a stack that made sense.

Comment 17

[John J. Barton]

With 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032505 
Minefield/3.0b5pre
and xpcnativewrappers=no removed, chromebug is kinda working again. The issues discussed here from comment #4 to #16 all vanished. 
So "b5pre no longer broken" ;-)

Comment 18

[John J. Barton]

With 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032705 Minefield/3.0pre
I am crashing with the stack listed in 425452. It pretty reproducible but involves JSD. I'll wait for b5 release then ask getfirebug.com to release a version to file a bug with.

Comment 19

[Justin Dolske [:Dolske]]

(In reply to comment #18)
> I am crashing with the stack listed in 425452.

That stack might have been caused by bug 424376 (which has since been backed out, but is still present in beta 5).

Comment 20

[John J. Barton]

I've used Chromebug with FF3.0 quite successfully and don't have problems I can blame on FF.

FF3.1b1 crashes immediately
http://crash-stats.mozilla.com/report/index/0c9568f5-acf0-11dd-90bb-001cc45a2ce4

Should we close this bug and start fresh?

Comment 21

[Rob Campbell [:rc] (:robcee)]

I'm thinking yes, since I can get chromebug working in 3.0. I'd still like to get a version of it ready to go on AMO though. Maybe that should be the target for the new bug?