Dotjs<\/a> was originally created by Chris Wanstrath<\/a> as a Google Chrome extension and as of this writing has also been ported to Firefox, Safari and Fluid. The SDK-based Firefox add-on was ported by Mozilla WebDev Ricky Rosario<\/a>, and is available on AMO here<\/a> and of course on github here<\/a>.<\/p>\n The idea behind dotjs is nice and simple: you create a .js directory in your home directory and put your content scripts there. To load a script on github.com, you just name that script ‘github.com.js’.<\/p>\n dotjs’ code executes in a nice, simple sequence of events:<\/p>\n <\/p>\n The main functionality in dotjs is implemented using page-mod<\/a>:<\/p>\n The page-mod implementation is fairly straightforward – it attaches the ‘dotjs.js’ content script to every page loaded by Firefox. In the The content script for dotjs is also pretty straightforward:<\/p>\n The content script does three things:<\/p>\n This add-on does need chrome privileges in order to reliably find the user’s home directory and resolve the .js and .css directories in a cross-platform compatible way. All of this functionality is contained in the dotjs.js module<\/a> in the add-on’s lib directory. In particular, the dotjs library uses the Once we have a handle on the .js directory, we loop through the files in it to find a match based on the current web page’s url:<\/p>\n Ricky also added in Coffeescript and CSS support as a nice extra feature, so that you can write Coffeescript content scripts or CSS style-sheets and have them injected into the target site by the add-on:<\/p>\n When I read Ricky’s code I really liked it – it is simple, compact, makes sensible use of the SDK’s built-in features and design patterns, and also uses Firefox’s internal apis to get filesystem access when needed. I have also been involved with lots of discussions about various add-on memory use complaints, and wondered if I would make dotjs a little more efficient. The first real attempt at this encapsulated in pull request 19<\/a>:<\/p>\n Optimization 1:<\/strong> Ricky’s original code always loaded jQuery into every page loaded in the browser. Instead, I opted to remove the jQuery dependency for the initial content script. This way jQuery is only loaded if there is a file match. [ commit<\/a> ]<\/p>\n Optimization 2:<\/strong> when using page-mod, always bail out of documents that are in a frame. Social networking sites in particular are guilty of embedding lots of iframes as ‘social plugins’ which can really bog down the browser. [ commit<\/a> ]<\/p>\n Modularity:<\/strong> originally the file matching code was located in main.js, but I opted to move it into dotjs.js as a separate CommonJS module, mainly so I could keep the chrome-privileged code as separate as possible. For such a small add-on as dotjs this isn’t much of a concern, but isolating chrome-privileged code into modules greatly simplifies the add-on reviewer’s job, especially for large, complex add-ons. In theory, we could even write tests for dotjs.js!<\/p>\n This is as far as I got. I have considered some ideas for future, mainly along these themes:<\/p>\n\n
SDK API Usage<\/h3>\n
\r\nrequire(\"page-mod\").PageMod({\r\n include: \"*\",\r\n contentScriptFile: data.url('dotjs.js'),\r\n onAttach: function (worker) {\r\n worker.port.on('init', function(domain) {\r\n let host = url.URL(domain).host;\r\n if (!host)\r\n return;\r\n\r\n if (host.indexOf('www.') === 0) {\r\n host = host.substring(4, host.length);\r\n }\r\n \r\n let files = matchFile(host);\r\n\r\n \/\/ how to tell from here if we actually matched something?\r\n if (files.match)\r\n worker.port.emit('load-scripts', files);\r\n });\r\n }\r\n});\r\n<\/pre>\nonAttach<\/code> handler the worker is set up to listen for an init event; when it recieves this event it then gets a list of files from the matchFile<\/code> function and passes the results back to the content script.<\/p>\nContent Script<\/h3>\n
\r\n\/*\r\n * catch the 'load-scripts' event and inject the results into the current scope.\r\n *\/\r\n(function() {\r\n self.port.on(\"load-scripts\", function(msg) {\r\n \/\/ bail out if we're in an iframe\r\n if (window.frameElement) return;\r\n \r\n if (msg.jquery) {\r\n eval(msg.jquery);\r\n }\r\n\r\n if (msg.js) {\r\n eval(msg.js);\r\n }\r\n\r\n if (msg.coffee) {\r\n (function() {\r\n eval(msg.transpiler);\r\n }).call(window); \/\/ coffee-script.js assumes this === window\r\n eval(CoffeeScript.compile(msg.coffee));\r\n }\r\n\r\n if (msg.css) {\r\n var headNode = document.querySelector('head');\r\n var cssNode = document.createElement('style');\r\n cssNode.innerHTML = msg.css;\r\n headNode.appendChild(cssNode);\r\n }\r\n });\r\n\r\n if (document.URL.indexOf('http') === 0) {\r\n self.port.emit('init', document.URL); \r\n }\r\n})();\r\n<\/pre>\n\n
require(“chrome”)<\/h3>\n
directory_service<\/code> xpcom service to get the home directory resolve the js\/css directories, as well as the SDK’s own file module to test if files exist, join paths and read file contents:<\/p>\n\r\nconst {Cc, Ci} = require('chrome'); \r\nconst data = require(\"self\").data;\r\nconst file = require('file');\r\nconst dirSvc = Cc['@mozilla.org\/file\/directory_service;1'].getService(Ci.nsIProperties),\r\nhomeDir = dirSvc.get('Home', Ci.nsIFile).path,\r\njsDir = homeDir.indexOf('\/') === 0 ? '.js' : 'js';\r\ncssDir = homeDir.indexOf('\/') === 0 ? '.css' : 'css';\r\n<\/pre>\n\r\nlet filename = file.join(homeDir, jsDir, files[i]);\r\n\r\nif (file.exists(filename + '.js')) {\r\n ret.js = file.read(filename + '.js');\r\n jsmatch = true;\r\n ret.match = true;\r\n}\r\n<\/pre>\n\r\nif (file.exists(filename + '.coffee')) {\r\n\tret.transpiler = data.load('coffee-script.js');\r\n ret.coffee = file.read(filename + '.coffee');\r\n jsmatch = true;\r\n ret.match = true;\r\n}\r\n\r\nlet cssname = file.join(homeDir, cssDir, files[i]);\r\nif (file.exists(cssname + '.css')) {\r\n ret.css = file.read(cssname + '.css');\r\n ret.match = true;\r\n}\r\n<\/pre>\nPerformance considerations<\/h3>\n
\n