Generally, as I go through a beta, I change little or nothing from the way it installs itself. As I work my way through each component = be they proxies, favicons, middle click, or whatever, I keep a chart of where I started and what I found. Again, look for yourself - under Tools-Mouse Accelerators there are three choices other than Default. It was easy enough for me to find out how this was set originally. All I had to do was unzip the original .7z file. Cranked up the new 1.5b2 and it was defaulted to Firefox 2.0. Apparently, it was left in that state when it was zipped.
Thanks for your thorough testing, Terry. That's important and helps us a lot. But in this case, well, Firefox 2.0 is simply not my default setting and I can't reproduce that. The pref that stores what mouse accel config is used doesn't exist by default, meaning that the Default configuration is used when a new profile is created. Have you created a new profile? In other words, have you deleted the old profile under %AppData% or have you created a profile.ini for the new installation? Otherwise the Firefox 2.0 setting may be a legacy of your old profile...
As to the need for user agents. In the past I have given you pages that show when you use the default for K-M or Seamonkey certain pages won't show. Here's an example: [www6.comcast.net] Since, today, Firefox is ubiquitous, setting the browser to it will get you into a number of sites. Go to that site and try it with the Firefox string and you will get in. Same goes for an IE string. Sure IE won't fool WindowsUpdate, but it will get you into a lot of pages without getting the message that you need to update your browser.
I know that, Terry. But it is a simple fact that not all browsers are technically compatible. You cannot simply use a browser with the UA string of some other browser expecting that this will do any good (Gecko is Gecko
, but MSIE and Opera are not). Facing your comment in regard to WindowsUpdate, you seem to know that. But many users don't. When they find a website not working that previously worked in IE, they make K-Meleon identify itself as IE and expect the site working in K-Meleon. This may indeed work in many cases, but in as many other cases (like WindowsUpdate) it does not because K-Meleon fails to run proprietary Microsoft JScript - like any other browser apart from IE. Now, what do users do when a feature is not working as expected? They write bug reports! And then somebody has to spend time on investigating these reports - for nothing and nothing again, finally, since this kind of bugs are no K-Meleon bugs. Such bug reports are a complete waste of time for both the reporters and the investigators. For an individual reporter it's only a couple of minutes. But for the investigators it's much more time, it sums up to hours. Hours that are spent on something totally useless! Zero result.
Well, I cannot blame users for not knowing something, but I feel the need to do something when I'm getting the impression that a certain feature (or choice) is causing more problems than it is able to solve. In this case, less choice is a better choice - an option that doesn't exist doesn't cause trouble.
Under the Mouse Accelerators you have three choices other than default. In essence, as far as the middle button goes, default brings up pages into the foreground and the other three choices bring up pages in the background. So, why do you need three choices that do the same thing? Since you are using Ockham's razor to get rid of Agent strings why not use it on the Mouse Accelerators? Call one foreground and one background?
As you can see in the FAQ
(well, Opera is new in 1.5 and still missing), these mouse accel configs set more than just one accel. K-Meleon is often used as a supplementary browser (in addition to others). This feature is meant as a help for users who are using (or used) another browser in the first place and who are accustomed to a certain way of opening links with the mouse. This feature will allow them dealing with links in K-Meleon as they are used to that from other browsers.
In the contrary to user agent strings, this feature, as well as most others, doesn't cause us any trouble and more choice is helping more (for now, but that doesn't mean that Ockham's razor won't be applied at a later time). I guess the difference is that users usually don't play around with features when they don't understand their purpose - or they ask how it is used, but they usually don't write bug reports. This is different for user agent strings. Many users have heard about that and think that they know everything about it. In fact, most of them don't and they have wrong expectations. And that's the problem. I don't like to limit your freedom of choice - in fact, I don't do that, you just have to get your own hands dirty. But your freedom of choice is not for free. Others have to pay the bill. The time that I have to spend on updating the user agent strings and on investigating bug reports is lost for other things, lost for real improvements of other features that are more important to most users than user agent strings. At least that's how I see it.