When using windows vista RTM, cannot load ultimateknicks.com

VERIFIED FIXED in 4.6.7

Status

P1
normal
VERIFIED FIXED
12 years ago
5 years ago

People

(Reporter: nik, Assigned: moco)

Tracking

({relnote, verified1.8.0.12, verified1.8.1.4})

4.6.7
x86
Windows Vista
relnote, verified1.8.0.12, verified1.8.1.4
Dependency tree / graph
Bug Flags:
blocking1.9 +
blocking1.8.1.4 +
blocking1.8.0.10 -
blocking1.8.0.12 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 7 obsolete attachments)

(Reporter)

Description

12 years ago
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
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.
(Reporter)

Comment 2

12 years ago
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

12 years ago
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

12 years ago
(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.
(Reporter)

Updated

12 years ago
OS: Other → Windows Vista
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

12 years ago
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.

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.
> 

Updated

12 years ago
Version: unspecified → 2.0 Branch
(Reporter)

Comment 8

12 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Resolution: FIXED → WORKSFORME
Whiteboard: Please see comment#6 and http://msdn2.microsoft.com/en-us/library/ms741621.aspx
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?
Let's try to make sure this doesn't get lost.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: 2.0 Branch → Trunk
We probably want to address this in Firefox 2.0.x as well.
Flags: blocking1.9?
Flags: blocking1.8.1.3?
Duplicate of this bug: 369902

Updated

12 years ago
Duplicate of this bug: 369535
Flags: blocking1.8.1.2?
Flags: blocking1.8.0.11?
Flags: blocking1.8.0.10?
Assignee: nobody → sspitzer
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10+
curious, what about firefox 2.0.0.1 and firefox 1.5.0.x on vista RTM?
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.
Status: NEW → ASSIGNED
> 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)?
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.
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10-
Flags: blocking1.8.0.10+

Comment 18

12 years ago
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

12 years ago
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.
Flags: blocking1.8.1.2?

Updated

12 years ago
Flags: blocking1.9? → blocking1.9+
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.
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.
Created attachment 257781 [details] [diff] [review]
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.
Attachment #257605 - Attachment is obsolete: true
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.
Attachment #257781 - Flags: review?(wtchang)
+    if (_pr_majorVersion == 6)

shouldn't that be >= 6?
> 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

12 years ago
Created attachment 258170 [details] [diff] [review]
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!
Attachment #257781 - Attachment is obsolete: true
Attachment #258170 - Flags: superreview?(cbiesinger)
Attachment #258170 - Flags: review?(sspitzer)
Attachment #257781 - Flags: review?(wtchang)
Comment on attachment 258170 [details] [diff] [review]
patch v2

seems to me like you could remove socketSetCompatMode and just test wsaioctlProc instead.
Attachment #258170 - Flags: superreview?(cbiesinger) → superreview+

Comment 29

12 years ago
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.
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).
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.
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.
Created attachment 258481 [details] [diff] [review]
updated patch, based on Wan-Teh's patch, that works for me on Vista
Attachment #258170 - Attachment is obsolete: true
Attachment #258170 - Flags: review?(sspitzer)
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
Attachment #258481 - Flags: review?(wtchang)

Comment 35

12 years ago
Created attachment 258488 [details] [diff] [review]
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.
Attachment #258488 - Flags: review?(sspitzer)

Comment 36

12 years ago
Created attachment 258489 [details] [diff] [review]
Patch v4 (corrected)

The previous patch contains an unrelated change.
Attachment #258488 - Attachment is obsolete: true
Attachment #258489 - Flags: review?(sspitzer)
Attachment #258488 - Flags: review?(sspitzer)
Attachment #258481 - Attachment is obsolete: true
Attachment #258481 - Flags: review?(wtchang)
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?
Attachment #258489 - Flags: review?(sspitzer) → review+
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)
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.
Keywords: relnote

Comment 40

