Remember that Firefox add-on I wrote up a while back – the one that allows you to suppress annoying alert popups?
Some updates:
Not bad for my first add-on!
Remember alertCheck – that Firefox Extension I wrote a while back, that helped suppress annoying popups?
I finally decided to post it on Mozilla Addons. Now compatible with Firefox 3.5.*.
So, I think I’m more or less done the extension.
Someday, when I’ve got more extension development experience under my belt, I’ll probably come back to this and fix it up. Until then, this will have to do.
If you’re interested in looking at the source, just change the file extension from “.xpi” to “.zip”, and decompress. It’s all there.
There’s no license on this thing, no GPL, MIT, nothing. Use it however you want. If you find it useful though, I’d love to hear from you – send me email, post a comment, Facebook, Twitter, whichever.
Whew. I think I’m going to reward myself with some orange sherbet. Om nom nom…
Here’s a really annoying website to test the extension with. I really don’t recommend that you visit it without my extension installed.
The window hops around a bit, so just double click on the location bar, and type in something like “http://www.google.ca”. This will start up the flood of alerts, and (hopefully) you’ll be able to suppress them after the first one hits.
Here’s the site. Visit at your own risk.
UPDATE:
I’ve moved the extension to Mozilla Addons, and added Firefox 3.5 compatibility.
I’ve updated alertCheck.xpi so that it’ll play nice with Firefox 3.0b5, and hopefully Firefox 3.1.*. Let me know if there are any behaviour foulups, and I’ll do my best to fix them.
Wow. I think I got it. I’ve got a Firefox plugin that can suppress all alert() dialogs on a page if the user checks a “suppress” box on the second alert() dialog.
The trick, was not to rely on the DOMContentLoaded event to fire to do the override. Instead, I used the DOMWillOpenModalDialog to detect the first alert(). After detection, I overrode with an alertCheck which asked the user whether or not to “suppress more dialogs”. If the user answers in the affirmative, alert() is simply overwritten with an empty function.
Piece of cake.
A couple of issues though…
In order to override the alert() function, I have to write to document.getElementById(‘content’).contentWindow.wrappedJSObject.alert.
Remember how I mentioned the distance between the Extension JavaScript, and the inline content JavaScript? I said it felt like a security layer.
I was totally right.
Check this out. I’ll quote:
You should be aware of XPCNativeWrappers when working with untrusted content. With XPCNativeWrappers turned on (which is the default in Firefox 1.5+), your extension can safely access the DOM of the content document, but not the content JavaScript. Bypassing XPCNativeWrapper to work with content JavaScript directly can lead to security problems.
Hrmph. So I seem to be violating some security rules here. So maybe my approach isn’t the greatest idea. “Mook” from irc.mozilla.net #extdev suggested looking into commonDialog.xul…but I can’t seem to wrap my head around that just yet.
Not sure why yet, but while I can suppress dialog floods like this:
for (i = 0; i < 10; ++i) {
alert(i);
}
It seems to fail on this:
for (i = 0; i < 10; ++i) {
alert(i);
confirm(i);
}
For some reason, regardless of whether or not I choose to suppress the dialogs, they just keep coming. It works fine when I swap out the confirm() for a second alert(). Not exactly sure why. Yet.
Ok, so I’m going to clean the code up, and post it soon. I’ll also post a link to a real, brutally annoying website where you can test the alertCheck extension. Just give me a bit.
Ok, so there have been some developments.
Before I go into this though, I just want to make it clear that I have very little knowledge or experience working with XUL, or writing Firefox extensions in general. I’ve dabbled, but I’m mostly ignorant. So all you Firefox aficionados out there…go easy on me.
So, developments:
Using this site, I created a skeleton for my extension, calling it “alertCheck”.
And then I hit a brick wall right away, trying to find the right “alert” to override.
Let me explain. Mozilla extension development is strange for me because of all of the various layers to Firefox, and the distance between the JavaScript in the extension, and any page that is loaded in the browser. It feels like a security layer – and it makes sense: you really don’t want the Javascript on a website to monkey around with the internals of your browser.
Thankfully, this forum and this forum provided some help.
Now, after the appcontent is loaded, I wait for the DOMContentLoaded event to fire, and then write my new alert function to here:
document.getElementById('content').contentWindow.wrappedJSObject.alert
The problem is, if I wait for the DOMContentLoaded event to fire, the alert override happens (obviously) after all of the DOM Content is loaded into the browser. This is only useful if the alert’s that we want to capture are fired using <body onLoad> or some other function that detects when the DOM has been loaded. It’s no good for inline Javascript alerts, since these commands are parsed and executed line by line as the HTML is processed.
Phew. Big mouthful.
So, where does that leave me? Well, I was just hanging out in irc.mozilla.net in the #extdev channel. Here’s a chunk of what was said:
<mike_conley> Hey all - I'm trying to write an extension to override window.alert, with an alertCheck that allows users to disable future alerts.
<mike_conley> So far, I'm able to override alert by writing to document.getElementById('content').contentWindow.wrappedJSObject.alert
<mike_conley> however, now it's a matter of timing - I'm doing the override after the DOMContentLoaded event is fired
<mike_conley> But this means that it doesn't catch alerts that are fired using inline javascript.
<mike_conley> So my question is, when should I do the override?
<Mook> I suspect just overriding commonDialog.xul is easier
<Mook> trying to poke the content JS's definition is going to be full of pain
<mike_conley> Cool, I'll look into that - thanks!
<Mook> (the content JS starts around http://mxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#4022 and goes the the prompt service which pokes that xul)
<mike_conley> Excellent - I appreciate it.
So maybe there’s another approach that I should be taking – I’m going to look into overriding commonDialog.xul… I’ll write more when I have it.