Here’s my modified version of the script:

// ==UserScript==
// @name           Open Links in Same Tab/Window
// @description    Prevents websites from forcing links to open in new tabs or windows.
// @version        0.1
// ==/UserScript==

var a = document.getElementsByTagName("a");
for( i=0; i < a.length; i++ )
  if( a[i].target == "_blank" )
    a[i].target = "_self";

There are half a dozen popular solutions to this, but I wasn’t completely happy with any of them on their own, so I’m experimenting with using a combination of  Ethan Marcotte’s max-width technique and a modified version of Keith Clark’s cookie technique. The cookie technique can be used to determine the size of a user’s screen before outputting the filename, so you can serve a low-res version to mobile devices and a high-res version to desktops. You can add the max-width technique on top of that to handle any situations where the image still doesn’t fit right.

My modification to Keith’s technique is that instead of setting the image’s src tag to call a PHP file which outputs the respective image’s contents, I just have the function determine the path of the appropriate image. That avoids the faux URL and any caching issues. The image quality will still degrade when it has to scale, but serving multiple images minimizes the number of times that occurs. The major downside is that the it only takes effect after the first page load. But, given the lack of a proper solution, I think that’s an acceptable compromise.

Update: I’m now also considering adding a third layer to help minimize the cases where the first load would include the large images. The browser doesn’t send the screen width with the HTTP request, but it does send a user agent string. The code could parse out the agent and default to the small images for known mobile browsers. On it’s own user agent detection is insufficient, but it may be useful as one of many layers. There could be issues with unreliable (or intentionally false) agent disclosures, and also with different devices using the same agent even though they have different screen capabilities, so it’ll have to be tested out thoroughly, but I think it’s worth a shot.

It turned out that I had accidentally loaded the site via one of it’s domain aliases when I came back to it instead of using the domain that WordPress is configured with. I’m guessing that triggered the same origin policy and Firefox blocked the response.