12 years ago
Created attachment 258566 [details] [diff] [review]
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
Attachment #258489 - Attachment is obsolete: true
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."
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
Whiteboard: Please see comment#6 and http://msdn2.microsoft.com/en-us/library/ms741621.aspx → [landed on trunk, for 2.0.0.4, wan-teh to investigate after 3/26/07]
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.
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?
Whiteboard: [landed on trunk, for 2.0.0.4, wan-teh to investigate after 3/26/07] → [landed on trunk, for 2.0.0.4/1.5.0.12, wan-teh to investigate after 3/26/07]
(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.
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-?
Whiteboard: [landed on trunk, for 2.0.0.4/1.5.0.12, wan-teh to investigate after 3/26/07] → [landed on trunk, for 2.0.0.4, wan-teh to investigate after 3/26/07]
Unfortunately this last check-in is breaking builds made with Mingw. See bug 374029 for details
Depends on: 374029

Updated

12 years ago
Duplicate of this bug: 374029
Created attachment 258695 [details] [diff] [review]
supplimental patch to fix mingw breakage (bymartijn.martijn@gmail.com)
Attachment #258695 - Flags: review?

Comment 49

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

Does this patch fix the MinGW build failure?
Attachment #258695 - Flags: review? → review?(wtchang)
> 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.
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

12 years ago
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 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.

Updated

12 years ago
Attachment #258696 - Flags: superreview?(sspitzer)
Attachment #258696 - Flags: review?(martijn.martijn)

Comment 54

12 years ago
Comment on attachment 258695 [details] [diff] [review]
supplimental patch to fix mingw breakage (bymartijn.martijn@gmail.com)

No problem.  All of us are working on this bug at the
same time :-)
Attachment #258695 - Attachment is obsolete: true
Attachment #258695 - Flags: review?(wtchang)
Attachment #258696 - Flags: review?(martijn.martijn) → review+

Comment 55

12 years ago
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 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.)
Attachment #258696 - Flags: superreview?(sspitzer) → superreview+
Thanks for all this, Wah-Teh and Martijn. I have tested and both Mingw and VC8 are now happy
(Win XP)!
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.
Status: RESOLVED → VERIFIED
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12-
Tested the patches on MOZILLA_1_8_BRANCH and it works as expected. Thanks!
> 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

12 years ago
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

12 years ago
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?

Updated

12 years ago
Blocks: 376273

Updated

12 years ago
Blocks: 376062
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
dario, please see bug #376062
Whiteboard: [landed on trunk, for 2.0.0.4, wan-teh to investigate after 3/26/07] → [landed on trunk, before we back port for 2.0.0.4, need to fix bug #376062]
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 ?
Component: Networking → NSPR
Product: Core → NSPR
QA Contact: networking → nspr
Target Milestone: --- → 4.7
Version: Trunk → 4.6
> 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)
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?
Attachment #258696 - Attachment description: Patch to fix MinGW build failure → Patch to fix MinGW build failure (checked in on trunk and pre 4.2 branch)
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.
NSPR 4.6.7 is now defined as a target fix milestone
So this one will now show up fixed in Firefox once we update our NSPR tag?
Whiteboard: [landed on trunk, before we back port for 2.0.0.4, need to fix bug #376062] → FF needs nspr tag[landed on trunk, before we back port for 2.0.0.4, need to fix bug #376062]
Blocks: 378958

Comment 71

12 years ago
I backported the patches to the NSPR_4_6_BRANCH for NSPR 4.6.7.
Target Milestone: 4.7 → 4.6.7
Keywords: fixed1.8.0.12, fixed1.8.1.4
Marking P1, since it was handled that way.
Priority: -- → P1
Whiteboard: FF needs nspr tag[landed on trunk, before we back port for 2.0.0.4, need to fix bug #376062]
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.
Keywords: fixed1.8.1.4 → verified1.8.1.4
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. 
Keywords: fixed1.8.0.12 → verified1.8.0.12
Duplicate of this bug: 377103
Depends on: 888273
You need to log in before you can comment on or make changes to this bug.