User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021212 I'm running a Powerbook g4 with osX.2.3 and have 2 possible connections to the internet: the hardwire builtin ethernet or the wireless. Both connections run through a linux router and both are configured manually (no dhcp). When browsing with the ethernet, everything works great. When I switch over to the wireless, many pages don't load. I can ping the URL's, I can even browse to the URL in IE, but they are broken in Mozilla 1.2, 1.3a, Chimera, and Netscape 7 (whichever builds are available on the downloads page). Example: When loading any pages at google.com under ethernet, the pages load quickly and correctly. If I am browsing on the wireless (using the built in airport card) the pages don't load (unless cached, but then images still don't load). I get "Sending request to www.google.com..." in the status bar while it is hanging. Eventually the request times out with "The document contains no data." A majority of pages do load in wireless if I haven't visited them while connected to ethernet (I tried this with random domains off the top of my head, www.homestarrunner.com for example. They continue to load in ethernet and remain working in wireless. Reproducible: Always Steps to Reproduce: 1.Browse to a new domain under ethernet. 2.Disconnect ethernet, begin browsing on the wireless network. 3.Visit a page on the domain again. Actual Results: Webpage doesn't load, hangs with "Sending request to www.google.com...". Eventually times out with "The document contains no data." Expected Results: Should have resolved the domain regardless of what network device was being used both at the time of visit and at the initial visit. This is all happening on a new powerbook with nothing extra added. Mozilla was the first thing installed on OSX.2.3. Network connections work under both devices (can ping sites that are hanging in mozilla, and can visit said sites in IE). Any assistance is appreciated, I really hate going to IE when I need to disconnect the ethernet. Cheers!
Also, Browsing by IP address works in wireless, it seems to only be a problem with DNS resolution.
*** Bug 186980 has been marked as a duplicate of this bug. ***
does it work when you restart Mozilla ? or by switching offline/online mode ? I have this issue too when connecting to a VPN server while Mozilla is running, Linux only (does not affect Win32 platforms). similar: bug 109313, bug 150729, bug 146769, bug 162871.
After viewing those threads, I can see why restarting or cycling [on|off]line would work... however, it doesn't. I've even tried uninstalling, reinstalling, and installing different versions. This seems to be a bit deeper than simple dns resolution, since the sites that are broken have been resolved at one point, and continue to work while connected via ethernet. Only when forcing a switch to the wireless device (by unplugging the ethernet cable) does this problem occur. The sites continue to work again after the ethernet is reconnected. If you notice there's a duplicate of this bug that i posted (which has just been verified). I posted that while on wireless and then cancelled, plugged in ethernet, and posted it again. It seems to have put the original post in a buffer and sent it out when it could do so again. (I apolagize for the duplicate, it was unintentional) I can verify this behavior in iChat also. I can IM people normally while using the ethernet, but when I disconnect it seems to put all my ims, and all of their im's in a queue somewhere. When I reconnect the ethernet cable the IMs I was supposed to receive come in in quick succession, and the IMs I sent out are received by my friends in quick succession also after I connect the ethernet. I would consider this merely a bug with OSX networking (which it may well be), however IE somehow gets around it, and I can still ping the addresses on the console. I'll have the opportunity in a few days to attempt a different wireless network, and several other networks in the following week.
I've run mozilla on several other WAPs now and have had problems only on the original access point, a Linksys Instant Wireless series Wireless Network Access Point. Mozilla is the only application affected (iChat seems to work with this particular access point now), and it only seems to happen on this WAP. If there's any kind of diagnostic information which could help pinpoint the problem, please let me know and I'll see what I can do. I do know requests are being sent out, however no data is being returned. Once again, this only happens with Mozilla on this particular AP on MacOSX. I will try to get my hands on another AP of the same make/model to eliminate a faulty AP from being the problem.
I noticed recently that Mozilla did not seem to auto-refersh DNS server changes as well as it had in the Mozilla 1.0 timeframe. I need to look at this problem further, as well as ponder your comments again. The most important item I want to verify is that IP addresses work fine for you. Also, if you follow your steps, if you quit mozilla, and restart it w/ ethernet still off, does it work okay?
Jaroslav, can you still reproduce this problem using a current nightly build?
This sounds a lot like bug 178296
Please don't confirm bugs based solely on a similar bug in Bugzilla. Furthermore, do take a moment to fully read the bug. As it states in bug 178296 comment 0, "The problem does NOT show up when switching interfaces, for example: from wired network to AirPort. Everything works properly when this is the scenario."
I have this issue pop up and I was able to fix it by "repairing" the wireless connection and Mozilla would work fine. But now I have hit a road block and i think it is because of a new software installation - I intalled the O2 software which manages the PDA/phone from the laptop. Now Mozilla does not want to work at all. If I have a wired connection it works fine. what the deal?
mass reassigning to nobody.
Do you still see this problem when using Firefox 3?
@Reporter, we have not heard back from you in a while, so I am closing this bug as INCOMPLETE. You can reopen this bug if more information becomes available.