Attempt to load an invalid page, e.g. www.lkjldskfjlsdkjflksdfjlksdfjlk.com and Mozilla just sits there forever. There appears to be a problem with the DNS lookup behaviour. This might be XP specific since I cannot reproduce on W2K, Mac or Linux. For simplicity you can reproduce using TestSocketIO, e.g. TestSocketIO www.lkjldskfjlsdkjflksdfjlksdfjlk.com /
i will take a look. it may be a regression caused by recent changes to the dns.
I had the same problem in trunk 20020714, seems to be gone in 20020715, although I admit I just reinstalled the OS also (WinXP).
I can not reproduce this in a build from this morning. Windows.
I was able to reproduce this again late last night on XP but not W2K. What were the recent DNS changes that may be causing this?
I've been digging and I think the problem is the automatic RAS dialup feature in Win32. The pref "network.autodial-helper.enabled" is set to true in all.js. On Win32 this means the socket transport will attempt to use the native connection helper object when a DNS lookup fails. On my XP system I appear to have the "RasAuto" service (it's probably there by default) so the nsRASAutodial thinks I want to use it and attempts to dial out. Unfortunately, this fails each time so it goes around and around for ever trying to do the lookup. I'll see if there is a simple patch to fix RAS.
Dialup networking was enabled by bug 93002
Created attachment 91657 [details] [diff] [review] Patch This patch changes how the nsRASAutoDial decides if it should be used or not. The old behaviour tested if the RAS service was running and returned AUTODIAL_USE_SERVICE. On XP (on mine at least), the service always seems to be running, either by default or because installing a modem or AOL enabled it. BTW My IE is set to "Never dial a connection" so it isn't that. Steve, can you verify and review the new ordering? In this ordering, we first test the IE settings before resorting to guesswork based on whether the RAS service is running or not. I also notice the RAS API has a method called RasGetAutodialEnable which we don't call. Perhaps that would be more reliable than testing for services, but I'm not familiar with RAS so I don't know.
No, we need to check to see if the service is running first, and let it do its work if it is. We only want to try to dial ourselves if the service is not running. If you do it the other way around you can end up with two sets of autodial dialogs if the user cancels the first one: We dial from withing the code, and the user cancels the dialup dialog. The service then tries to dial. It sounds like what is happening in your case is that the service is running, so we expect it to dial, but there are no connections set up, so it doesn't actually dial. But we retry because we assume it would dial. I think the best fix is to not retry if the service is running, since we can't assume it will dial just because it is running (the assumption I made when writing this.)
Please keep in mind that (R)RAS does much more than dial-up. Maybe we could reproduce this also on Win2K (at least server) if RAS is enabled for dial-in? Anyway, I think Steve is right in that we can't assume anything just because it's running.
>Please keep in mind that (R)RAS does much more than dial-up. Yes, but the service we are examining only does the autodial stuff.
Created attachment 91836 [details] [diff] [review] Patch which will not assume the service will alway dial.
Adding keyword. Note that on XP is that the service runs even when it's not actually doing or required to do anything. I don't think you can infer anything from the fact it is running.
over to steve who is working on this.
The latest patch does work, however it puts some junk about the unresolved address into my registry under HKEY_CURRENT_USER\Software\Microsoft\RAS Autodial\Addresses. I still believe it is doing that because it erroneously thinks I have RAS and want to use when I don't.
Yes, if the autodial service is running, you'll get that "junk" in the registry. That where Windows stores the autodial database, and that's how I try to force the service to dial when it can't reach an address. (I don't add them to the registry directly--I use the RAS API, and the service puts them there itself.) Addresses will be added to that area of the registry by the OS in certain other cases as well.
As I mentioned though, I am *not* running RAS in any way shape or form. I have no idea why the service is enabled on my XP system (perhaps all of them), but my options all say to use the local network, not dial out. I just believe there is something wrong if it tries to use the RAS service even when the internet settings say it shouldn't.
I see what you mean. I am interpreting the fact that the RAS autodial service is running to mean that you want to use RAS autodial. In your case this isn't true because you didn't start the service on your own. However, I don't know of any other Windows settings relating to the autodial service. Here are the problems I am trying to solve with my autodial approach: People who know Windows XP know that they should start the autodial service if they want the OS to autodial on error. That works fine with Mozilla without any extra code, UNLESS there is a network card installed (even when it's not plugged in to anything.) It that case, the only way the service will trigger an autodial is if the network address is in the autodial database, and that's what I'm doing. People who don't know XP want the OS to autodial if they turn it on in the control panel | Internet Options | Connections. In reality, those setting have nothing whatsoever to do with controlling the service: they only control IE and Outlook. But we try to accommodate those people: if they configure auto there, then we bring up the autodial dialogs ourselves in the code, UNLESS the autodial service is running. Because if it is running, the service might try to dial. We have no way of knowing if it did or not. If it did, and the user cancels, and then we try to dial, there will be two dialup dialogs. Now I was assuming the service would always dial on error if running, so there is a new additional problem: if it is running and doesn't dial, we won't either, and autodial is broken for that case.
Oh wait: there is a setting that controls if the RAS autodial service will dial or not. I didn't come across this setting in my prior research. It's in Network Connection | Avanced | Dialup Preferences. So if I test for that setting as well as if the service is running, and carry on as before, I should be in good shape.
Created attachment 91889 [details] [diff] [review] patch that checks OS settings better This patch changes the behavior such that the code won't write to the autodial database unless the autodial service is running AND autodial setting is enabled in Network Connections | Advanced | Dialup Preferences. I also now examine the setting that is supposed to disable the autodial service for the remainer of the logon session, which I wasn't doing before. I had to make some changes to pick up the setting from the dialing location, and in the process fixed a problem where the dialing location was hardwired to 1 in the call to RasSetAutodialAddress(). These changes should make the autodial behavior work better when used when the service is running. It will still work as before when the service is not running. Also, since the number of dynamically loaded functions is getting large, I moved the initialization of those into functions and added NULL checking there instead of at every call.
Created attachment 91910 [details] [diff] [review] Minor change to last patch to get it to work on Win 2k as well.
Comment on attachment 91910 [details] [diff] [review] Minor change to last patch to get it to work on Win 2k as well. New patch works for me. r=adamlock
Created attachment 92274 [details] [diff] [review] Minor change to pick up the right dialing location. This is a change to the last patch to pick up the correct "dialing location" to use when querying the autodial setting for the autodial service. The service uses the setting of the "current" dialing location--last patch I was checking for the setting on any dialing location.
Comment on attachment 92274 [details] [diff] [review] Minor change to pick up the right dialing location. r=adamlock
Comment on attachment 92274 [details] [diff] [review] Minor change to pick up the right dialing location. >Index: nsAutodialWin.cpp > // force it to dail in that case by adding the network address to its db.) s/dail/dial/ otherwise the changes look solid to me. sr=darin
asa, dbaron could you a= this regression fix?
Comment on attachment 92274 [details] [diff] [review] Minor change to pick up the right dialing location. a=asa (on behalf of drivers) for checkin to 1.1
thanks Asa! I checked in the patch on Steve's behalf. Here is the protocol: cvs commit -m "DNS: lookup regression, r=adamlock, sr=darin, a=asa, local fix for autodial by s..." nsAutodialWin.cpp nsAutodialWin.h (in directory C:\build\trunk\mozilla\netwerk\base\src\) Checking in nsAutodialWin.cpp; /cvsroot/mozilla/netwerk/base/src/nsAutodialWin.cpp,v <-- nsAutodialWin.cpp new revision: 1.3; previous revision: 1.2 done Checking in nsAutodialWin.h; /cvsroot/mozilla/netwerk/base/src/nsAutodialWin.h,v <-- nsAutodialWin.h new revision: 1.2; previous revision: 1.1 done