hoodwink.d enhanced
RSS
2.0
XHTML
1.0

RedHanded

Just a Few MouseHole Tips #

by why in inspect

If you’re hesistant to use mouseHole since you think you’ll need to commit to using a proxy all the time, consider the following:

  1. ProxyButton, a plugin for Firefox which adds a button to your toolbar. The button turns proxying on and off. Just like the Greasemonkey monkey face. (Or SwitchProxy if you have several proxies.)
  2. Even when you aren’t using it as a proxy, you can still access mounted user scripts by hitting http://localhost:37004/.
  3. Your settings are persistent and are stored in a folder under your user account. Run MouseHole at your convenience, your scripts and preferences will always be there.
    • $HOME/Application Data/MouseHole on Windows.
    • ~/.mouseHole on OSX/Linux/BSD.
  4. And, for the highly timid, here’s ProxyLike, a mouseHole user script which lets you pass stuff to the proxy on the URL:
    • http://localhost:37004/http://boingboing.net
    • http://localhost:37004/http://hoodwink.d/onslaught/

Thanks to flgr for the bright idea on ProxyLike!

said on 03 Sep 2005 at 00:49

I’d like to use MouseHole for hoodwinking, except (at least when I tried the initial version) it’s really slow. Maybe I should go ahead with my idea to write a GreaseMonkey equivalent for Safari… (the problem is I don’t really have the time for it :/ )

said on 03 Sep 2005 at 01:36

I have the same problem with speed, especially once NewsFire starts grabbing all my feeds through mouseHole. ProxyLike is a nice trick for now. I made a “mouseHole’d” bookmark pointing to “javascript:location.href=’http://localhost:37004/’+escape(location.href)”.

said on 03 Sep 2005 at 02:14

Hrm, do news aggregators use the Web Proxy? That’s not gonna be fun when NetNewsWire updates while I’m using MouseHole.

As a suggestion to others, the way I’m using MouseHole is I duplicated my Home location and named the new location MouseHole and turned on the HTTP proxy, so I can just flip locations if I want to start using MouseHole.

Hrm… now I need to come up with a fiendish MouseHole script to write…

said on 03 Sep 2005 at 10:54

Hey _why, I was thinking of writing a Safari plugin that basically integrated MouseHole into Safari, so it’s nice and fast (and doesn’t interfere with NetNewsWire).

A nice benefit of this is then I could add communication between JavaScript and MouseHole scripts and make scripts that add nice JavaScript tricks (like aggregating info from other sites with AJAX instead of doing it all in pre-processing of the page, because pre-processing holds up display of the page whereas AJAX doesn’t). Of course then this wouldn’t be supported cross-browser…

Anyhoo, I really would like to run MouseHole in Safari alone, and have it fast, hence the MouseHole Safari plugin idea. Any thoughts?

said on 03 Sep 2005 at 11:41

Hrm, I just realized, JS scripts can probably communicate with MouseHole already by simply accessing some non-existant resource on the current page’s domain (because of security restrictions) and having the MouseHole script rewrite that non-existant resource to do what it wants (assuming you can write non-existant resources – I haven’t looked into that yet).

said on 03 Sep 2005 at 12:56

What’s the main speed bump for MouseHole? Is it Webrick itself or somewhere else?

If it’s Webrick, couldn’t we create a C extension such that if it were present the C implementations for certain speed-critical methods would be called instead of Webrick’s? Seems doable, just wondering if anyone has done any profiling? It could be that writing only a handful of methods in C would result in a big speed increase.

said on 03 Sep 2005 at 14:26

Ok, turns out MouseHole scripts can’t intercept requests for non-existant resources. The only way this could be done is to request an existing text/html resource on the page’s domain and to rewrite that with MouseHole. I’m planning on hacking MouseHole to add the request interception stuff so I can do it with a non-existant resource (because that’s much cleaner).

said on 03 Sep 2005 at 18:20

Making a MouseHole network location is a great idea.

Continuing on with my half-assed hoodwink’ry, I’ve made a script to rewrite hoodwink.d links for ProxyLike. It’s mostly useful for the Onslaught.

The MouseHole URI is hardcoded right now. Is there a way to get the pre-ProxyLiked URI ? Or test if ProxyLike is installed?

said on 04 Sep 2005 at 00:39

Kevin: why and I did that for hoodlum.rb actually. Since mouseHole is based on that, it’s not hard to add back in…

said on 04 Sep 2005 at 12:51

:{ (with conical adornment): WEBrick really isn’t much of a bottleneck. At least, when I’m browsing on sites which aren’t interacting with user scripts, WEBrick comes back in a fraction of a second.

The slowness is htree → rexml → html. There’s still plenty of work that can be done speeding this up. It’s totally inefficient right now.

said on 05 Sep 2005 at 10:20

Got the source version to work in XP, but on Windows98 both the installer and the source version blow up too quickly for me to see why they went BANG ! Do they leave any logs anywhere, or do you have to configure that once it works?

Also, from XP, I couldn’t read any of the help information about hoodwink.d before registering, which seems a little too defensive? At least I was seeing the site though, so I could tell MouseHole was working….

Thanks.

said on 07 Sep 2005 at 16:05

Did MouseHole wreck Apple’s Software Update for anyone? I couldn’t upgrade iTunes while proxied to the script. Works without it though.

said on 07 Sep 2005 at 21:31

Yeah, if I had Apple the first thing I would do is figure that deal out for you.

said on 10 Sep 2005 at 01:37

I’m actually trying to figure out if I can write a plugin for Safari that makes it use MouseHole without setting MouseHole as a global web proxy. Unfortunately there’s no exposed API for setting a proxy on URL loads in Cocoa (don’t ask me why not).

Oh, and as for the slowness, I’ve decided that it’s all hoodwink’s fault. After all, it forces every single page load to go through the htree/tidy conversion and also requires pinging hoodwink each time.

Perhaps (assuming my register_url patch gets accepted) a new hoodwink script needs to be written that does things the Greasemonkey way and just embeds JavaScript that pings hoodwink and modifies the page dynamically? That way it loads fast and if you don’t care about hoodwink for that particular page you don’t have to wait for it to load.

Comments are closed for this entry.