Most Firefox addons add a toolbar button that does something when clicked, or
you can add such button by dragging it via Customize Firefox interface.
For example, I have a button for (an awesome) Column Reader extension on the
right of FF menu bar (which I have always-visible):
But as far as I can tell, most simple extensions don't bother with some custom
hotkey-adding interface, so there seem to be no obvious way to "click" that
button by pressing a hotkey.
In case of Column Reader, this is more important because pressing its button is
akin to "inspect element" in Firebug or FF Developer Tools - allows to pick any
box of text on the page, so would be especially nice to call via hotkey + click,
(as you'd do with Ctrl+Shift+C + click).
As I did struggle with binding hotkeys for specific extensions before (in their
own quirky ways), found one sure-fire way to do exactly what you'd get on click
this time - by simulating a click event itself (upon pressing the hotkey).
Whole process can be split into several steps:
Install Keyconfig or similar extension, allowing to bind/run arbitrary
One important note here is that such code should run in the JS context of the
extension itself, not just some page, as JS from page obviously won't be
allowed to send events to Firefox UI.
Keyconfig is very simple and seem to work perfectly for this purpose - just
"Add a new key" there and it'll pop up a window where any privileged JS can be
Install DOM Inspector extension (from AMO).
This one will be useful to get button element's "id" (similar to DOM elements'
"id" attribute, but for XUL).
It should be available (probably after FF restart) under "Tools -> Web
Developer -> DOM Inspector".
Run DOM Inspector and find the element-to-be-hotkeyed there.
Under "File" select "Inspect Chrome Document" and first document there -
should update "URL bar" in the inspector window to
Now click "Find a node by clicking" button on the left (or under "Edit ->
Select Element by Click"), and then just click on the desired UI
button/element - doesn't really have to be an extension button.
It might be necessary to set "View -> Document Viewer -> DOM Nodes" to see XUL
nodes on the left, if it's not selected already.
There it'd be easy to see all the neighbor elements and this button element.
Any element in that DOM Inspector frame can be right-clicked and there's
"Blink Element" option to show exactly where it is in the UI.
"id" of any box where click should land will do (highlighted with red in my
case on the image above).
whatever other hotkey-addon).
I did try HTML-specific ways to trigger events, but none seem to have worked
with XUL elements, so JS below uses nsIDOMWindowUtils XPCOM interface,
which seem to be designed specifically with such "simulation" stuff in mind
(likely for things like Selenium WebDriver).
JS for my case:
var el_box = document.getElementById('columnsreader').boxObject;
var domWindowUtils =
domWindowUtils.sendMouseEvent('mousedown', el_box.x, el_box.y, 0, 1, 0);
domWindowUtils.sendMouseEvent('mouseup', el_box.x, el_box.y, 0, 1, 0);
"columnsreader" there is an "id" of an element-to-be-clicked, and should
probably be substituted for whatever else from the previous step.
There doesn't seem to be a "click" event, so "mousedown" + "mouseup" it is.
"0, 1, 0" stuff is: left button, single-click (not sure what it does here), no
If anything goes wrong in that JS, the usual "Tools -> Web Developer ->
Browser Console" (Ctrl+Shift+J) window should show errors.
It should be possible to adjust click position by adding/subtracting pixels
from el_box.x / el_box.y, but left-top corner seem to work fine for buttons.
Save time and frustration by not dragging stupid mouse anymore, using trusty
hotkey instead \o/
Wish there was some standard "click on whatever to bind it to specified
hotkey" UI option in FF (like there is in e.g. Claws Mail
), but haven't
seen one so far (FF 36).
Maybe someone should write addon for that!
Just had an epic moment wrt how to fail at kinda-basic math, which seem to be
quite representative of how people fail wrt homebrew crypto code (and what
everyone and their mom warn against).
So, anyhow, on a d3 vis, I wanted to get a pseudorandom colors for text blobs,
but with reasonably same luminosity on HSL scale (Hue - Saturation -
Luminosity/Lightness/Level), so that changing opacity on light/dark bg can be
seen clearly as a change of L in the resulting color.
There are text items like (literally, in this example) "thing1", "thing2",
"thing3" - these should have all distinct and constant colors, ideally.
So how do you pick H and S components in HSL from a text tag?
Just use hash, right?
As JS doesn't have any hashes yet (WebCryptoAPI
is in the works) and I don't
really need "crypto" here, just some str-to-num shuffler for color, decided
that I might as well just roll out simple one-liner non-crypto hash func
There are plenty of those around, e.g. this list
Didn't want much bias wrt which range of colors get picked, so there are these
test results - link1, link2 - wrt how these functions work, e.g. performance
and distribution of output values over uint32 range.
Picked random "ok" one - Ly hash, with fairly even output distribution,
implemented as this:
hashLy_max = 4294967296 # uint32
hashLy = (str, seed=0) ->
for n in [0..(str.length-1)]
c = str.charCodeAt(n)
while c > 0
seed = ((seed * 1664525) + (c & 0xff) + 1013904223) % hashLy_max
c >>= 8
c >>= 8 line and internal loop here because JS has unicode strings, so it's
a trivial (non-standard) encoding.
But given any "thing1" string, I need two 0-255 values: H and S, not one
So let's map output to a 0-255 range and just call it twice:
hashLy_chain = (str, count=2, max=255) ->
[hash, hashes] = [0, ]
scale = d3.scale.linear()
.range([0, max]).domain([0, hashLy_max])
for n in [1..count]
hash = hashLy(str, hash)
Note how to produce second hash output "hashLy" just gets called with "seed"
value equal to the first hash - essentially hash(hash(value) || value).
People do that with md5, sha*, and their ilk all the time, right?
Getting the values from this func, noticed that they look kinda non-random at
all, which is not what I came to expect from hash functions, quite used to
dealing crypto hashes, which are really easy to get in any lang but JS.
So, sure, given that I'm playing around with d3 anyway, let's just plot the
"Wat?... Oh, right, makes sense."
Especially with sequential items, it's hilarious how non-random, and even
constant the output there is.
And it totally makes sense, of course - it's just a "k1*x + x + k2" function.
It's meant for hash tables, where seq-in/seq-out is fine, and the results in
"chain(3)" and "chain(3)" calls are so close on 0-255 that they map to the
same int value.
Plus, of course, the results are anything but "random-looking", even for
non-sequential strings of d3.scale.category20() range.
Lession learned - know what you're dealing with, be super-careful rolling your
own math from primitives you don't really understand, stop and think about wth
you're doing for a second - don't just rely on "intuition" (associated with e.g.
Now I totally get how people start with AES and SHA1 funcs, mix them into their
own crypto protocol and somehow get something analogous to ROT13 (or even
double-ROT13, for extra hilarity) as a result.
As I was working on a small d3-heavy project (my weird firefox homepage), I
did use d3 scales for things like opacity of the item, depending on its
relevance, and found these a bit counter-intuitive, but with no
readily-available demo (i.e. X-Y graphs of scales with same fixed domain/range)
on how they actually work.
Basically, I needed this:
I'll be first to admit that I'm no data scientist and not particulary good at
math, but from what memories on the subject I have, intuition tells me that
e.g. "d3.scale.pow().exponent(4)" should rise waaaay faster from the very start
than "d3.scale.log()", but with fixed domain + range values, that's exactly the
opposite of truth!
So, a bit confused about weird results I was getting, just wrote a simple
script to plot these charts for all basic d3 scales.
And, of course, once I saw a graph, it's fairly clear how that works.
Here, it's obvious that if you want to pick something that mildly favors higher
X values, you'd pick pow(2), and not sqrt.
Feel like such chart should be in the docs, but don't feel qualified enough to
add it, and maybe it's counter-intuitive just for me, as I don't dabble with
data visualizations much and/or might be too much of a visually inclined person.
In case someone needs the script to do the plotting (it's really trivial
Wanted to have some sort of "homepage with my fav stuff, arranged as I want to"
in firefox for a while, and finally got resolve to do something about it - just
finished a (first version of) script to generate the thing -
Default "grid of page screenshots" never worked for me, and while there are
other projects that do other layouts for different stuff, they just aren't
flexible enough to do whatever horrible thing I want.
In this particular case, I wanted to experiment with chaotic tag cloud of
bookmarks (so they won't ever be in the same place), relations graph for these
tags and random picks for "links to read" from backlog.
Result is a dynamic d3 + d3.layout.cloud (interactive example of this
layout) page without much style:
"Mark of Chaos" button in the corner can fly/re-pack tags around.
Clicking tag shows bookmarks tagged as such and fades all other tags out in
proportion to how they're related to the clicked one (i.e. how many links
share the tag with others).
Started using FF bookmarks again in a meaningful way only recently, so not much
stuff there yet, but it does seem to help a lot, especially with these handy
awesome bar tricks.
Not entirely sure how useful the cloud visualization or actually having a
homepage would be, but it's a fun experiment and a nice place to collect any
useful web-surfing-related stuff I might think of in the future.
Repo link: firefox-homepage-generator
is a simple and useful
tool to visualize disk space usage (a must-have thing in any admin's
Probably the best thing about it is that it's built on top of "du" command, so
if there's a problem with free space on a remote X-less server, just "ssh
user@host 'du -k' | xdiskusage" and in a few moments you'll get the idea
where the space has gone to.
Lately though I've had problems building fltk, and noticed that xdiskusage is
the only app that uses it on my system, so I just got rid of both, in hopes
that I'll be able to find some lite gtk replacement (don't have qt either).
Maybe I do suck at googling (or just giving up too early), but filelight
(kde util), baobab
(gnome util) and philesight
(ruby) are pretty much the only
alternatives I've found. First one drags in half of the kde, second one - half
of gnome, and I don't really need ruby in my system either.
And for what? xdiskusage seem to be totally sufficient and much easier to
interpret (apparently it's a lot easier to compare lengths than angles for me)
than stupid round graphs that filelight and it's ruby clone produce, plus it
looks like a no-brainer to write.
There are some CLI alternatives as well, but this task is definitely outside
of CLI domain.
So I wrote this tool. Real source is
actually coffeescript, here, JS is compiled from it.
Initially I wanted to do this in python, but then took a break to read some
reddit and blogs, which just happened to push me in the direction of a
web. Good thing they did, too, as it turned out to be simple and
straightforward to work with graphics there these days.
I didn't use (much-hyped) html5 canvas though, since svg seem to be much more
fitting in html world, plus it's much easier to make it interactive (titles,
events, changes, etc).
Aside from the intended stuff, tool also shows performance shortcomings in
firefox and opera browsers - they both are horribly slow on pasting large text
into textarea (or iframe with "design mode") and just slow on rendering
svg. Google chrome is fairly good at both tasks.
Not that I'll migrate all my firefox addons/settings and habits to chrome
anytime soon, but it's certainly something to think about.
Also, JS calculations can probably be made hundred-times faster by caching
size of the traversed subtrees (right now they're recalculated gozillion times
over, and that's basically all the work).
I was just too lazy to do it initially and textarea pasting is still a lot
slower than JS, so it doesn't seem to be a big deal, but guess I'll do that