346834 - Startup slowed by unneeded attempts to load IPv6 support

Status: RESOLVED INVALID

(NSPR :: NSPR, defect)

Description

[Steve Snyder]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060527 SUSE/1.5.0.5-0.0 Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060527 SUSE/1.5.0.5-0.0 Firefox/1.5.0.5

[This is realy a NSPR issue but General was the closest catagory I was offered.]

On Windows platforms we unconditionally try to load 2 DLLs ("ws2_32.dll" and "wship6.dll") in an attempt to get IPv6 support.  This attempt ignores 2 things:

1. How, or if, IPv6 is supported on that version of Windows.
2. The state of the "network.dns.disableIPv6" preference.

Some background: There is no support of IPv6 in any Win9x version nor is it supported in NT-based versions of Windows older than Win2K.  In Win2K IPv6 is support as a "Technology Preview" by DLL wship6.dll.  All versions of Windows subsequent to Win2K support IPv6 in DLL ws2_32.dll.


Reproducible: Always

Steps to Reproduce:
1.Run any current Mozilla-based browser (seen on SeaMonkey 1.0.3).
2.
3.

Actual Results:  
SeaMonkey attempts to load a DLL, ws2_32.dll, which cannot be used on my Win2K system.  Then it attempts to load wship6.dll despite my having the network.dns.disableIPv6 preference enabled.

Expected Results:  
Mozilla browsers should not waste time attempting to load resources that are inappropriate for my environment.


The DLL loading is done in _pr_find_getaddrinfo() (file nsprpub/pr/src/misc/prnetdb.c).

Two bits of information are needed by _pr_find_getaddrinfo() to fix this.  We need to know the version of Windows that the code is being run on and we need to know that state of the network.dns.disableIPv6 preference.  With those 2 facts in hand, then:

1. Never attempt to load either DLL on versions of Windows that don't support IPv6

2. Attempt to load only wship6.dll on Win2K if network.dns.disableIPv6 has not been enable.

3. Attempt to load only ws2_32.dll on WinXP+ if network.dns.disableIPv6 has not been enable.

Comment 1

[Steve Snyder]

Changed Product to more appropriate NSPR.

Comment 2

[Steve Snyder]

Attachment: First cut: Windows version-specific IPv6 loading, no Prefs support

The loading of IPv6 support is attempted on a Windows-version-specific basis - or not at all in the case of unsupported platforms.

This version does not take the IPv6 pref into account because I'm not sure it is allowed to make the NSPR library dependent on libprefs.  I don't see any other NSPR code that uses the preferences.

In any case, this patches reduces the number of attempted DLL loads for versions of Windows prior to WinXP.  WinXP and later always succeeded on the first DLL load and that single successful load is still true.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Steve, you do realize you'll need to set the appropriate review flags if you want to see this checked in to CVS, right?

If not, http://www.mozilla.org/hacking/code-review-faq.html might be of some help.

Alternatively, you can stop by #developers on irc.mozilla.org and ask there.

Comment 4

[Steve Snyder]

Well, I'm no longer sure that there is anything worth checking in.

I didn't do the 1st of the 2 changes I claimed were needed, where the user's stated IPv6 preferences are taken into account.  I'm still not sure it is is deemed appropriate to make the NSPR library (which loads the DLLs) dependent on the prefs library (which parses the prefs file).

My goal in the 2nd changes was to avoid the attempted load of ws2_32.dll on Win2K systems.  My understanding was that ws2_32.dll was a WinXP+ feature and that the unconditional load attempt was inappropriate on that OS.  It turns out that this DLL can be on a Win2K system if an application that requires it installs it there.  So it may in fact be appropriate to attempt the loading of that DLL on Win2K.

Comment 5

[Julien Pierre]

Indeed, we can't make the NSPR library depends on the prefs file, since the library is used in many applications other than the mozilla browser, which don't have prefs file.

Based on comment 4, it sounds like the other change to select the DLL to load based on the OS version is also inappropriate. So, I'm closing this bug as invalid. Feel free to reopen if you disagree.