363997 - When using windows vista RTM, cannot load ultimateknicks.com

Status: VERIFIED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Nik Thatte]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Firstly, I really appreciate the work the firefox developers do. Thank you very much for providing us with a real browser.

issue: I installed Windows Vista on a test machine. Visited ultimateknicks.com which on IE7 which worked just fine. Next thing I do is download firefox 1.5 and try to get to the website from firefox and that isn't working. The domain name resolves and firefox status bar shows "Waiting for response" and thats it. I was able to get another Windows Vista user to duplicate the issue on FF1.5, 2 and Opera. Another affected website www.bmwscruz.com

Once again, thanks for coding and maintaining such a fantastic application.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox on Windows Vista 
2. try accessing www.bmwscruz.com or ultimateknicks.com

Actual Results:  
Browser waits and the status bar says "waiting for response" but the page never loads.

Expected Results:  
Browser waits and the status bar says "waiting for response" but the page never loads.

I had the same problem on Fedora Core 5 and the fix was running the following command as root: sysctl -w net.ipv4.tcp_window_scaling=0 in the 2.6.16+ kernels

These two websites described the problem on why the linux kernel had issues:
http://securitydot.net/news/exploits/vulnerabilities/articles/2284/news.html
http://www.varbusiness.com/sections/technology/tech.jhtml?articleId=190800013

Comment 1

[Marcia Knous [:marcia]]

Nik: Both these sites work fine for me using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0.

Comment 2

[Nik Thatte]

Marcia: Hi, just to make sure, this problem only occurs when firefox is installed and run on Windows VISTA which is set to be released to public on Jan 30th. I have been testing Windows Vista for my users and would like to work out any kinks. Were you able to access the pages from firefox running on windows vista? Thanks Marcia.

Comment 3

[IceDogg]

Same thing here, I'm using the nightly builds though. I do have Vista RTM. Loads in IE. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061218 Minefield/3.0a1

Comment 4

[IceDogg]

