Talk:About:config entries

From MozillaZine Knowledge Base
Revision as of 21:53, 28 August 2010 by Dmcritchie (talk | contribs) (Groups of related references)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Is there an entry for ...

Disabling the annoying image placeholder icon?

I don't mind seeing ALT text, but the page/red-circle thing is highly distracting. I've tried browser.display.show_image_placeholders = false which seems to work -- but from the name I'd assume that it really doesn't do anything more than expand the image bounding box as it's downloaded. At least that was my theory; in actuality it seems to merely disable the icon and alt text (although it could be that I've only browsed sites which specified WIDTH and HEIGHT since).

  • What about:config entry disables the placeholder icons ONLY (or with the fewest "sideffects")?
  • What does browser.display.show_image_placeholders really do?

--Eibwen 04:52, 19 April 2006 (UTC)

You might try setting browser.display.force_inline_alttext to true. Also, I believe AdBlock replaces the image placeholder image with a red diamond -- you might want to disable AdBlock temporarily to see if that causes the effect you're describing. (The mozillaZine forums are probably a more appropriate venue for these types of questions.)--Unarmed 03:36, 20 April 2006 (UTC)


Disabling the confirmation dialog You are about to login to the site "<uri>" as the user <user>. ?

--Eibwen 06:58, 17 March 2006 (UTC)

Yes, see network.http.phishy-userpass-length. --Unarmed 23:18, 17 March 2006 (UTC)

* Convention

What is the * for on many of the headings and entries? Also, would it look better if the prefs were left-justified (=left-aligned)? --Mozcerize

The * has been used as a wildcard to indicate anything, e.g. "Browser.*" would be "any entry that begins with browser." It was just the convention on the page, though probably not strictly necessary. The prefs would look better left-aligned, though Wiki turns them all into <th> cells and they're centered instead. --Unarmed 07:41, 27 Feb 2005 (PST)

Ah, yes it's clear now; I didn't see the "." so I thought the headings were "Accessibility*" not "Accessibility.*". --Mozcerize

Default values

To anyone editing this page: Please keep in mind that the specified "Default value" for each preference is not the "recommended" or "tweaked" value. It is the value that is specified when you install the browser.

Line breaking

Rather than putting in spaces in the config names, why not use the &zwnj; Unicode character for a non-joining zero-width character? :-) PhilHibbs

It gives inconsistent rendering results in Firefox. In Windows, at least, it displays only as a thin black bar and does not give wbr-equivalent behavior --Unarmed 06:40, 18 Apr 2005 (PDT)

Why do we use spaces between the config. names anyway? It's rather non-user-friendly to have to edit out the spaces when copying and pasting a name of a preference.

The longer preference names will cause the table they're in to extend past the edge of the page, requiring horizontal scrolling. --Unarmed 11:14, 25 Jun 2005 (PDT)
Can we please re-assess the pros and cons of using spaces for 2009? What's the largest firefox default config option name? 80 characters? I think is an affordable width for 99% of the users. And, meanwhile, we are hindering everybody wanting to do a ctrl+f for an option. --another_sam 15:21, 20 Jul 2009 (UTC+2)
The longest user set preference name in my SeaMonkey prefs.js is extensions.irc.networks.irc-opensuse-org.channels.%23suse.conference.enabled (76 characters). I agree that I haven't checked all the defaults OT1H, and that even though that's a pref for an extension (ChatZilla) distributed with SeaMonkey, this name won't appear on this page OTOH. However, just scrolling the page shows many names split to more two or even three lines even on a maximized window. If longer (unsplit) names were to widen the first column of the table, the last (description) column would be made narrower by that much, or perhaps pushed off the screen, and that wouldn't be nice. What's the problem with adding a space after every dot in names, for display purposes only? It's clearly mentioned atop the page (in the last paragraph above the table of contents), and once you know it, it's not much of a hardship IMHO. — Tony 14:13, 20 July 2009 (UTC)

There has also been recent forum discussion on using the wbr tag. This tag works perfectly fine in a standard page, and would need to be enabled on the kb before it could be used.

