Re: user.js ... all hat, no cattle?

Clover <[email protected]> wrote:
> Joe Koenig wrote:
>> user_pref("dom.disable_window_status_change", true);
>> conflicts with many sites. e.g:
>> http://www.alltheweb.com/search?q=foo
>
> Those sites should use "title" attribute. The reason the pref is there 
> is because status text change is usually not user-friendly. If you don't 
> like it, then don't set it. It is off by default.

Huh?  I want to use this pref, but it doesn't do what it's supposed to
do.  IOW: It doesn't work.  Look, it should, as you've already stated
correctly, _prevent_ sites from changing the text in the statusbar, but
it doesn't.  That's the whole point of my posting.  These prefs are not
working.



>> user_pref("browser.toolbars.showbutton.print", false);
>> user_pref("browser.toolbars.showbutton.search", false);
>> 
>> didn't work, either.
>
> Chrome settings are saved in localstore.rdf. Button visibilities only 
> change when you set them via UI.

Could you please explain to me the relevance of the internal handling of
the prefs?  Why should the user care how these settings are being
applied?

Look:  These prefs /are/ being read, the corresponding checkboxes in the
UI /are/ being unticked.  Still, Mozilla doesn't remove the buttons from
the toolbar.  Still, it's possible to toggle these buttons on/off at
_runtime_ through the UI.

How could I /ever/ know, whether a pref is actually applied correctly?
Even if I restart Mozilla several times, the buttons are still there,
although the corresponding checkboxes have been unticked long ago.  See
my point?  How should I verify the functionality of these prefs?  I
guess I'd have to test each pref under realistic conditions, to see
whether it actually works or not.

Presumably there's a deep going technlogical reason, which is just too
sophisticated for me to grasp.


>> user_pref("browser.turbo.singleProfileOnly", true);
>> user_pref("profile.manage_only_at_launch", true);
[...]
> You need to use -remote command.

 $ mozilla -h
   -remote <command>       Execute <command> in an already running

That's not want I wanted to do.  I want to open a new instance of
Mozilla.  I can do this either with <CTRL-N> or type 

 $ mozilla &

at the command prompt.  But I can not pass any command line parameters
to this instance, because Mozilla will, for some reason beyond my
comprehension, assume that I want to start this new instance under a
different profile.  I tried to avoid this behaviour by setting the
aforementioned prefs.  As one might have guessed, these prefs don't
work.


>> Are these prefs actually supposed to work, or is this just a some fake
>> act of courtesy?  
>
> The prefs you mentioned are hidden preferences.

Well, I managed to find them ;-)  
Jokes asaide: Beg your pardon?

>> I'd just like to know: why is it so hard to _disable_ a /feature/?
>
> Documentation problem. There are 600+ prefs and documentating 'em all is 
> no trivial stuff.

It has nothing to do with documentation.  It should be perfectly clear
what the purpose of
user_pref("browser.toolbars.showbutton.print", false);
is, without any documentation.  The problem is: this pref no workie.

See what I mean?  This nice print-button can be considered a feature.
However I cannot disable it through my user.js file, _although_ the file
is read and _although_ the corresponding checkbox in the UI dialogue is
unticked.  The only reason I took notice of this malpractice was that
the button was still there, visible for me.

Considering this, the whole benefit of "user.js" is rendered useless,
because I'll have to check manually which prefs have been applied
correctly.  How about my settings regarding Privacy, Security,
JavaScript ... and so on.  Have any of these prefs been applied
correctly?  I don't know, have no idea.  I can't SEE these things
(verify them visually) like I saw the print-button, which was there
although he shouldn't have been.  I'll have to examine it manually.
That's annoying.



> dunno what ~/.X***** are.

These are resource files for X11 (the window system for unix/linux),
where you can specify default properties for various applications. E.g.:
AppName*geometry: 500x400+0+0
This would make the application AppName start up with a size of 500x400
at the upper left corner of the screen.  Guess what: Mozilla doesn't
play along here, neither.