(In reply to comment #3)
> Same thing here, I'm using the nightly builds though. I do have Vista RTM.
> Loads in IE. 
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061218
> Minefield/3.0a1
> 

Sorry, meaning it doesn't load for me either.. endlessly tries.

Comment 5

[Marcia Knous [:marcia]]

I do see the problem now, running the 2.0.0.1 build - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1. The site never seems to load. I am using the Windows Vista RTM as well. Note in my earlier comment that I was running FF 2.0, where it seemed to work. Need to see what might have changed between the two builds.

Doesn't load using Seamonkey either, but does work fine in IE as icedogg has stated.

Comment 6

[Frank Racis]

I've also seen this on:
http://www.erh.noaa.gov/forecast/MapClick.php?CityName=Philadelphia&state=PA&site=PHI

It's not Firefox specific.  Vista made some changes to TCP defaults and RFC1323 window scaling, and there are Cisco devices out there that don't properly follow the spec.

On Vista, Firefox will default to opening the TCP connection with a scaling factor of 8.  If you hit one of these broken sites, it will successfully open the connection, but you will never receive any packets after the handshake.  IE is opening the connection with a scaling factor of 2, which succeeds.  

You can make the same configuration change on Vista as you did on Linux:
    netsh interface tcp set global autotuninglevel=disabled
to set the window scaling to 0.  You can also use
    netsh interface tcp set global autotuninglevel=highlyrestricted
    netsh interface tcp set global autotuninglevel=restricted
for 2 or 4, respectively.  In the sites I've tested, "restricted" (size 4) was enough to solve the problem.

If you go to http://msdn2.microsoft.com/en-us/library/ms741621.aspx and scroll down to the part about SIO_SET_COMPATIBILITY_MODE it explains what's happening and how to use an Ioctl to fix this programatically without changing the systemwide default.

Comment 7

[Marcia Knous [:marcia]]

Frank: Thanks so much for clarifying this issue and for the links to more information.

(In reply to comment #6)
> I've also seen this on:
> http://www.erh.noaa.gov/forecast/MapClick.php?CityName=Philadelphia&state=PA&site=PHI
> 
> It's not Firefox specific.  Vista made some changes to TCP defaults and RFC1323
> window scaling, and there are Cisco devices out there that don't properly
> follow the spec.
> 
> On Vista, Firefox will default to opening the TCP connection with a scaling
> factor of 8.  If you hit one of these broken sites, it will successfully open
> the connection, but you will never receive any packets after the handshake.  IE
> is opening the connection with a scaling factor of 2, which succeeds.  
> 
> You can make the same configuration change on Vista as you did on Linux:
>     netsh interface tcp set global autotuninglevel=disabled
> to set the window scaling to 0.  You can also use
>     netsh interface tcp set global autotuninglevel=highlyrestricted
>     netsh interface tcp set global autotuninglevel=restricted
> for 2 or 4, respectively.  In the sites I've tested, "restricted" (size 4) was
> enough to solve the problem.
> 
> If you go to http://msdn2.microsoft.com/en-us/library/ms741621.aspx and scroll
> down to the part about SIO_SET_COMPATIBILITY_MODE it explains what's happening
> and how to use an Ioctl to fix this programatically without changing the
> systemwide default.
> 

Comment 8

[Nik Thatte]

Frank: I appreciate the comments and the fix. Thank you very much for all the links as well. I successfully tested with: 

netsh interface tcp set global autotuninglevel=restricted

Thanks again.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Er... shouldn't we actually change the TCP window on our end to match IE's if the one we're using will break sites?

Like add that ioctl() call?  Should that be happening in Necko, or NSPR?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Let's try to make sure this doesn't get lost.

Comment 11

[Boris Zbarsky [:bzbarsky]]

We probably want to address this in Firefox 2.0.x as well.

Comment 14

[(not reading, please use [e-mail] instead)]

curious, what about firefox 2.0.0.1 and firefox 1.5.0.x on vista RTM?

Comment 15

[(not reading, please use [e-mail] instead)]

I'll start working on this, but I think this would be something better for 2.0.0.3.

I think a change like this would deserve a full dot release of testing.

Comment 16

[(not reading, please use [e-mail] instead)]

> Like add that ioctl() call?  Should that be happening in Necko, or NSPR?

I think we'd want to do something in NSPR, and not Necko.

Specifically, use WSAIoctl() [and not ioctl() or ioctlsocket()] in nsprpub/pr/src/md/windows/ntio.c as soon as the socket is created (in _PR_MD_SOCKET() at http://lxr.mozilla.org/mozilla1.8/source/nsprpub/pr/src/md/windows/ntio.c#1147)

From the documentation, setting the BehaviorId member to WsaBehaviorAutoTuning and the TargetOsVersion to NTDDI_LONGHORN (aka Windows Vista).  But, also according to the documentation, SIO_SET_COMPATIBILITY_MODE is supported on Windows Vista and later.

so, when we call WSAIoctl() on other versions of windows it should return SOCKET_ERROR and I think WSAGetLastError() should be set to WSAEINVAL.  In that case, I think we should then call WSASetLastError(0)to clear that error.

Wan-teh, any thoughts on this approach, as what I am proposing morphs this bug into an NSPR / Vista bug.

Also, I wonder if this bug could be affecting tbird on Vista (in the mail/news protocol code and in the ldap sdk code)?

Comment 17

[Daniel Veditz [:dveditz]]

Definitely not blocking 1.5.0.10, we have lots of Vista compatibility issues addressed only in 2.0.0.x and should urge people having problems to upgrade. Of course if NSPR gets a fix then later versions of 1.5 will pick it up.

Comment 18

[Wan-Teh Chang]

Seth, why don't you go ahead and experiment with the WSAIoctl()
approach?  For Mozilla clients, you need to patch
mozilla/nsprpub/pr/src/md/windows/w95io.c instead of ntio.c.

Comment 19

[Wan-Teh Chang]

Seth, you can call GetVersionEx() to get the Windows version
and save it in a global variable.  Then, you only call WSAIoctl
on Windows Vista or later.

We already call GetVersionEx() in the InitUnicodeSupport function
in w95io.c.  We can just use that call to set the new global variable.

Comment 20

[(not reading, please use [e-mail] instead)]

wan-teh, thanks for the suggestions.

I did a little investigating yesterday and here's where I am:

I followed wan-teh's suggestion and I'm leveraging the call in GetVersionExA() in InitUnicodeSupport() to save off the Windows version.

Then, in _PR_MD_SOCKET() in w95sock.c, if the version is Vista, I use WSAIoctl
() to set the compatibility mode.

note, WSAIoctl() is part of winsock2 (Ws2_32.dll) and only on vista, and winsock2.h has changed on vista.  so, I'm using PR_LoadLibrary() and PR_FindFunctionSymbol() in order to call WSAIoctl(), again only on vista and some additional mumbo jumbo to avoid including winsock2.h.

wan-teh (and the rest of the windows experts on the cc list), does this seem reasonable?

alternatively, there might be a way to fix/workaround this by, for vista only, calling setsockopt() and setting the size of the SO_RCVBUF to something smaller, but I'm not sure if that would work (or if it would have other side effects.)

I may hand this over to someone else, so I'll attach a patch as after I clean it up.

Comment 21

[(not reading, please use [e-mail] instead)]

Attachment: wip patch

Comment 22

[(not reading, please use [e-mail] instead)]

that patch is having problems on vista.  I can't tell (yet) if it is because I'm building and testing an optimized build.

but it might be pilot error:

+          if (wsaioctlProc(sock, SIO_SET_COMPATIBILITY_MODE,  
+                          (char *)&mode, sizeof(mode),
+                           NULL, 0, NULL, NULL, NULL) == SOCKET_ERROR)

I may need to do:

+          char dummy[4];
+          int ret_dummy;
+          if (wsaioctlProc(sock, SIO_SET_COMPATIBILITY_MODE,  
+                          (char *)&mode, sizeof(mode),
+                           dummy, 4, &ret_dummy, 0, NULL) == SOCKET_ERROR)

I'll test and rebuild.

Comment 23

[(not reading, please use [e-mail] instead)]

Attachment: patch

in addition to needing the "dummy", I was missing __stdcall

I've built on windows xp with this this, and when I run on vista, I can now visit www.ultimateknicks.com

important note, I am not running vista under VMWare.  mscott tried that for me, and he was able to visit www.ultimateknicks.com even without this fix.

Comment 24

[(not reading, please use [e-mail] instead)]

Comment on attachment 257781 [details] [diff] [review]
patch

seeking wan-teh's review on this one.  note, this is for the NSPRPUB_PRE_4_2_CLIENT_BRANCH, for firefox trunk.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

+    if (_pr_majorVersion == 6)

shouldn't that be >= 6?

Comment 26

[(not reading, please use [e-mail] instead)]

> shouldn't that be >= 6?

Good question:   limit the fix to vista or assume it will be a problem in the next release as well.

Wan-teh, which do you recommend?

Comment 27

[Wan-Teh Chang]

Attachment: patch v2

Seth, thanks a lot for your patch.  You are on the right
track and have done the hard part.  The only problem with
your patch is that it calls PR_LoadLibrary and PR_FindFunctionSymbol
every time we open a socket.  Since we can't unload ws2_32.dll
until NSPR is shut down, your patch will leak a PRLibrary
structure for each socket we open.  I fixed this memory leak.
I also made some editing changes (such as using C comment
delimiters instead of //) and went back to making a separate
call to GetVersionEx in w95sock.c.

I decided to enable this workaround on Vista and later.
I can't predict the future, so I don't know if it will be
a problem in the next release after Vista as well.  It is
*safe* to use this workaround on Vista and later because
SIO_SET_COMPATIBILITY_MODE is supported on Windows Vista
and later.

Please review and test this patch on Vista.  Thanks!

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 258170 [details] [diff] [review]
patch v2

seems to me like you could remove socketSetCompatMode and just test wsaioctlProc instead.

Comment 29

[Wan-Teh Chang]

Comment on attachment 258170 [details] [diff] [review]
patch v2

Yes, socketSetCompatMode is redundant now.  I added
socketSetCompatMode to prepare for the future if we
ever need to call WSAIoctl for other reasons.

Comment 30

[(not reading, please use [e-mail] instead)]

Wah-Teh, thanks for pointing out the problems with my patch (and the major leak!) and for reworking it.  your patch looks good, and much cleaner.

I'll test it out first thing on monday morning on Vista (note, I can't test using Vista under a VM, see comment #23).

Comment 31

[(not reading, please use [e-mail] instead)]

update:  I tried this patch yesterday afternoon, but I had a problem.  

(firefox would not run, unexpected error.  note, I had seen something like that with earlier versions of my patch, before I added the __stdcall)

I'll try again today, figure out the problem, and report back.

Comment 32

[(not reading, please use [e-mail] instead)]

wan-teh, sorry for the delay.

this patch has problems, I think caused by calling PR_LoadLibrary() early?

When I move the code around, to _PR_MD_SOCKET(), it works and I don't get the problems.

I'll attach a rework of wan-teh's patch that works on vista.

Comment 33

[(not reading, please use [e-mail] instead)]

Attachment: updated patch, based on Wan-Teh's patch, that works for me on Vista

Comment 34

[(not reading, please use [e-mail] instead)]

Comment on attachment 258481 [details] [diff] [review]
updated patch, based on Wan-Teh's patch, that works for me on Vista

seeking a review from Wan-Teh

Comment 35

[Wan-Teh Chang]

Attachment: Patch v4

The crash is inside PR_LoadLibrary, and the reason for the
crash is that NSPR's support for PR_LoadLibrary hasn't been
initialized when we call _PR_InitIO.

The workaround is to call the Win32 LoadLibrary function.
This is OK because this is Windows-specific code.

Seth, please test this patch.  Thanks.

Comment 36

[Wan-Teh Chang]

Attachment: Patch v4 (corrected)

The previous patch contains an unrelated change.

Comment 37

[(not reading, please use [e-mail] instead)]

Comment on attachment 258489 [details] [diff] [review]
Patch v4 (corrected)

r=sspitzer, thanks for fixing this Wan-Teh.

this patch works for me on Vista.

one small question for Wan-Teh:

any reason why we should not explicitly initializes libWinsock2, wsaioctlProc, and socketSetCompatMode to NULL, NULL and PR_FALSE?

Comment 38

[(not reading, please use [e-mail] instead)]

wan-teh, one other minor correction:

* so don't pay for it at build time (and avoid including winsock2.h

should be:

* so don't pay for it at build time (and avoid including winsock2.h)

(I'm missing the close parenthesis)

Comment 39

[(not reading, please use [e-mail] instead)]

this seems like something that should be in the 2.0.0.3 (and prior?) release notes, as the it looks like the soonest we would see the fix is 2.0.0.4.

Comment 40

[Wan-Teh Chang]

Attachment: Patch v5 (as checked in)

I initialized the static variables to NULL, NULL, and PR_FALSE
and added the closing parenthesis to the comment as Seth suggested.
I was relying on the compiler initializing static variables to
0 as required by the C language.  I guess a null pointer doesn't
have the value 0 in all C implementations?

I checked in the patch on the NSPR trunk (NSPR 4.7) and the
NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.9).

Checking in pr/include/md/_win95.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_win95.h,v  <--  _win95.h
new revision: 3.34; previous revision: 3.33
done
Checking in pr/src/md/windows/w95io.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c,v  <--  w95io.c
new revision: 3.32; previous revision: 3.31
done
Checking in pr/src/md/windows/w95sock.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95sock.c,v  <--  w95sock.c
new revision: 3.12; previous revision: 3.11
done
Checking in pr/src/md/windows/w95thred.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95thred.c,v  <--  w95thred.c
new revision: 3.17; previous revision: 3.16
done

Checking in include/md/_win95.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_win95.h,v  <--  _win95.h
new revision: 3.19.2.15; previous revision: 3.19.2.14
done
Checking in src/md/windows/w95io.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c,v  <--  w95io.c
new revision: 3.22.4.9; previous revision: 3.22.4.8
done
Checking in src/md/windows/w95sock.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95sock.c,v  <--  w95sock.c
new revision: 3.7.4.5; previous revision: 3.7.4.4
done
Checking in src/md/windows/w95thred.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95thred.c,v  <--  w95thred.c
new revision: 3.9.4.8; previous revision: 3.9.4.7
done

Comment 41

[(not reading, please use [e-mail] instead)]

wan-teh has landed on the trunk, so marking fixed.

wah-teh, thanks again for fixing my patch and for landing it.

to fix this for 2.0.0.x (probably 2.0.0.4) wtc writes:   "Yes, the firefox branch needs to use an official NSPR release tag.  So we'll need to land the patch on NSPR_4_6_BRANCH and release NSPR_4_6_7_RTM.  There is some extra release engineering work required."

Comment 42

[(not reading, please use [e-mail] instead)]

additional note:  rstrong did not see this on his vista laptop with his curitel broadband wireless card.

but, at least with the vista ultimate dell machine in the mozilla.com QA lab, you can reproduce it.

Comment 43

[(not reading, please use [e-mail] instead)]

this is also an issue with 1.5.0.10.  We'd need similar release work in order to fix it for 1.5.0.12 on Vista.  wan-teh, would that be possible?

Comment 44

[Robert Strong (they/them - no direct email)]

(In reply to comment #43)
> this is also an issue with 1.5.0.10.  We'd need similar release work in order
> to fix it for 1.5.0.12 on Vista.  wan-teh, would that be possible?
I don't think we should since we aren't going to backport the changes for Vista compatibility to 1.5.0.x and 1.5.0.x is scheduled to EOL in April.

Comment 45

[(not reading, please use [e-mail] instead)]

based on roberts comments and how we recommend 2.0.0.x to vista users, perhaps we should make this blocking 1.8.0.12-?

Comment 46

[Bengt-Erik Soderstrom]

Unfortunately this last check-in is breaking builds made with Mingw. See bug 374029 for details

Comment 48

[(not reading, please use [e-mail] instead)]

Attachment: supplimental patch to fix mingw breakage ([e-mail])

Comment 49

[Wan-Teh Chang]

Attachment: Patch to fix MinGW build failure (checked in on trunk and pre 4.2 branch)

Does this patch fix the MinGW build failure?

Comment 50

[(not reading, please use [e-mail] instead)]

> Does this patch fix the MinGW build failure?

according to Martijn (see https://bugzilla.mozilla.org/show_bug.cgi?id=374029#c1) it does.

but i don't have a MinGW build environment to verify.

Comment 51

[Martijn Wargers (dead)]

Yeah, the patch fixes the build issue for me, also for , according to Bengt-Erik:
https://bugzilla.mozilla.org/show_bug.cgi?id=374029#c2

Comment 52

[Wan-Teh Chang]

Comment on attachment 258696 [details] [diff] [review]
Patch to fix MinGW build failure (checked in on trunk and pre 4.2 branch)

Seth, I attached an alternative supplemental patch (this patch).

Martijn, does this (alternative) patch fix the MinGW build failure?

Comment 53

[Martijn Wargers (dead)]

Comment on attachment 258696 [details] [diff] [review]
Patch to fix MinGW build failure (checked in on trunk and pre 4.2 branch)

Sorry, I didn't notice.
Yeah, your patch also seems to fix the mingw build issue.

Comment 54

[Wan-Teh Chang]

Comment on attachment 258695 [details] [diff] [review]
supplimental patch to fix mingw breakage ([e-mail])

No problem.  All of us are working on this bug at the
same time :-)

Comment 55

[Wan-Teh Chang]

Comment on attachment 258696 [details] [diff] [review]
Patch to fix MinGW build failure (checked in on trunk and pre 4.2 branch)

Thank you, Martijn, for your help.

I checked in this supplemental patch on the NSPR trunk
(NSPR 4.7) and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.9).

Checking in w95sock.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95sock.c,v  <--  w95sock.c
new revision: 3.13; previous revision: 3.12
done

Checking in w95sock.c;
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95sock.c,v  <--  w95sock.c
new revision: 3.7.4.6; previous revision: 3.7.4.5
done

Comment 56

[(not reading, please use [e-mail] instead)]

Comment on attachment 258696 [details] [diff] [review]
Patch to fix MinGW build failure (checked in on trunk and pre 4.2 branch)

thanks for fixing this wah-teh.

(I'll re-test the trunk firefox build on Vista tomorrow to make sure it works fine.)

Comment 57

[Bengt-Erik Soderstrom]

Thanks for all this, Wah-Teh and Martijn. I have tested and both Mingw and VC8 are now happy
(Win XP)!

Comment 58

[(not reading, please use [e-mail] instead)]

verifying.

On Windows Vista Ultimate, I used a trunk released nightly build from before this fix, and was unable to visit ultimateknicks.com.

This morning I ran software update and got a new trunk build (Gecko/2007031504 Minefield/3.0a3pre) and I can now visit that site.

Note, Wah-Teh checked in a his supplemental fix (so that we build on MingW) after 3/15 at 4 am, so I'll try again later today when the 3/16 update is available.

Comment 59

[Robert Strong (they/them - no direct email)]

Tested the patches on MOZILLA_1_8_BRANCH and it works as expected. Thanks!

Comment 60

[(not reading, please use [e-mail] instead)]

> Note, Wah-Teh checked in a his supplemental fix (so that we build on MingW)
> after 3/15 at 4 am, so I'll try again later today when the 3/16 update is
> available.

still works great, using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a3pre) Gecko/20070320 Minefield/3.0a3pre

what's next:  the release and back port to MOZILLA_1_8_BRANCH for firefox 2.0.0.x (and tbird 2)

Comment 61

[Dario de Judicibus]

I just received a DELL E520 with Vista Premium preinstalled. I can browse any site by IE, but I cannot by Firefox. Most Italian sites cannot be visited. Practically, apart Google and few other ones, Firefox fails to load any other site.

Comment 62

[Dario de Judicibus]

I tried 

netsh interface tcp set global autotuninglevel=disabled

but that da*n Vista request some special authority to perform that operation. However I already entered in Vista with my account, and it is an ADMINISTRATOR account. What does it wants more?

Comment 63

[(not reading, please use [e-mail] instead)]

Dario, which version of firefox are you using?

Note, this fix is only on trunk builds, and has not yet been backported to 2.0.0.x

Comment 64

[(not reading, please use [e-mail] instead)]

dario, please see bug #376062

Comment 65

[Nelson Bolyard (seldom reads bugmail)]

I am changing this bug's product to NSPR so that it will show up in 
searches for NSPR bugs fixed.

Wan-Teh, 
Is there any reason for these fixes NOT to be on the NSPR_4_6_BRANCH ?

Comment 66

[(not reading, please use [e-mail] instead)]

> Is there any reason for these fixes NOT to be on the NSPR_4_6_BRANCH ?

In addition to what Wan-Teh says, please wait until a fix for #376062 has landed on the trunk before we backport this fix to the NSPR_4_6_BRANCH (as that will affect Firefox 2.0.0.x / Thunderbird 2.0.0.x)

Comment 67

[(not reading, please use [e-mail] instead)]

in bug #376062, Wan-Teh wrote:

> Please check it in on both the NSPR trunk and the NSPRPUB_PRE_4_2_CLIENT_BRANCH

The patch in here needs to be landed on NSPRPUB_PRE_4_2_CLIENT_BRANCH, too along with the patch in bug #376062.

Nelson, can you help me land on the NSPRPUB_PRE_4_2_CLIENT_BRANCH?

Comment 68

[Nelson Bolyard (seldom reads bugmail)]

Seth, it appears that you landed this patch on NSPRPUB_PRE_4_2_CLIENT_BRANCH
yourself.  If you also want this to go into the NSPR_4_6_BRANCH, for 
inclusion in the next official NSPR "stable" release, then please reopen
this bug and  change the target milestone to NSS 4.6.<something>.
I think the highest defined point release number for that branch in 4.6.6.

Comment 69

[Nelson Bolyard (seldom reads bugmail)]

NSPR 4.6.7 is now defined as a target fix milestone

Comment 70

[Daniel Veditz [:dveditz]]

So this one will now show up fixed in Firefox once we update our NSPR tag?

Comment 71

[Wan-Teh Chang]

I backported the patches to the NSPR_4_6_BRANCH for NSPR 4.6.7.

Comment 72

[Nelson Bolyard (seldom reads bugmail)]

Marking P1, since it was handled that way.

Comment 73

[Marcia Knous [:marcia]]

verified fixed on the 1.8 branch using  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4) Gecko/2007050106 Firefox/2.0.0.4. Running on Win Vista Home Basic. The ultimateknicks.com URL loads fine. Adding branch keyword.

Comment 74

[Marcia Knous [:marcia]]

verified fixed on the 1.8.0 branch using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.0.12pre) Gecko/20070508 Firefox/1.5.0.12pre. Running on Win Vista Home Basic. The ultimateknicks.com URL loads fine. Adding branch keyword.