user.js ... all hat, no cattle?
Joe Koenig <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.prefs |
|---|---|
| Message-ID | <[email protected]> |
user_pref("dom.disable_window_status_change", true);
conflicts with many sites. e.g:
http://www.alltheweb.com/search?q=foo
user_pref("browser.toolbars.showbutton.print", false);
user_pref("browser.toolbars.showbutton.search", false);
didn't work, either. They did un-check the checkboxes in the
preferences dialogue, but didn't remove the buttons from the toolbar,
though. I had to: open the gui-dialogue, tick the checkboxes, save,
reenter the dialogue, untick them again, save.
user_pref("plugin.display_plugin_downloader_dialog", false);
didn't work, either. I had to delete libnullplugin.so manually.
user_pref("browser.turbo.singleProfileOnly", true);
user_pref("profile.manage_only_at_launch", true);
were rendered useless when launching a new instance with command line
parameters. Be it
mozilla -height 100 -width 100
or simply
mozilla -foobar_noneffective
Are these prefs actually supposed to work, or is this just a some fake
act of courtesy?
Didn't mean to whinge (well, at least not too much). I'd just like to
know: why is it so hard to _disable_ a /feature/? Is it maybe because it
took the developer a couple of hours, days or weeks to implement a
feature that now he's so reluctant to give the user the possibility to
/ignore/ his masterpiece?
What's the use of a config file if the user has to check whether his
settings have been applied correctly. How'd you react if your
mailserver would simply ignore his config file? What would you say if
"make" would make up it's own rules, instead of parsing your Makefile?
It doesn't end there, of course. Mozilla's reluctance to adhere
~/.Xdefaults resp. ~/.Xresources is well know, too. How come, that
every upcoming toolkit/app seems to consider itself to be "equipped
with special rights" or maybe even "bound to establish new standards"?
Why don't they fscking obey to the user's orders?
Mozilla 1.5
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016