Example: the text "accessibility. typeaheadfind. enablesound" could be changed to "accessibility.typeaheadfind.enablesound" - Racer 21 Dec 2006
kerz would be the one to petition for this. I believe he watches the wiki thread in the MozillaZine Site forum. --Unarmed 04:32, 22 December 2005 (UTC)
uuurgh! WBR is non-standard ;-) And it would be unneccessary if only Gecko sorted out its support for the various Unicode linebreak characters. Both options are hacks though, since the author shouldn't have to worry about how the user agent decides to apply linebreaking. What's really needed is for Gecko to have sensible linebreaking for URLs and similar (much as the "url" package in LaTeX does). Happily, there's been a lot of recent activity on Bug 255990 - Characters below U+0100 are not subject to line-breaking rules at all. --Mozcerize 09:16, 17 March 2006 (UTC)

Missing entries

I am particularily interested in the missing entries for java.* entries of which are present on my browser's options, but that I can't find documentation on. For I seek to use them if possible to change configurations for my Java plugin in firefox.

Thunderbirds about:config entries

Is it possible that there is no description of Thunderbirds about:config entries on mozillaZine. Or didn't I find them. I'm looking for a description of the ldap*.*- and mail.*- entries. --BeCo 10:41, 14 December 2005 (UTC)

There aren't many on this listing, no. I don't use Thunderbird myself, but of course others are free to document the settings and add them to the page. --Unarmed 15:39, 14 December 2005 (UTC)
Someone also asked for mail-related about:config entries in this thread. Unfortunately I don't knowledge about them since I don't use any mail clients. --LouCypher ☎ 15:02, 6 August 2006 (UTC)
See Mail and news settings . Its not complete yet (doesn't have anything for ldap for example) but should be useful. It also includes some settings added by Shredder (the upcoming Thunderbird 3 release) and some popular add-ons. Tanstaafl 16:53, 20 July 2009 (UTC)

plugin.disable_full_page_plugin_for_types

I added the preference since it was missing from the list. See the discussion here. Alice Wyman 20:30, 20 August 2006 (UTC)

Split article

This article is huge. I think we should split it. --LouCypher ☎ 21:43, 21 Aug 2005 (PDT)

By branch? Or did you have something else in mind? ... Even though it's huge, it is fairly convenient to be able to search the entire list in one go. --Unarmed 12:54, 22 Aug 2005 (PDT)
I think we can split the content between a few pages, like "about:config entries (A-N)", then create a "long list of about:config entries", which would include the smaller pages (using {{:page name}}). --asqueella 05:19, 19 September 2005 (PDT)
Yes, by branch. We can make a new Category:about:config entries to each split article and a template to link to other branch. The only problem is how to name the article because we can use * to an article name. Any more idea? --LouCypher ☎
I'm beginning work on an article-per-preference scheme. That'll give us Category:Preferences as an automatic index, leaving this article free to be organized however. I tend to agree with asqueella's suggestion, but I'm not dead-set on any particular idea. --Unarmed 19:11, 17 October 2005 (PDT)

Merge with about:config

I don't really see the need to have this article and the about:config article. We should merge them.--Np 21:08, 26 August 2005 (PDT)

I disagree; I think 1) the average user looking at this article already knows how to use about:config, 2) we don't need a longer article, 3) it's convenient to point people to a brief unintimidating article about how to use about:config, 4) having this list in an article named "About:config" would encourage even more edits of the settings in the mistaken belief that this Wiki article is about:config. --Unarmed 21:41, 26 August 2005 (PDT)
I'm concerned with the amount of users (me included) who find an article called about:config but don't find this article because all there is is a buried link. Maybe I'll just make the link to this article on that article much more prominent.--Np 09:14, 29 August 2005 (PDT)

Replacing entries with link to Category:Preferences

Should we do that for branches that have been completely transferred?--Np 03:45, 3 December 2005 (UTC)

