Just a few weeks in the past I launched JavaScript Deobfuscator 2.Zero - finally something that works with present Firefox versions once more. Why did it take me a 12 months to fix this compatibility problem? Well, it actually wasn’t that easy. After considering all of the prospects I determined that rewriting it from scratch was the only risk, and that was laborious to perform in my spare time. Before I proceed with the technical particulars, enable me to introduce JavaScript Deobfuscator in its new reincarnation: it now adds a panel to Firefox Developer Tools. Instead of messing with filters your view is restricted to the current tab automatically. Both compiled and executed scripts go into the identical listing, with some textual content indicating whether we’ve seen the script being compiled or executed or each. Starting with Firefox 39 even code working in Web Workers will be displayed. And JavaScript Deobfuscator will beautify the code as an alternative of counting on the JavaScript engine to take action.

The draw back is that only Firefox is supported now - other purposes merely don’t have Developer Tools to integrate with. Also, debugging add-ons or the browser itself isn’t attainable-- Developer Tools run in a separate process for that, no add-ons put in there. Finally, the search functionality is absolutely rudimentary right now, that’s something I hope to improve finally. Now to the technical details. The reason for this overhaul is the new debugging interface which replaced the one JavaScript Deobfuscator was utilizing. The previous debugging interface was conceptually completely different, it was designed as a single hook to gather all data. The brand new one alternatively collects information about individual compartments and it’s as much as you to figure out which of them you need. After a number of unsuccessful attempts to continue gathering all data in JavaScript Deobfuscator I realized that it made much more sense to look at particular person tabs.

Using the new debugging API turned out to be tricky to say the least. Did I link to MDN above? Sorry about that, I ought to have linked to the SpiderMonkey source code. It’s very just like the MDN documentation however the later is outdated. And even if you happen to look on the SpiderMonkey source, much of the documentation is merely wishful pondering, listing features that had been never implemented. A new UI idea had to be developed as well, and the only good option for per-tab debugging would be integrating into the Firefox Developer Tools. That’s where the fun really began. Then I checked out what TargetType is and the way present instruments work with it - this was the point the place I realized that there are so many implementation particulars concerned that an extension can not presumably do it. So I gave up. When i got here back just a few months later things improved, barely. Somebody wrote an Add-on SDK module to create new Developer Tools panels.

While I didn’t use that module directly, it showed nicely which components of the API are contractual and which of them are merely implementation particulars. It additionally confirmed that things aren’t too bad for those who restrict your self to a single target kind - an area tab. Handling remote connections to browser and add-ons is more complicated, but as I mentioned above extensions cannot do this anyway. Now that article stops at the purpose the place you "merely" need to make use of the distant debugging protocol to communicate with the built-in debugging actor. Well, possibly it is de facto easy however I couldn’t determine how to do this - and whether that protocol is one thing I can depend on. See, the constructed-in tools will definitely be adjusted when the debugging actor or/and the protocol change. My extension however might be damaged, and I’ll need to speculate time into figuring out what changed and the way my code needs to be adjusted while staying compatible with older Firefox versions.

So JavaScript Deobfuscator makes use of the debugging interface immediately, with out relying on the debugging actor of the Developer Tools. And it beautifies JavaScript code using its own copy of a library quite than relying on code used by Developer Tools - JavaScript beautification in Developer Tools is presently an implementation detail that extensions cannot rely on. JavaScript Deobfuscator additionally duplicates the types of the two Developer Tools themes to ensure it appears similar to the present panels - simply utilizing the styles from Developer Tools would have probably triggered a catastrophe after just a few Firefox releases. Not that the built-in styles are actually outlined in a generic way, there is admittedly lots of inconsistencies there and every panel is styled somewhat differently. These are only some examples, Jennette mccurdy there's more code duplication. Developer Tools aren’t currently built to allow extensions to reuse their code. Still, I’m pretty proud of the result, and that i hope that the biggest chunk (JavaScript beautification) will go away ultimately. From the usability standpoint the brand new version is a big leap forward, getting there could have been simpler nonetheless.