| Summary: | www-client/mozilla-firefox slow to start after network changes (direct -> proxied or no network) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gabriel Rossetti <misc> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | adrien_joel, alon.barlev, billkiller, crusaderky, D.Clermont, gentoo, misc, pentek.imre |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | mozilla-firefox-2.0.0.4.ebuild | ||
|
Description
Gabriel Rossetti
2007-03-03 16:57:53 UTC
Can you please test with mozilla-firefox-bin, see if you have the same results? (In reply to comment #1) > Can you please test with mozilla-firefox-bin, see if you have the same results? > I did and it works great. Since then I tuned down my CFLAGS but that didn't change anything on the source version. I also tried to use a new profile, still nothing. Here are my new CFLAGS : CFLAGS="-O2 -march=prescott -mmmx -msse -msse2 -msse3 -mfpmath=sse -fomit-frame-pointer -pipe" But like I said, even with those it still has that problem. I wonder if it tries to connect to the internet before it's launched (graphically) and since the proxy is wrong, it hangs for a very long timeout. (In reply to comment #2) > (In reply to comment #1) > > Can you please test with mozilla-firefox-bin, see if you have the same results? > > > > I did and it works great. Since then I tuned down my CFLAGS but that didn't > change anything on the source version. I also tried to use a new profile, still > nothing. > > Here are my new CFLAGS : > > CFLAGS="-O2 -march=prescott -mmmx -msse -msse2 -msse3 -mfpmath=sse > -fomit-frame-pointer -pipe" > > But like I said, even with those it still has that problem. I wonder if it > tries to connect to the internet before it's launched (graphically) and since > the proxy is wrong, it hangs for a very long timeout. > If this is that big of an issue you could enable a second profile. One for home one for school this would resolve your issue. *** Bug 181868 has been marked as a duplicate of this bug. *** Created attachment 121932 [details]
mozilla-firefox-2.0.0.4.ebuild
I can't reproduce this bug as i lack of network to test it.
So, please, the guys having problem with this, could you test this ebuild?
Thanks
(In reply to comment #5) Tried to use the ebuild... ebuild {ebuild} digest But... it compains that it cannot download (HTTP 404 error): http://dev.gentooexperimental.org/~armin76/dist/firefox-2.0.0.4-xpi/firefox-2.0.0.4-mn.xpi Regards -Pieter (In reply to comment #6) Sorry... had some stuff misconfigured... so it wasn't weird that I couldnot download the files. Comment #6 is now obsolete (In reply to comment #5) > Created an attachment (id=121932) [edit] > mozilla-firefox-2.0.0.4.ebuild > > I can't reproduce this bug as i lack of network to test it. > > So, please, the guys having problem with this, could you test this ebuild? > > Thanks > Ok, I'm compiling now, juste a note, if I modify /usr/bin/firefox and add some bogus text after "exec /usr/libexec/mozilla-launcher "$@" " like this : #!/bin/sh # # Stub script to run mozilla-launcher. We used to use a symlink here # but OOo brokenness makes it necessary to use a stub instead: # http://bugs.gentoo.org/show_bug.cgi?id=78890 export MOZILLA_LAUNCHER=firefox export MOZILLA_LIBDIR=/usr/lib/mozilla-firefox export MOZ_PLUGIN_PATH=${MOZ_PLUGIN_PATH:-/usr/lib/nsbrowser/plugins} exec /usr/libexec/mozilla-launcher "$@" toto it tries to open that "link" and it works, I no longer have to wait 5 mins, and it works at home and at school. I'll tell you as soon as the ebuild is done if it works. Gabriel (In reply to comment #8) Interesting... You could try to run firefox directly without using mozilla-launcher, just do 'cd /usr/lib/mozilla-firefox/' and then './firefox' (In reply to comment #9) > (In reply to comment #8) > Interesting... > > You could try to run firefox directly without using mozilla-launcher, just do > 'cd /usr/lib/mozilla-firefox/' and then './firefox' > Well, I have a new problem now.... the tabs don't work anymore. If I try ctrl + left mouse click on a link, it opens a tab but it's empty. If I try to use the contextual menu, it doesn't even open the tab... I'm going to test the 5 mins. problem now, I'll tell you how that goes. Gabriel Ok, the good news is that the 5 mins to startup problem seems to be gone. Gabriel Also good new from the Netherlands... The ebuild works fine for me, no more ~10minutes waiting time The tabs are also available! -Pieter (In reply to comment #10) > Well, I have a new problem now.... the tabs don't work anymore. If I try ctrl + > left mouse click on a link, it opens a tab but it's empty. If I try to use the > contextual menu, it doesn't even open the tab... Errr, but using what? The modified ebuild? Or calling the app directly with the normal ebuild? ---- Okay guys, since you're the only who can reproduce this and you seem that you want to help, i'll start doing some patchsets. So, when i tell you to use '1.1' for example, change the PATCH line in the ebuild. PATCH="${P}-patches-1.0" <- just modify the 1.0 by the number i'll tell you. Use 1.1 and tell me how it worked. (In reply to comment #13) > (In reply to comment #10) > > Well, I have a new problem now.... the tabs don't work anymore. If I try ctrl + > > left mouse click on a link, it opens a tab but it's empty. If I try to use the > > contextual menu, it doesn't even open the tab... > > Errr, but using what? The modified ebuild? Or calling the app directly with the > normal ebuild? > > ---- > > Okay guys, since you're the only who can reproduce this and you seem that you > want to help, i'll start doing some patchsets. So, when i tell you to use '1.1' > for example, change the PATCH line in the ebuild. > PATCH="${P}-patches-1.0" <- just modify the 1.0 by the number i'll tell you. > > Use 1.1 and tell me how it worked. > yes, it was with the modified ebuild (calling directly changed nothing) ok, I'm compiling using the 1.1 patch, I'll keep you up to date Thanks, Gabriel (In reply to comment #13) > (In reply to comment #10) > > Well, I have a new problem now.... the tabs don't work anymore. If I try ctrl + > > left mouse click on a link, it opens a tab but it's empty. If I try to use the > > contextual menu, it doesn't even open the tab... > > Errr, but using what? The modified ebuild? Or calling the app directly with the > normal ebuild? > > ---- > > Okay guys, since you're the only who can reproduce this and you seem that you > want to help, i'll start doing some patchsets. So, when i tell you to use '1.1' > for example, change the PATCH line in the ebuild. > PATCH="${P}-patches-1.0" <- just modify the 1.0 by the number i'll tell you. > > Use 1.1 and tell me how it worked. > Ok, I tested 1.1, the tabs work again, but it takes 5 mins to start. I deleted my .mozilla before, which I hadn't done with the 1.0 patch, so, I tried the 1.0 patch again with .mozilla deleted, since it seamed to work for our dutch friend, but same thing happend as it had originally with the 1.0 patch, tabs don't work right, no copy/paste in the contextual menu, and this time it too 5 mins to start (I'm at home now, so if I set the proxy, shut down firefox and restart it, it takes 5 mins with both patches) I tried to rebuild the 1.0 patched firefox with less CFLAGS, no change, I tried running it directly, no change, I then had an idea, when I added junk to the /usr/bin/firefox script, like I said earlier, it worked, no 5 min wait. What it did was try to open the junk as a link. I decided to try and tell my config to open a default webpage to see what happens. It was already selected as that, but there was no web page, so I added one and guess what, it works! For some reason, if no web page is set in the open default web page configuration (Edit->preferences->main->when firefox starts show my home page) it taks 5 mins to load when going from a proxied to a non-proxied network (without having changed the proxy settings prier to the switch). I hope that this helps find out why this is happening.... Cheers, Gabriel (In reply to comment #12) > The tabs are also available! Yesterday evening I played around with ff... but the tabs wil open... but can only browse in the first tab :( -Pieter (In reply to comment #17) > (In reply to comment #12) > > The tabs are also available! > > Yesterday evening I played around with ff... but the tabs wil open... but can > only browse in the first tab :( > > -Pieter > Yes, that's what I ment. Gabriel So, no difference between the modified ebuild and patchset 1.0 and 1.1? Only the thing that the tabs doesn't work? (In reply to comment #19) > So, no difference between the modified ebuild and patchset 1.0 and 1.1? Only > the thing that the tabs doesn't work? > Yes, exactly. I have the same problem. I built www-client/mozilla-firefox-2.0.0.4 and removed the .mozilla directory prior to first launch. The program didn't launch, so I suspected that there was a linking issue where the binary was broken. I removed the gnome use flag, in case some gnome library wasn't working properly. This didn't have any effect. Firefox did eventually come up, while I was in the process of re-emerging it, so I realized it was just incredibly slow. After finding this bug report, I suspected that the proxy I use at work might be the issue. I attempted to run firefox directly as indicated in this post, and that didn't solve any issues. I ran an strace on firefox, and found that it was attempting a direct internet connection (before I even had a browser window open!). This lead me to believe that perhaps it really was a proxy issue. I copied my old .mozilla back, and launched firefox. This worked instantly. I had used the firefox-bin package, which worked fine, but never with a fresh profile. I would have to test running firefox-bin with no .mozilla directory to repeat the issue (which I don't have time to do today). I do have an outdated profile, and my system is a bit out of date, which is why I suspected that it would be a linking issue in the first place. I have not tested the ebuilds provided here, but I can repeat the problem if I remove my .mozilla directory. Randomly saw this bug - have any of you tried disabling ipv6 resolution? I saw very slow behavior only in some network configuration with Firefox until I disabled ipv6 support. Turns out my router at home doesn't support it.... In about:config - add network.dns.disableIPv6 boolean true See: http://kb.mozillazine.org/Network.dns.disableIPv6 *** Bug 207322 has been marked as a duplicate of this bug. *** *** Bug 212719 has been marked as a duplicate of this bug. *** 1)emerge mozilla-firefox-2.0.0.12 (only active USE flags are ipv6 java) 2)rm -rf ~/.mozilla 3)fire up wireshark and have it listen to traffic 4)launch firefox I see Firefox doing a GET / HTTP/1.1 Host: www.gentoo.org This happens at every firefox startup, not just the first one. what's a lot worse is that **firefox completely locks up until it receives a response**. If the network is somehow unresponsive or unreachable, it completely locks until the request timeouts. I stress that my config is clean. The default home page is google.com. If you set it to none it still tries to retrieve www.gentoo.org/. `grep -R www.gentoo.org ~/.mozilla` returns 0 results (actually, just one in the cache as expected). This happens both on my x86/64 and my x86/32 computers. setting network.dns.disableIPv6 to true is completely uneffective (as expected). (In reply to comment #25) > 1)emerge mozilla-firefox-2.0.0.12 > (only active USE flags are ipv6 java) > > 2)rm -rf ~/.mozilla > > 3)fire up wireshark and have it listen to traffic > > 4)launch firefox > > I see Firefox doing a > > GET / HTTP/1.1 > Host: www.gentoo.org > > This happens at every firefox startup, not just the first one. > > what's a lot worse is that **firefox completely locks up until it receives a > response**. If the network is somehow unresponsive or unreachable, it > completely locks until the request timeouts. > > I stress that my config is clean. > > The default home page is google.com. If you set it to none it still tries to > retrieve www.gentoo.org/. > > `grep -R www.gentoo.org ~/.mozilla` returns 0 results (actually, just one in > the cache as expected). > > This happens both on my x86/64 and my x86/32 computers. > I have the same problem with mozilla-firefox-2.0.0.13. Firefox tries to connect to the page mentioned in /usr/lib/mozilla-firefox/defaults/pref/all-gentoo.js: pref("browser.startup.homepage", "http://www.gentoo.org/"); If DNS or the page itself is unreachable firefox waits until the request timeouts. (In reply to comment #27) As a workaround you can just change /usr/lib/mozilla-firefox/defaults/pref/all-gentoo.js: -pref("browser.startup.homepage", "http://www.gentoo.org/"); +pref("browser.startup.homepage", "about:blank"); Since "about:blank" is always reachable firefox does not lock up at startup, even if network is unreachable. How is firefox3 doing with this issue? immediately after wiping ~/.mozilla and starting mozilla-firefox-3.0-r1, browser.startup.homepage DOES still point to http://www.gentoo.org contrarily to what one could imagine, the startup URL in the basic firefox preferences is blank. Please make firefox run correctly without network or access to www.gentoo.org. It is very annoying issue, especially accessing your modem while having no connectivity. I forgot to say it doesn't point anymore to gentoo.org *** Bug 232472 has been marked as a duplicate of this bug. *** Noone has reported in almost a year as to status closing for now, feel free to reopen if the problem is still there. |