I wouldn't be opposed to that, but I'd like to hear everyone's opinions. --Unarmed 20:23, 5 December 2005 (UTC)
Well it looks like no one has an opinion on this except you and me. I say we do it to eliminate duplicate information. I've also noticed that some of the entries on this page are wrong or misleading because they require a lot more space to explain. The only downside I can see is it will prevent people from searching this page, but they can't really do that anyway with the spaces in the pref names.--Np 17:34, 13 December 2005 (UTC)
For searching, I more often search for keywords in the descriptions. Perhaps the best approach would be to link to Category:Preferences in each branch, and add a bit of text describing the most-used prefs' effects. E.g., "The accessibility branch of preferences allows you to modify Find As You Type behavior, change how the [Tab] key works in web pages and XUL, turn on caret browsing, and tweak other accessibility-related features." That would give us a good summary that wouldn't easily go out of date, and if every pref is article-ified eventually, the page will still have somewhat of a purpose. --Unarmed 23:36, 13 December 2005 (UTC)
I think removing content from this page is a mistake, mainly for the reason Unarmed listed. (Also the category listing doesn't display all the entries by default, which is an additional inconvenience for the user.)
What's worse though, is that this page tricks the user (I fell for it) into thinking that it has the complete listing of prefs, when if fact some preferences are moved into the category. During the (really lengthy) process of migration, there's no single listing of all prefs the user can search through.
If you have a recent enough version of mediawiki, you can try using <includeonly> and <noinclude> to simplify maintenance while including the most important part of pref descriptions on this page.
Sorry for noticing this thread only half a year later. --asqueella 18:33, 16 July 2006 (UTC)
Just being a user I never saw question, and if all took was another rhetorical question to put everything back, I'd sure be in favor of it all being put back together again, the spaces never bothered me as it is easy enough to modify a find or just use part of a preference name, the same as using about:config itself. The separation of articles makes it a lot more difficult to work with and makes it harder to reference things in helping others, once you do have the solutions. DMcRitchie 15:58, 30 December 2007 (UTC)

The preferences need to be brought back here

In October 2005, a large number of preferences were migrated into categories [Category:Preferences] and removed from this document. This dramatically increases the difficulty that new users face when trying to find out what preferences to set the adjust browser or mailreader behavior.

Note that most new users won't even know in what category to search. The preferences that were removed need to be put back. I want to do this soon.--Mumia-w-18 04:27, 28 June 2008 (UTC)

(Mumia-w-18, I moved your comment here, since it is part of the same discussion.) I've edited the intro to make it clearer that this article is not a complete listing. As far as bringing back or adding entries for all preference articles that are now included in Category:Preferences, I don't think that's practical. This article is way already too long to add entries for all of the currently documented preference articles. See the #Split article discussion for some background. It would also mean duplicate work, since each new preference article would have to be summarized for a new entry for this article. Many new preference articles have been added since the January 2006 migration, that were never part of this article to begin with. Alice 12:18, 2 July 2008 (UTC)
Yes it seems the combined article would be largish. I copied the source onto my local machine's wiki, and it's big enough to cause some problems. I'm still (slowly) thinking about possible solutions to the confusion created by splitting the article.--Mumia-w-18 04:44, 2 August 2008 (UTC)

Porting the Preferential listing

THe author of the Preferential extension has given permission for us to port over the large listing of preferences he has collected at http://preferential.mozdev.org/preferences.html . Would anyone mind my starting a large page with this data until the contents could be all ported over into the respective file(s)? thanks... Brettz9 17:12, 16 January 2006 (UTC) Or has someone been tracking the contents (or covers it all) anyways?

I don't see why not. Just remember, if you're adding this information, a) we're moving every preference into its own article in Category:Preferences and (eventually) retiring this article, b) make sure the info is correct and complete before using it.
Where was the decision to retire this article made/discussed? I find it much easier to find the relevant setting when I only have a rough idea of what setting I'm looking for by searching this article than a category. Never mind that the third column listing is trashed if you use Firefox (due to it being overwritten by the three boxs to the right). Tanstaafl 17:03, 20 July 2009 (UTC)
That thrashing is skin-related anyway. When I'm logged-in, my favourite skin is "CologneBlue" with floating sidebar on the left, and there is no thrashing of anything on the right side. — Tony 17:10, 20 July 2009 (UTC)
I'm not using a skin. I assume you're talking about a GreaseMonkey script. Tanstaafl 19:00, 20 July 2009 (UTC)
No, I'm talking about the skins selectable in your wiki preferences. The default skin is called Monobook but that's not the one I'm using. — Tony 19:54, 20 July 2009 (UTC)
Thanks. I switched to it. Tanstaafl 21:50, 20 July 2009 (UTC)

