Networking Preferences - index of preferences



16 years ago
6 years ago


(Reporter: benc, Assigned: benc)





(1 obsolete attachment)



16 years ago
I'm going to put a master document for networking related-prefs. I don't
actually QA all these features, so I am not going to cover everything on the
list, but I will own this document, and keep the links accurate.

Comment 1

16 years ago
I just finished documenting most of the prefs I cover as QA.

At some later date, hopefully via people suggesting itesm that I do not QA, this
list could encompass all networking behaviors, not just my assigned areas.


16 years ago
Blocks: 178685

Comment 2

16 years ago
I've added all the missing misc. stuff + the beginnings of the HTTP write-up.

Comment 3

16 years ago

Comment 4

16 years ago
Comment on attachment 125989 [details] [diff] [review]
Patch for a few typo-type nits.

Warner's patch in
Attachment #125989 - Attachment is obsolete: true


16 years ago
Depends on: 213473

Comment 5

15 years ago
cc: darin as an FYI.

Thanks for the corrections!

The document still trails the trunk, but I've added partial info on
external-handler, as well as the https disk caching change darin made.

I'm going to give this extra attention in the future, because it is one of the
few really important network docs that is also a moving target.

Comment 6

15 years ago
-> mine, P1

I know I'm behind on this, so anyone who spots a netpref that is not documented,
tell me here!
Priority: -- → P1

Comment 7

15 years ago
Added info about the general offline/online prefs (nothing module-specific, like

Comment 8

15 years ago
kerberos prefs! I'm behind on bugmail... bug 243850 
Depends on: 243850

Comment 9

15 years ago
The description for the pref browser.cache.memory.capacity on is wrong. 
1) The values are in KiB not in B. See
2) Not any value. Pref not present or < 0 == use default, = 0 memory cache is
DISABLED, > 0 value is used. See 

Comment 10

13 years ago
Where possible, it would be nice to document what version prefs became avaialable in, as well as when defaults change. 

For example, the default for network.dnsCacheExpiration is listed as "60", but AFAICT by browsing bugzilla, it was infinite before ~2002, and 5 minutes until 1.6 (please correct me if I'm wrong).


Comment 11

13 years ago
network.http.keep-alive.timeout is documented as having a default of "30", but a clean install of FF (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20060508 Firefox/ has "300". has a fuller list of preferences, suggest referring people to that doc instead.
Assignee: benc → endico
Didn't mean to reassign.. benc are you still working on this?
Assignee: endico → benc

Comment 14

12 years ago

I can't seem to find pref to set the proxy timeout. In FF 1.0.x you could set a proxy up and if it wasn't found it would switch to direct connection very fast (maybe 2-5 sec). Since FF 1.5.x the timeout has become very long, so I had to install an extension to switch from proxied to non-proxied mode. Is there a way to get the pre-1.5 mode/timeout back via a pref? This problem has gotten to be unbearable since 2.0.x since aperently FF tried to contact the proxy before the UI is up, so if I go from a proxied network to a non-proxied network (and vice-versa), I have to wait about 5 minute (a colleague says he times it and it took him 11 minutes) to launch FF. I tried to turn off the update feature, since I though it was it that tried to connect, but that changed nothing. If I launch FF without the network it starts right up.So to summarize my questions :

1) Is there a pref (or can one be added) to get the FF < 1.5 mode back, where if a proxy is set, if it can't be contacted then after a short timeout it switches to non-proxied mode. This would be nice so that an extention isn't needed to switch from proxied-to non-proxied mode and vice versa.

2) Is there a pref (or is it a bug?) so that FF doesn't try to connect to the internet before the UI is up, so that I don't have to wait more than 5 minutes for FF to launch. (I have 2 colleagues that have the same problem).

(In reply to comment #14)
> Hello,
This post totally doesn't belong in this bug. Ask in the relevant forum/newsgroup/mailing list instead.
Component: Mozilla Developer → Documentation Requests
Product: Documentation → Mozilla Developer Center
QA Contact: imajes → doc-request

Comment 16

12 years ago
Nickolay: I'm only making appearences when I am unemployed. So for another week or so, yes :)

Gabriel: I'm not aware of such a timeout. If you find a bug number or other reference, please email me, and we can see about documenting it.

If you want it added as a feature, ask in the group Nickolay mentioned.

I'm going to review more recent comments and try to do some updating tonight.

Comment 17

12 years ago

now that I think about this more, what your are describing is two problems:

1- ff starts up and sends an http request to the proxy. ff has no offline-online controls, but you can find that in the plug-icon in seamonkey.

2- how long does this take, to timeout? necko uses the system default. time your failure from the line command (date;telnet proxy port;date), and compare the times.

Comment 18

12 years ago
Checking in mozilla-org/html/quality/networking/docs/netprefs.html;
/www/mozilla-org/html/quality/networking/docs/netprefs.html,v  <--  netprefs.html
new revision: 1.21; previous revision: 1.20

moved feedback link.
made dns entries separate from cache.
removed old cookie prefs. (pointer to mconners stuff, which is current.

Comment 19

11 years ago

This was migrated to:

I'm porting the late changes, then I will hack the top of the page to make it historical. is a very impressive article. I don't have edit access there, so I'm going to re-think the content of the MDC document to avoid duplicating info.
Last Resolved: 11 years ago
Resolution: --- → FIXED
Component: Documentation Requests → Documentation
Product: Mozilla Developer Network → Mozilla Developer Network
Component: Documentation → General
Product: Mozilla Developer Network → Developer Documentation
You need to log in before you can comment on or make changes to this bug.