Firefox right-click menu offset

I hit this on a Firefox upgrade sometime ago: the context menu (i.e., the “right-click” menu) would be placed right under my mouse cursor, so if I wanted to click, release, and then select my menu option, the menu option that happened to be in the top-left corner of the menu would be activated when I released the right-mouse button (currently, that’s a navigation to the previous page in history). Very annoying. I lost track of the Q&A post that led me to the solution, but basically it’s to add the following to ~/.mozilla/firefox/<your_profile_directory>/chrome/userChrome.ccs:

#contentAreaContextMenu{ margin: 10px 0 0 10px }

Restart Firefox after changing that file and now your context menus will be nicely offset from the cursor location. Ah. So much better.

A Mozilla resource on this CCS class and others:

I’ve spent my free time the last several days obsessively watching television. I’ve never understood how people could watch TV while also doing something else because when I watch, it is the thing I’m doing. I look at myself and ask “Is everyone like this or just me?” I don’t mean that in a, “There must be something special about me,” sort of way: it’s just that I mostly cruised through psychology class, and, having a deeply introverted personality, I really don’t know what’s up with other people. So, after I finish watching about 4 hours of television almost continuously, I just wonder if that is normal.

I decided to watch television these past days because work has been somewhat draining. The volunteer work on open source software that I usually do felt like a chore for me to work on. Watching TV was meant to be relaxing. It was not. Rather, it was like a vacuum that pulled in all of my energy and attention, distracting me from important things like cooking proper meals or doing laundry. It required that I spend even more time sitting when my life is already quite sedentary. On top of that, whenever I pull myself away, and I am reminded of useful work that I’m not doing, it is easier for me to avoid the uncomfortable thought by watching more television than by doing the work.

To address this problem, some of my habits will be changing. When I was younger, I removed the TV from my room completely because I had a similar problem, but I’ve let that same situation re-occur. A Wii with the Netflix app on it has been removed from my room — I spent more time watching that then anything else. I will also try to get back into the habit of regular workouts three days a week. Soon, I’ll find a healthy balance again.

Python’s for/else construct

I’ve been a Python program for a few years now, but I’ve only just encountered the ‘for/else’ construct. I was changing a conditional to a for loop, but accidentally left behind the else block. My initial reaction after looking back at the code was, “Oh, the else must run if the ‘for’ block never executes,” because that would actually make sense. That’s not what it does though, I thought, because the code in the ‘for’ does execute. I wrote some test code, just be sure I’m not crazy:

def test(l):
    for x in l:
test([1, 2])
# else
# 1
# 2
# else 

And lo, both blocks execute — the loop body and the else block. At this point, I took to the interwebs, and, naturally, someone has described this bizarre python behavior. The else will not execute if you break before the iterator is exhausted. Even knowing this construct exists and knowing I’ve been is situations where it would be usable, I don’t think I would use it. Considering that I introduce loops on many occasions where before I was checking for None, an ‘else: …’ like that in the code above would always initially look like a programming error, and I’d have to spend precious seconds of my time unpacking the intent of that code.

I’m not the first to express surprise at the behavior of this feature of Python, and one helpful redditor linked to one of Raymond Hettinger‘s[1] lecture videos which gives historical context for why the construct exists and why it’s named the way it is. The explanation is cogent and helps me to see for/else less as a misfeature and more as an unfortunately named, but effective construct, much like the ‘try/else’ which I had encountered in some FOSS code about a year back.

1: Fun fact: Raymond Hettinger also wrote my favorite and most-referred-to Python article on the super() construct. It helped open up my thinking on mix-in types, which I now use readily to graft functionality onto my Python objects and classes.