Talk:About:config entries

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)

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)

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)

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.

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)