[Greasemonkey] firefox weirdness (namespace conflicts?)
Godmar Back
godmar at gmail.com
Thu Jul 28 15:43:31 EDT 2005
On 7/28/05, Aaron Boodman <zboogs at gmail.com> wrote:
> Right, but it could be that extension's javascript which is doing it.
> Like you said, removing that extension's javascript file stopped the
> problem from happening. It is possible that the extension is monkeying
> with the DOM nodes in the menu and something is getting dropped.
> Without actually looking at that extension's code it's difficult to
> say.
>
No, I have disabled all of the other extension's Javascript, except for
<script type="application/x-javascript"
src="chrome://communicator/content/utilityOverlay.js" />
which is a set of utility routines that comes with Firefox. No
Javascript from the other extension is being executed.
I looked in utilityOverlay.js and it's mostly function definitions and
one or two global variables.
If I also disable this .js file, so that no javascript is run period
the error with GM does not occur.
> > No, the exception is not reported; GM dies a silent death during initialization.
> > I know of the exception only because I debugged GM and found out
> > exactly where it died during it's initialization and then I wrapped
> > those places in the try/catch clauses I showed in my original email.
> >
> > What I recommend is to wrap the initialization in browser.xul (all of
> > the javascript executed when the xul is loaded, and also independently
> > the "load" handler that's run when a new browser is opened) in a
> > try/catch and output errors if any to the console.
>
> That is very strange. The default behavior of Mozilla is to report
> unhandled exceptions to the JavaScript Console (we're talking about
> the JavaScript console here, right? -- as opposed to the command line
> console?). And as far as I know, I'm not swallowing any exceptions...
> I routinely get all sorts of initialization errors from GM in the JS
> console. There is no need (and in fact it's bad form) to additionally
> wrap the initialization code and rethrow exceptions.
>
Maybe it's because you're using a debug build rather than a release
build - or I don't have the right preferences set. But I do know that
with default preferences, on a release build, no exceptions are being
displayed. I'm only suggesting this so you could learn if this
happens to others.
> Perhaps your other extension is eating the exceptions at a higher
> level? By handling window.onerror perhaps? Again, this would be easier
> to debug with specifics.
As I said, the error occurs despite no Javascript code being executed
by the other extension - the fact that it include that
communicator/utilityOverlay.js file is what breaks it - on Mac OS
only. I actually don't think GM or the other extension is to blame, I
think it's a bug in FF; I only sent this email to see if others had
experienced similar weirdness.
- Godmar
More information about the Greasemonkey
mailing list