User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212 Build Identifier: MachO nightly of today The MachO nightly installs and runs, very fast, but when you have to check the mail or navigate, it waits indefinitely for a connection which does not arrive. If I run other browsers, I can navigate. Is there something special to set? Reproducible: Always Steps to Reproduce: 1. 2. 3.

I experienced this for the first (and hopefully only) time today. Mac OS X 10.2.3 Mozilla Mach-O 2003020603 DSL connection using PPPoE Mozilla had been running fine previously. I quit Mozilla, later started it up again (the computer had gone to sleep) and it would not connect to anything. I started up IE and that worked fine. Quitting Mozilla resulted in a crash (crashlog is attached), and starting it up again everything went back to normal. Maybe it's just a coincidence and part of a sleep bug in OS X?

I have installed 1.3b and did not work, but I relauched it and now works.

Now I have enquired more. to reproduce the bug 0) disconnect from the Internet 1) launch MachO, working online 2) connect to the Internet via DHCP (I don't know if via modem this works) 3) check mail you see Mozilla checks but cannot connect. If you swap point 2 with point 1, you will see everything works out fine!

This works for me w/ Mozilla 1.3b. I'm using DSL w/ PPPoE set with "Connect automatically when needed." Giovanni: are you using just ethernet, or PPPoE? I need a better description of how you "connect" via ethernet and DHCP. Joseph: please put your problem into a new bug w/ a link to the crashlog you added here. I saw some sluggishness, but no crash.

Now I am using a PPP dial-up connection and the problem is the same. It seems that Mozilla cannot use the feature offline/online. That is: 1) connect to the internet via dialup PPP 2) launch mozilla then if you launch Mozilla AFTER the established connection, it works if you launch it BUT the connection is still not established, it does not work, you have to relaunch Mozilla - About the other type of connection, I have a breadband but no PPP nor ADSL, it is a service we in Italy have, Fastweb, it connects directly via a DHCP and ethernet to a device called HAG. Will be more precise tomorrow.

By chance I discovered new facts: 1) connct via dialup PPP 2) launch mozilla and work with it 3) drop the connection and put the powerbook to sleep (I have G3 lombard with 10.1.5) 4) wake up, connect via dialup PPP 5) turn to Mozilla and use it: IT WORKS REALLY GREAT! 6) send long email attachment 4500 [details]kb) 7) unfortunately while sending, drop the connection 8) re-connect same way without stopping the upload: IT WORKS GREAT! So it seems the bug is at the very first time you launch Mozilla.

Confirming. This is bad. Setting critical and blocking1.3? (this needs to get fixed before 1.3) If you launch Mozilla without an active network connection, and then connect, Mozilla will behave as though it can't connect to the network ("www.mozilla.org couldn't be found..." etc.), forcing you to relaunch (apparently it never re-checks to see if there is an active connection). This is not a problem with online/offline mode (you can switch back and forth all you want, it makes no difference), and only occurs if Mozilla starts up before a connection is established. Mac OS X 10.2.4, Mozilla 1.3b, dialup connection. (There was a similar problem with the classic Mozilla a couple of years ago.)

gordon, simon: can either of you take this bug? thx!

We need this for 1.3. Who can help?

over to simon. bounce if you don't have time.

The answer probably lies in http://developer.apple.com/technotes/tn/tn1145.html This is going to be in NSPR, I think.

simon: i didn't read much of that link, but i just wanted to point out that we have autodial code for windows that lives outside NSPR. please see nsSocketTransport::RecoverFromError ... maybe this could be done using a similar solution.

Mozilla succesfully causes the modem to autodial for me. However, I can reproduce this problem by: 1. Pull out network cable 2. Launch mozilla, note that it can't find the host for the homepage 3. Put network cable back in. 4. Hit reload. Mozilla continues to fail to connect until restarted.

simon: does toggling the online/offline switch make any difference?

I believe this is my fault. When I added IPv6 support for Mac OS X, I added a lookup for the IPv4 and IPv6 network addresses of the local machine during NSPR initialization. The result of the lookup is used by PR_GetIPNodeByName to determine if it needs to return IPv4 or IPv6 addresses. If NSPR is initialized while the local machine is off line, PR_GetIPNodeByName will remember that the local machine has no IPv4 and IPv6 network addresses and will not return any address. I suspect that removing IPv6 support will fix this problem. I will attach a patch for you to try.

The issue here seems to be that _pr_have_inet_if in prnetdb.c never gets set back to 1 when the network becomes available.