The UI references (are for Firefox 1.0.x)

The UI references like Note: In Firefox, this can be changed via "Tools → Options → General → Fonts & Colors → Unvisited Links". for browser. anchor_color are wrong for Firefox 1.5.x as the UI has been changed. --FatJohn 09:24, 12 February 2006 (UTC)

That one also needs fixing in the linked browser.anchor_color article). If you are asking if both the Firefox 1.5 and 1.0.x UI should be noted, I would probably include both since many people still use 1.0.x but that's just my opinion. If you're asking whether someone should go through all the preferences and update for Firefox 1.5..... that's a tall order but in the meantime if you find something that needs fixing why not fix it? Alice Wyman 23:24, 12 February 2006 (UTC)
I fixed it for browser. anchor_color Alice Wyman 17:15, 13 February 2006 (UTC)

Indeed, will do! :) Just wanted to make this issue known first. Edited a few. Damn this article is nasty to edit because it's so long... And nasty to search because of the syntax of the names of the keys (browser.anchor_color → browser. anchor_color) --FatJohn 01:37, 14 February 2006 (UTC)

Sessionstore prefs

Just a heads-up that some prefs for the new sessionstore component were added in bug 328159. They can be found by inspecting http://lxr.mozilla.org/seamonkey/source/browser/components/sessionstore/src/nsSessionStore.js --asqueella 14:59, 10 May 2006 (UTC)

http://wiki.mozilla.org/Session_Restore#Preferences --asqueella 21:32, 11 May 2006 (UTC)
Looks like they have been added:

Automigration

Uhm, what's "automigration" the article refers to? Ah, google suggests "Support for Importing Settings from Other Browsers". Maybe somebody has a good link to put to the article when the word is used. --FatJohn 21:12, 23 September 2006 (UTC)

I found http://www.mozilla.org/projects/firefox/ue/migration/ and this forum post which includes a bunch of information and links, and https://bugzilla.mozilla.org/show_bug.cgi?id=286557 if that helps. Alice Wyman 15:16, 27 September 2006 (UTC)

Updating for Firefox 2

...From a forum post by dickvl dated Fri 22nd Dec 2006:

I had a quick look through the about:config article and it looks that more prefs need to be updated for newer Fx versions.

There seem to be more prefs that reference Fx 1.0.x and Fx 1.5 options as Firefox (without a version number). I will ask some advice on what the policy is (?is Firefox alone Firefox 2.0?) and maybe do the changes myself if I have some time left.

I did one update for security.enable_ssl2 since the default has changed AND the UI option was removed in Firefox 2. I also added the "update" template to this article, as discussed recently here. Alice Wyman 20:17, 23 December 2006 (UTC)

The article looks pretty good now, as far as being updated for Firefox 2. If no one finds anything else that needs updating I'll go ahead and remove the update template. Alice 23:43, 31 October 2007 (UTC)

intl. locale. matchOS description is ambiguous

Said description:

  • Determines how to decide locale
  • True: Use the locale the OS is using
  • False (default): Opposite of the above

So False is either "Use the locale the OS is NOT using", indicating there are only two locales available (probably not intended), or "DO NOT use the locale the OS is using" (Do use anything but?) (also not intended, I'm guessing).

I assume the pref is about OS overriding user choice or vice versa, but I don't really know. I was just passing by.

bomfog 15:50, 27 September 2007 (UTC)

main article name changed

It appears to me that the main article name got changed from http://kb.mozillazine.org/About:config_entries to http://kb.mozillazine.org/About:config_Entries it obviously has not changed the current page -- Talk:about:config entries page. DMcRitchie 00:52, 29 December 2007 (UTC)

The latter (with Entries capitalized) is a redirect to the former (with entries in lower case), so the main article name did not get changed AFAICT. -- Tony 01:20, 29 December 2007 (UTC)
Interesting that if nobody changed anything that the main entry failed to work with entries in lower case yesterday and the alias worked, but both do work today -- I did reboot this morning. I'll change my own keyword shortcut ("aboutconfig:") back to using entries in lower case. All's well that ends well. DMcRitchie 16:36, 29 December 2007 (UTC)
This has happened to me numerous times since, don't know why it happens, but it seems to get solved by clearing cache. If it happens again, I will try to remember to first check to see if it shows redirect (I don't think it did) and to click on the "Article" link at the far right to see if a link to the correct name works from here as that clears up redirects. That would indicate if internal links from these pages work or fail in the same manner as from my own pages. This is the only article that I've had such problems with. DMcRitchie 11:18, 23 July 2009 (UTC)

