A long-standing problem will not be replicated in the OPML Editor

The problem is very adequately explained on The Tweezer's Edge, it's been in Radio and Frontier probably since 1998, maybe even before.

Basically, as Radio is starting up, it smashes the value of user.webBrowser.winDefaultBrowserApp. I don't think this was the right thing for Radio to do, especially since Radio is so intimately connected with the web browser. It's actually less of an issue for the OPML Editor because it's more of an outliner than a browser-based app. But we've already gotten burned by this, and it's likely to be a major support headache, much as it was with Radio, so let's change the behavior in the OPML Editor.

The rule for all user.xxx data is that the system is allowed to initialize it (in fact it's expected to) but then it's hands-off. The data belongs to the user. startup.startupScript violates this rule by setting winDefaultBrowserApp every time the app starts up.

The change I've made sets it once, the first time the OPML Editor launches. If it exists, it leaves it alone.

# Posted by Dave Winer on 7/24/05; 3:39:14 PM - --