Simon is right. Please try reverting mozilla/nsprpub/pr/include/md/_darwin.h to rev. 3.10.4.1 and recompile nsprpub. (No need to recompile anything outside nsprpub.) # change directory to the top of your build tree % cd nsprpub % make clean % make

My current thinking is that NSPR needs to register with the System Configuration framework to get notified when the available network interfaces change.

Yeah, reverting _darwwin.h fixes this. Should we proceed with the "correct fix" (listen for system configuration changes), or should we back out IPv6 for Darwin? FWIW, I've had requests that Chimera support IPv6, so it is wanted. What other issues in http://developer.apple.com/technotes/tn/tn1145.html do we need to address? Does NSPR deal with the local IP address changing?

Note that it's easy to reproduce this bug by just toggling the network ports in the Network system prefs panel. You don't have to pull any wires out of the wall.

IPv6 is not tested by QA, so if you need to make this work for 1.3f and we are running out of time, get rid of it for the purposes of the release.

I think fixing this bug is more important than IPv6 support. We should back out the IPv6 support change in mozilla/nsprpub/pr/include/md/_darwin.h, and work on the long term solution. Listening for system configuration changes is not portable. Ideally I want a portable solution because the same code is also used for AIX and FreeBSD, although I don't think there are enough laptops running AIX or FreeBSD to make this a serious problem for their users.

I have a chunk of sample code that listens for network configuration changes on OS X. Of course, we'd have to wrap this in the usual nest of NSPR defines, so that other platforms can implement it in different ways. I guess, for now, we can just #if 0 the IPv6 stuff in _darwin.h.

Keep looking up the local IP addresses as long as there are none. This will allow us to detect the transition from offline to online. NSPR does not care about the actual addresses but rather whether the local host has any IPv4 or IPv6 network interfaces. Please try this patch.

Comment on attachment 114979 [details] [diff] [review] Proposed patch this patch makes sense, but what if someone has an IPv6 interface up and running, but then shuts it down (possibly replacing it with an IPv4 interface)? how is the online to offline transistion handled?

The online to offline transition won't be detected, but PR_GetIPNodeByName fails anyway when the machine is offline. When the machine goes online again, PR_GetIPNodeByName will use the IPv4 and IPv6 interface presence information it obtained previously, which will be correct except for the following cases, which I don't think are likely to happen in practice: ... IPv4 interface up -> offline -> IPv6 interface up ... or ... IPv6 interface up -> offline -> IPv4 interface up ... etc. Another way to look at this patch is that although it can't handle some rare cases, it is strictly better than what we have now.

Comment on attachment 114979 [details] [diff] [review] Proposed patch ok, that's what i thought. thanks for the detailed explanation :) r=darin

did this problem affect people who are not using IPv6? I never got my system to break, and I know I'm IPv4-only.

I don't know what IPv6 is, but even if I use dialup connection Mozilla does not work if the connection is established after Mozilla is launched.

This bug was introduced by my change to add IPv6 support but it has nothing to do with IPv6.

Comment on attachment 114979 [details] [diff] [review] Proposed patch Patch checked into the NSPR TIP (NSPR 4.3) and the NSPRPUB_PRE_4_2_CLIENT_BRANCH (mozilla 1.4alpha).

*** Bug 194592 has been marked as a duplicate of this bug. ***

*** Bug 194476 has been marked as a duplicate of this bug. ***

*** Bug 194479 has been marked as a duplicate of this bug. ***

Comment on attachment 114979 [details] [diff] [review] Proposed patch We'd like to get this for 1.3. Can someone make sure it's landed for the 1.3 branch? Thanks.

wtc, can you land this for us for 1.3? we're getting close and need everything in asap.

Patch checked into the MOZILLA_1_3_BRANCH (mozilla 1.3 final). Marked the bug fixed.

Thanks Wan-Teh.

Giovanni: Can you try a new build? I was not able to reproduce this bug (hence all my questions to wtc...) so I don't think I could safely verify this fix.

ok, I'm going to download the current build

OK, with ethernet DHCP direct connection it works now. I launched Mozilla and then connected manually to the net, it works!

I've tried: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030325 as well as the 1.3 final release and the bug still seems to be there. 1) Quit Moz 2) Disconnect from network (Airport in my case) 3) Start Moz 4) No connections (domain not found) 5) Connect to network 6) Still no connections (domain not found) Reproducible: Always Maybe it is caching the result of "I can't connect now so I won't bother trying"???

VERIFIED: Giovanni - based on your comments, as reporter, I'm verifying this. Paul, please try a newer version and see if you have the same problem. If so, file a new bug.

VERIFIED FIXED: I just tried in a recent 1.6 build and everything seems to work fine. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 Great Job! Thanks!