Active Stop Button compatibility

Bug reports and enhancement requests
Post Reply
Alan Baxter
Ambassador
Posts: 1586
Joined: Fri Mar 20, 2009 4:47 am
Location: Colorado, USA

Active Stop Button compatibility

Post by Alan Baxter »

I just updated to the latest version of the Active Stop Button extension, version 1.4.2. In the change log, the developer complains that this version contains a workaround for an issue created by NoScript. Is this something that should be addressed on NoScript's end?
Ref: https://addons.mozilla.org/en-US/firefo ... /versions/
Improved compatibility with addons, which thoughtlessly redefine BrowserToolboxCustomizeDone, like NoScript
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
User avatar
Giorgio Maone
Site Admin
Posts: 9527
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Active Stop Button compatibility

Post by Giorgio Maone »

NoScript wraps BrowserCustomizeToolbarDone() in order to initialize NoScript's UI whenever the toolbar button gets added, since there's no official notification API to intercept this event:

Code: Select all

let btcd = window.BrowserToolboxCustomizeDone;
if (btcd) window.BrowserToolboxCustomizeDone = function(done) {
 btcd(done);
 if (done) noscriptOverlay.initPopups();
}
This is what is deemed "unthoughtful" by Active Stop Button's guys.

But, surprise!, Active Stop Button 1.4.0 (previous version), did something very similar, supposedly in a more "thoughtful" way?

Code: Select all

eval("BrowserToolboxCustomizeDone ="+BrowserToolboxCustomizeDone.toString().replace(
/{/,"{"+"ASB_BrowserToolboxCustomizeDone();"));
Ooops, what were they thinking?
Patching functions that way (by modifying their source code in place with eval()) is doomed to fail as soon as anybody else wraps or replaces the same function, either in a thoughtful or in an unthoughtful way.

In fact, as a "work-around", 1.4.2 adopts the same "unthoughtful" wrapping (eval-less) technique as NoScript, nobody breaks and everybody is happy, albeit unthoughtful ;)
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Alan Baxter
Ambassador
Posts: 1586
Joined: Fri Mar 20, 2009 4:47 am
Location: Colorado, USA

Re: Active Stop Button compatibility

Post by Alan Baxter »

Thank you for the clarification, Giorgio.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
User avatar
JustOff
Posts: 1
Joined: Thu Mar 10, 2011 11:59 am

Re: Active Stop Button compatibility

Post by JustOff »

I am a developer of Active Stop Button and first of all wanted to thank Giorgio for the NoScript addon, which I use by myself.

Now, concerning the modification of BrowserToolboxCustomizeDone.

Way by which this was done by me 4 years ago (by modifying source code in place with eval) is certainly deprecated. Nevertheless, it does not cause conflicts with extensions that properly insert their own handler in this function, unlike NoScript does it.

NoSctipt code listed above, simply redefines window.BrowserToolboxCustomizeDone, removing all handlers installed by other extensions previously. To preserve the operability of my extension, in case it is initialized prior to NoScript, I was forced to use a trick with a delayed startup. But if I would have used exactly the same technique as NoScript (redefine window.BrowserToolboxCustomizeDone), then I would have broke operation of NoScript.

The only possible way to avoid problems in this situation that I found, is to substitute handler CustomizeDone for a navigator-toolbox element (which defaults to BrowserToolboxCustomizeDone function), rather than the function itself:

Code: Select all

var ntoolbox = document.getElementById('navigator-toolbox');
_ToolboxCustomizeDone = ntoolbox.customizeDone;
ntoolbox.customizeDone = function MyCustomizeDone(aToolboxChanged) {
    _ToolboxCustomizeDone(aToolboxChanged);
    <custom code>
};
It is this solution was used in the Active Stop Button 1.4.2.

Also, I want to note that with the release of Firefox 4 (Gecko 2.0) introduced the new toolbar customization events, which should help avoid future problems such as discussed above.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6 YB/4.1.0
User avatar
Giorgio Maone
Site Admin
Posts: 9527
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Active Stop Button compatibility

Post by Giorgio Maone »

JustOff wrote:NoSctipt code listed above, simply redefines window.BrowserToolboxCustomizeDone, removing all handlers installed by other extensions previously. To preserve the operability of my extension, in case it is initialized prior to NoScript, I was forced to use a trick with a delayed startup. But if I would have used exactly the same technique as NoScript (redefine window.BrowserToolboxCustomizeDone), then I would have broke operation of NoScript.
Sorry, but I fail to see how you would. Could you explain it in more details?

As far as I can see, if you replace window.BrowserToolboxCustomizeDone the way NoScript does (i.e. storing the original handler -- or whatever it's been replaced with in the meanwhile -- and calling it from inside your replacement), you cannot break those who did the same before you (you'll call them), nor you'll be broken by those who come after you (they'll call you).

Am I missing something?
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15
Post Reply