Asterisks in section headers

Would anyone object if I were to remove the asterisks in section headers? For example, rather than Browser.* make it Browser. instead? Asterisks are not part of the preference name and they break forum links, even when you use [url] and [/url] tags around it - see this forum topic. Also, In-house style#Other style considerations says to use the same rules for section headers as for article titles and Article naming conventions#Punctuation marks or symbols says to avoid punctuation marks or symbols, which can break forum links. Alice 13:15, 23 July 2009 (UTC)

Good idea. I removed the asterisks in Mail_and_news_settings to be consistent with your changes. Tanstaafl 18:17, 23 July 2009 (UTC)

I went ahead and removed the asterisks. At least that eliminates the percent encoding (.2A) for asterisks from links that include section headers. Unfortunately, forum links are still broken for this article when you link to a specific section, even when using URL tags around the link. The problem seems to be the colon in the article name itself. Alice 10:46, 24 July 2009 (UTC)

Doesn't it work with percent-encoding? I.e., http://kb.mozillazine.org/About%3Aconfig_entries ? Colons have a special meaning in URLs (at least at some places such as near the start), so the forum software may balk on them. — Tony 11:24, 24 July 2009 (UTC)
Colons in urls do not interfere with the colon after "fttp:", "http:", "https:", and "file:///" as text links or in HTML. Certainly glad a representative sample of real links to the main article http://kb.mozillazine.org/About:config_entries have not been broken, because there are lots of links to the article itself, and to its sections (fragment-ids), bookmarks, and keyworded bookmarks that point to it, and colons specifically do not have to be encoded and are perfectly legal in a url, and about:config is what you enter into the location bar to see configuration variables not aboutconfig. Keep in mind that the wikis try to show a clear title based on the url without having to type the actual title separately. DMcRitchie 04:35, 29 July 2009 (UTC)

The problem is that many people don't know about using percent encoding. You can create a working link in a forum post with [url]http://kb.mozillazine.org/About:config_entries[/url] by using the URL tag or forum compose window URL button, but that doesn't work when you try to link to a specific section of the article. In other words, [url]http://kb.mozillazine.org/About:config_entries#Browser.[/url] doesn't create a clickable link but [url]http://kb.mozillazine.org/Aboutconfig_entries#Browser.[/url] (without the colon) does. Alice 14:28, 24 July 2009 (UTC)

Very confusing visually now without the asterisks in the headings. As text one can Google search on "Browser.*" and see the hits within the search results. Of course the asterisk is supposed to mean that something else is there in a Google search and an asterisk fits that as well as other characters. How would you like to read Firefox 3.5. and what it really meant was Firefox 3.5.* (very confusing). The other obvious thing is if you removed the ".*" on the descriptions, no one would even know what you were talking about. I think people just click on the link and copy the link from the location bar i.e. http://web.archive.org/web/20080106175346/http://kb.mozillazine.org/About:config_entries#Editor..2A, wouldn't make any difference what it looked like. If you want to see how ending a url with a punctuation mark confuses users, especially newsgroup users, see Troublesome comma - mozilla.support.firefox. The documentation is to be read by users. DMcRitchie 04:35, 29 July 2009 (UTC)

External References

I would not like to see anything removed from the main article, but I think that there are some categories/groups of related configuration options that should/might be linked to from within the article. (two suggestions are listed below) DMcRitchie 21:53, 28 August 2010 (UTC)

Retrieved from "http://kb.mozillazine.org/index.php?title=Talk:About:config_entries&oldid=42223"