On Oct 8, 5:06 pm, Andrew R <[email protected]> wrote:
> A user of my extension has realized that errors occur when firebug is
> opened in a new window. The reason is that Firebug.chrome.$(id) was
> returning null when I called a function during reattaching. Unlike the
> firebug code, I haven't been keeping local variables around to point
> to the DOM elements, but have instead have looked them up as needed
> (perhaps I will have to change that).
>
> In code like the commandLine.js, it seems that Firebug.chrome always
> gets passed to "setMultiLine", but in syncFilterButtons in net.js,
> initializeUI in the module uses FirebugChrome, where other code is
> using Firebug.chrome.
Use Firebug.chrome. We are trying to get rid of FirebugChrome.
>
> What are the rules of thumb when using $(id) in terms of using with or
> without the chrome and which chrome to use?
chrome.js has XUL-window specific code; Firebug.chrome is the current
window's chrome object. When we detach the Firebug object is not
changed, but Firebug.chrome changes from in-browser to the firebug.xul
window (and vice versa).
I don't like the way $() works in Firebug, too mysterious, eg this is
the definition in chrome.js:
$: function(id)
{
return $(id);
},
So when you say Firebug.chrome.$("foo"), it calls the function above
in the scope of chrome.js where document resolves to what ever it was
when you compiled chrome.js. That can be in browser.xul or
firebug.xul.
If Firebug.chrome.$(id) returns null, then the most likely problem is
not $() or chrome, but rather that the document is not ready with the
element yet.
jjb
>
> Thank you,
> Andrew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Firebug" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/firebug?hl=en
-~----------~----~----~----~------~----~------~--~---
