User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008012904 Minefield/3.0b3pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008012904 Minefield/3.0b3pre I held a stopwatch and recorded installations in the AMO manager; take about an average of 1 minute 15 seconds to install, and get to the security addons dialog. This is very poor performance, and we need more investigation. Reproducible: Always Steps to Reproduce: 1. Install latest nightly 2. Search for addons to install (eg. "addon") 3. when results return, click on any of them shown, to install. 4. Verify with a stopwatch, it takes almost 1 minute 15 seconds before the security addons dialog (with the countdown) appears. Actual Results: trying to install a addon takes about 1 minute 15 seconds before getting to the security dialog window Expected Results: it shouldnt take that long. my expectation would be more around 5-10 seconds before seeing the security dialog.

Tony, can you compare the time to install when clicking on the button in the addons manager against that when clicking on the AMO site. If they are about the same then this is likely an issue with AMO serving the xpi files, if there is a big difference then I will be surprised tbh.

i am resolving this as invalid. Further investigation showed that AMO was also returning the same exact time. Turns out, i was on a cat5 connection behind some firewall, where i couldnt really see mozilla.org very cleanly. anyway, its returning < 1 second again, after switching onto a wireless network.

sending this over to IT. Please investigate why AMO responds slower internally via cat5, versus over wifi. This is when pointing to mozilla.org

Bug 414648 also talks about slow installation.

Should dupe either this bug to 414891 or dupe that bug to this one.

mrz has done some investigation, and it looks like it has to do with IPv6 not working properly in the office. However, fx3 looks like ipv6 was enabled, but fx2.0.x doesnt. Cc'ing mrz for further comments. beltzner, mconnor: For now, can we have Fx3 builds disable ipv6 settings before we ship?

Why should we disable ipv6 support in firefox because of a fault on our office's network? Or is there actually a problem with the ipv6 support in Firefox? Seems that with today's beginnings of rolling out ipv6 addresses into the central DNS servers Firefox 3 is a good time to enable ipv6 support.

(In reply to comment #7) > mrz has done some investigation, and it looks like it has to do with IPv6 not > working properly in the office. However, fx3 looks like ipv6 was enabled, but > fx2.0.x doesnt. Cc'ing mrz for further comments. What OS is this? > beltzner, mconnor: For now, can we have Fx3 builds disable ipv6 settings before > we ship? If this is Mac, we just turned IPv6 back on in bug 408881. With the Internet moving towards IPv6, we shouldn't be turning this off.

There's a single v6 release.mozilla.org mirror. OSX (and Vista for sure, maybe XP) default to looking up the AAAA address and using that first if you have a valid non-internal ipv6 address. The problem we saw last week was that the v6 router at MoCo had lost it's ipv6 tunnel to the colo but on the LAN side it was still advertising auto-discovery for attached clients. A local host would attempt to connect to releases.mozilla.org over IPv6 before timing out and falling back to v4. That was about a minute. I disabled v6 at Mountain View until I can work on the tunnel end. This could also be a problem for home users behind v6 capable home routers, most notably Apple's Airports. The Airports default to v6 on the LAN side and try to establish a tunnel to route v6 traffic. If the tunnel is broken or up but not working, hosts on the LAN side will still try v6 first. This happened to me this weekend behind Comcast - the tunnel was up but I didn't have complete v6 connectivity and couldn't get to mirrors.isc.org (the AAAA releases.mozilla.org mirror) until Fx timed out and re-tried the v4 address. Could happen to other users.

fyi, this is why it was failing on wired connections and not wifi. The BVI bridge interface doesn't pass v6 packets out wifi (or itself really which is why the v6 router is a seperate router on the wired side).