Writing software, the wrong way

Monday, February 18, 2008

Dynamic Proxy Settings

There were three things I was planning on doing for the previous release that didn't get finished, and something extra that I didn't plan on doing and probably won't be done (priorities and such) but interesting to know that it exists.

  • Proxy Settings using group policy

  • Disable changing the proxy settings

  • Create some Javascript Wrappers around the XPCOM components for locating/reading registry keys


Proxy Settings using Group Policy
This was something that almost everyone that commented said was an important policy to them. I think I only once had to ever use a proxy (I wanted to watch a John Stewart clip from a website then wouldn't let me in, so I had to proxy to an American server to view it). Regardless, if it's the most popular request, I'll do what I can.
I have it working for http:// sites. Still need to make changes for the other protocols. Mossop also taught me a lesson that <preferences> requires a <prefwindow>. That's going to be a problem when you have to use <overlay>'s instead of a prefWindow, so I had to use an nsIPrefBranch instead. On the lighter side, I can refactor and finally have an excuse to use FUEL.

Disable changing the proxy settings
nsIPrefBranch supports locking preferences so that the user cannot change them in about:config or in the UI (it will grey out the settings).

Unfortunately, you can only lock the default value. Which kinda sucks at the moment. The other two alternatives is to make the option of changing your proxy greyed out or hidden. IE7 has it's own tab for connection which completely disappears with the right policy enabled. Since Firefox's proxy settings is located in the same UI tab as offline storage, it is probably best for us to disable the button. To avoid allowing people to change the settings via about:config, we would have a policy to disable about:config access (get back to me on this, I don't have an answer on how we can do that yet).

Javascript Wrappers around the XPCOM components for locating/reading registry keys
I started doing some work on doing some JS wrappers around registry keys, since I dislike the current implementation to a certain degree. I won't go into details, because it's more of a preference then anything else.

I'll end with an amusing quotation.
And _please_ file bugs when you hit problems like this. I flunked long-distance widebeam telepathy in college, so I'm no good at just guessing that you're running into problems...
-- Boris Zbarsky

No comments: