Closed Bug 637286 Opened 9 years ago Closed 9 years ago

Firefox4 freeze and is unusable when I try to open add-ons tab with Extensions pane selected

Categories

(Toolkit :: Add-ons Manager, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla5
Tracking Status
blocking2.0 --- Macaw+
status2.0 --- .1-fixed

People

(Reporter: lylambda, Assigned: mwu)

References

Details

(Keywords: hang, Whiteboard: [mozmill-test-needed][mozmill-endurance])

Attachments

(7 files, 6 obsolete files)

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre

Firefox4 freeze when I try to open add-ons's tab (visible here : http://uppix.net/7/d/9/da9282255ce693eb0fabf04f3b153.png). Then, the browser is unusable (no interactions) and I need to kill the process. Strangely, CPU didn't increase during the freeze.

That's seems to depend about the number of add-ons, not about a specific one.
This freeze happen exclusively when I installed more than 21 add-ons (compatibles). Less, the add-ons's tab can be open and all is okay. Just at 21 add-ons, the tab is hard to open (apparency incomplete) but no freeze.

Reproducible: Always

Steps to Reproduce:
1. Install more than 20 add-ons
2. Restart after install the last
3. Try to open add-ons's tab
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre

Tried to reproduce issue but I was unable. Can you please try it again using a clean profile? And maybe try selecting other add-ons - just to make sure that it's not because of an add-on that FF freezes.
Component: General → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: general → add-ons.manager
Version: unspecified → Trunk
Please list all of the addons you have installed. As best with URLs so we can quickly try to reproduce. Otherwise go to your profile, zip the extensions folder, and attach it to this bug.

I highly suspect an add-on issue is the cause here.
Severity: major → critical
Keywords: hang
It's a big possibility but I can't see which did that. I will create a new profile as soon as possible.

In my last test, I obtained a profile with which the bug happen not all time (first try, tab opens correctly, but the freeze happen all time during the second). It's better for install an add-on for create a list's extensions : [http://dl.free.fr/pmgOYIgB9]
I can upload a zip folder's extensions if that can help.

With this profile, enable or add one more extension give the systematic freeze (I try with "all-in-one sidebar 0.7.13rc1" and "Image Zoom 0.4.6").
PS : Select the little link "Télécharger ce fichier" for download the html list.
So I have tested with a new profile. When I put the extensions, the bug came back… I can't discover which does that. Maybe it's due to a combinaison of both or more ?
Duplicate of this bug: 644545
Same problem here with FF4 stable and a clean profile. In my case on Linux 64bits.
I've tested several times with several clean profiles and different add-ons, but it hangs always. In my case, the limit is 31 extensions.

By other side, the argument "...because of an add-on that FF freezes." isn't valid for me. IMHO, no add-on should be able to hang the manager add-ons.
In Firefox < 4 this isn't occur.
(In reply to comment #8)
> Same problem here with FF4 stable and a clean profile. In my case on Linux
> 64bits.
> I've tested several times with several clean profiles and different add-ons,
> but it hangs always. In my case, the limit is 31 extensions.

Are you saying that as soon as you have 31 add-ons it starts hanging, or something else?
(In reply to comment #9)
> (In reply to comment #8)
> > Same problem here with FF4 stable and a clean profile. In my case on Linux
> > 64bits.
> > I've tested several times with several clean profiles and different add-ons,
> > but it hangs always. In my case, the limit is 31 extensions.
> 
> Are you saying that as soon as you have 31 add-ons it starts hanging, or
> something else?

Well, now I'm doing more tests and the number is variable (~30) in function of the extensions. Perhaps is a problem of kb? 
with extensions folder >= 13880 KB it hangs.
(In reply to comment #10)
> Well, now I'm doing more tests and the number is variable (~30) in function of
> the extensions. Perhaps is a problem of kb? 
> with extensions folder >= 13880 KB it hangs.

How long does it hang?
ive got the same prob on ubuntu maverick 64bit
it seems a bit erratic to me, its both about how many addons but also about which addons. my extensions folder is 6.2mb and ive got 23 addons (not including the ones deemed not compatible such as prism and firefox notify) -  and i badly need 5-10 more extensions to make it as useable as 3.6x

some addons can be added without any problems, others cant, its about trying and failing (mostly failing)

when it hangs it hangs forever(well ive only let it hang for about 10 mins at max), its not using any cpu at all, its just dead

is there a way to go back to the old addons manager?
(In reply to comment #11)
> (In reply to comment #10)
> > Well, now I'm doing more tests and the number is variable (~30) in function of
> > the extensions. Perhaps is a problem of kb? 
> > with extensions folder >= 13880 KB it hangs.
> 
> How long does it hang?

In my case, more than 30 minutes and so on...

(In reply to comment #12)
> is there a way to go back to the old addons manager?

Same question.
If you enable extensions.logging.enabled and devtools.errorconsole.enabled and then restart, open the add-ons manager, wait for it to hang and then open tools - error console are there any messages listed?
(In reply to comment #14)
> If you enable extensions.logging.enabled and devtools.errorconsole.enabled and
> then restart, open the add-ons manager, wait for it to hang and then open tools
> - error console are there any messages listed?

I did this. The hang happened but the error console did not appear.

Note that it hangs only if I am on the Extensions tab of the Add-on Mgr, or i switch to it. Is this what others are seeing too? Once it hangs the only way out that I know is to kill the process.
The attachment is compressed using XZ, use 7z on Windows to open/unpack it.

I'm running the official Linux binary on Fedora 14 i686.
(In reply to comment #14)
> If you enable extensions.logging.enabled and devtools.errorconsole.enabled and
> then restart, open the add-ons manager, wait for it to hang and then open tools
> - error console are there any messages listed?

Error console also hangs as soon as you try to open Add-ons manager, so you cannot see anything in it.

The only messages that I see logged in the usual Linux console are:

$ firefox
*** LOG addons.xpi: startup
*** LOG addons.xpi: checkForChanges
*** LOG addons.xpi: No changes found
*** LOG addons.xpi: Opening database
*** Blocklist::_loadBlocklistFromFile: blocklist is disabled
(hang, no messages)
(In reply to comment #1)
> Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre
> 
> Tried to reproduce issue but I was unable. Can you please try it again using a
> clean profile? And maybe try selecting other add-ons - just to make sure that
> it's not because of an add-on that FF freezes.

Firefox _may_ or _may not_ hang with _the same set_ of extensions at different times. E.g. yesterday I could open add-ons manager, today it causes the browser to hang. In the meantime I've nothing except visiting new/old websites (i.e. I didn't install/uninstall/change any of my extensions).
Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110327 Firefox/4.2a1pre SeaMonkey/2.2a1pre ID:20110327003001

SeaMonkey almost always hangs (usually, but not always, at extremely low CPU%) when I try to open the "Extensions" tab in about:addons (but it doesn't hang in Safe Mode). Once hung, the ps utility reports, in the WCHAN column for seamonkey-bin (and plugin-container if running) the label futex_wait_queue_me (the label may be truncated unless the WCHAN column is widened by e.g. "-o wchan:25" (without the quotes) on the ps command-line). The program still reacts to kill -15 but not to the keyboard or mouse. I have reproduced this problem a few minutes ago in this nightly. I have reported this problem (which also, but more rarely, happens in other circumstances) as bug 570316, to which my list of addons (from about:support) is attached. Duplicate?
(In reply to comment #20)
> I have reported this problem (which
> also, but more rarely, happens in other circumstances) as bug 570316, to which
> my list of addons (from about:support) is attached. Duplicate?

I doubt it, SeaMonkey and Firefox have quite different add-ons managers.
(In reply to comment #21)
> (In reply to comment #20)
> > I have reported this problem (which
> > also, but more rarely, happens in other circumstances) as bug 570316, to which
> > my list of addons (from about:support) is attached. Duplicate?
> 
> I doubt it, SeaMonkey and Firefox have quite different add-ons managers.

Your information is outdated since 2009.

Until version 1.x inclusive, SeaMonkey could use extensions but it had no add-on manager to speak of.

However, not mentioning alpha and beta builds, SeaMonkey 2.0 (built on 2009-10-27) and later uses the Toolkit addon manager, just like Firefox and Thunderbird, and the "new addon manager" affected SeaMonkey 2.1 and later exactly like it affected Firefox 4.0 and later.
I have this exactly this problem too. firefox hangs when i opening my addon manager. 

Version: firefox 4 
OS: Fedora 14

please fix this bug :(
Same problem here with both offical firefox build and firefox-pgo (aur ) on Archlinux 64 bit

i have experienced this problem especially with some addons , not at all. 

 fireftp
 downthemall
 imacros
 all in one sidebar
Does this hang also happen when the Add-ons manager gets opened with another pane and then switched to Get Add-ons?
(In reply to comment #25)
> Does this hang also happen when the Add-ons manager gets opened with another
> pane and then switched to Get Add-ons?

"Extensions", not "Get Add-ons". about:addons is one of the tabs of my multitab homepage, and it starts up, correctly, at whichever pane was used latest (usually "Available updates" or "Recent updates"). When I click "Extensions", I get the hang and need to kill the application.
Confirming by popular vote.
Status: UNCONFIRMED → NEW
Ever confirmed: true
That's in your case with SeaMonkey. I really would like to get feedback from users of Firefox. It's not clear yet by all the comments which pane is selected when the AOM gets opened and the hang appears.
In reply to comment #29
OK, well, Firefox users, please speak up.

FTR, and in the light of comment #10, I have ATM 39 enabled addons plus a number of disabled ones. See bug 570316 attachment #499688 [details] for what they were on 2010-12-24.
(In reply to comment #29)
> That's in your case with SeaMonkey. I really would like to get feedback from
> users of Firefox. It's not clear yet by all the comments which pane is selected
> when the AOM gets opened and the hang appears.

For me it hangs when I try to see the list of installed extensions ("Extensions" on the left) - it never hangs on any other AOM's vertical tab.

However like I've said scores of times, Firefox _may_ or _may not_ hang when I open OR switch to AOM's "Extensions". I haven't established a pattern, but I've found out that it depends on a day, like e.g. yesterday Firefox hung, today it works ;)
Ok, thanks. Lets get the summary updated to reflect the real issue. I will try later to get this hang reproduced on my box.
Summary: Firefox4 freeze and is unusable when I try to open add-ons tab → Firefox4 freeze and is unusable when I try to open add-ons tab with Extensions pane selected
seems it has something to do with memory usage. i just checked the mem tab in the system monitor and ff was using 350mb ram or so and launched the addons manager and it froze (yes only on the extensions tab) and had to kill ff , restart(all cache gone), 140mb used, extensions tab no problem

oh and btw, its not just the extensions tab in the addons manager that causes this freeze, this addon that displays a list of the installed extensions from a toolbar button also causes the same freeze when clicked https://addons.mozilla.org/en-US/firefox/addon/extension-options-menu/

this is really a killer for me, tempted to go back to 3.6x until natty and hope this has been fixed by then. luckily i saved the ff3 profile

seems to happen only on 64 bit linux tho?
(In reply to comment #33)
> seems it has something to do with memory usage. i just checked the mem tab in
> the system monitor and ff was using 350mb ram or so and launched the addons
> manager and it froze (yes only on the extensions tab) and had to kill ff ,
> restart(all cache gone), 140mb used, extensions tab no problem

Hardly related IMO.

> 
> oh and btw, its not just the extensions tab in the addons manager that causes
> this freeze, this addon that displays a list of the installed extensions from a
> toolbar button also causes the same freeze when clicked
> https://addons.mozilla.org/en-US/firefox/addon/extension-options-menu/
> 
> this is really a killer for me, tempted to go back to 3.6x until natty and hope
> this has been fixed by then. luckily i saved the ff3 profile
> 
> seems to happen only on 64 bit linux tho?

32 bit here, the same issue.
Can I just confirm that this is only happening on Linux? Is there anyone seeing this on Windows or OSX?

What distro are you all using and are you using the Firefox downloaded from mozilla or one provided by your distro's package manager?
I am using Fedora 14. 32  bit.
I downloaded Firefox 4 from mozilla website.
(In reply to comment #35)
> Can I just confirm that this is only happening on Linux? Is there anyone seeing
> this on Windows or OSX?
> 
> What distro are you all using and are you using the Firefox downloaded from
> mozilla or one provided by your distro's package manager?

No ones wants to read the previous comments :)

Fedora 14, i686 with all updates installed.
Vanilla kernel 2.6.38.1.
NVIDIA binary drivers 270.30.
The official Firefox 4 binary from releases.mozilla.org

Quite a lot of extensions. Absolutely random hangs/freezes depending on a time of day so it's practically impossible to establish if any of installed addons is to be blamed for this issue.

A complete strace of firefox (with a hang) is attached earlier (comment #17).
i got it from the mozillateam stable ppa
(In reply to comment #35)
> Can I just confirm that this is only happening on Linux? Is there anyone seeing
> this on Windows or OSX?
> 
> What distro are you all using and are you using the Firefox downloaded from
> mozilla or one provided by your distro's package manager?

Ubuntu 10.10 amd64
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0

- Opening Extensions pane of Add-on Manager causes browser to hang indefinitely.
- This happens if more than N extensions are enabled (N seems to vary.)
- This happens consistently...except on the few occasions when some yet to be discovered planets are perfectly aligned.
(In reply to comment #35)

> What distro are you all using and are you using the Firefox downloaded from
> mozilla or one provided by your distro's package manager?

I got Firefox from:
http://ppa.launchpad.net/mozillateam/firefox-stable/ubuntu
(Ubuntu 10.10 amd64)
Comment 20 suggests that it doesn't hang when starting in safe mode, is the same true of Firefox?

http://support.mozilla.com/en-US/kb/Safe%20Mode
(In reply to comment #41)
> Comment 20 suggests that it doesn't hang when starting in safe mode, is the
> same true of Firefox?
> 
> http://support.mozilla.com/en-US/kb/Safe%20Mode

I couldn't reproduce this problem in safe mode. But then I'm not sure if it doesn't trigger with just one extension installed.
(In reply to comment #41)
> Comment 20 suggests that it doesn't hang when starting in safe mode, is the
> same true of Firefox?
> 
> http://support.mozilla.com/en-US/kb/Safe Mode

That's correct. It does not hang in Safe Mode -- in fact, to keep it from
hanging, I launch it in safe mode, disable a few extensions, then restart it.

I've seen this w/ multiple profiles, and the no. of enabled extensions that apparently triggers this isn't always the same.
(In reply to comment #43)
> (In reply to comment #41)
> > Comment 20 suggests that it doesn't hang when starting in safe mode, is the
> > same true of Firefox?
> > 
> > http://support.mozilla.com/en-US/kb/Safe Mode
> 
> That's correct. It does not hang in Safe Mode -- in fact, to keep it from
> hanging, I launch it in safe mode, disable a few extensions, then restart it.

Does that mean that it also doesn't hang in normal mode but with many of your extensions disabled? That is the hang only happens with a lot of extensions enabled at the same time?
(In reply to comment #44)
> Does that mean that it also doesn't hang in normal mode but with many of your
> extensions disabled? That is the hang only happens with a lot of extensions
> enabled at the same time?

Correct.
Not getting very far in reproducing this on my system as yet. It might be helpful for people that are seeing this to zip up their profile folder and email it to me directly
(In reply to comment #46)
> Not getting very far in reproducing this on my system as yet. It might be
> helpful for people that are seeing this to zip up their profile folder and
> email it to me directly

I've sent you my profile sans sensitive information. *Right now* when I try to invoke AOM, Firefox freezes. It *didn't* happen just three hours ago. :)
(In reply to comment #35)
> Can I just confirm that this is only happening on Linux? Is there anyone seeing
> this on Windows or OSX?
> 
> What distro are you all using and are you using the Firefox downloaded from
> mozilla or one provided by your distro's package manager?

I'm on openSUSE Linux, currently 11.4, before that 11.3 and before that 11.2.
I'm using SeaMonkey trunk builds downloaded from Mozilla. I reported the problem (as bug 570316, now duped to here) with a build datestamped 2010-05-10 (running on openSUSE Linux 11.2) but it may have happened earlier. I saw this on i386 (on a single-core machine) and I still see it on x86_64 (on a twin-core Pentium 4). Both machines had 2 GiB RAM. SeaMonkey is typically my most memory-hungry process, followed at some distance by Xorg, the rest are far behind.

I haven't yet noticed anyone who had this bug except on Linux.

I don't see this in Safe Mode. In December I saved my list of extensions from about:support, see comment #30 above. ATM I have some 39 extensions enabled, which seems to be enough to trigger the bug whenever I go to the addons manager's Extensions pane.

Whenever this hang happens, I notice that the ps utility reports "futex_wait_queue_me" in the WCHAN column for seamonkey-bin.

Dave, I'm willing to send you a .tar.bz2 of my profile, but it is a *SeaMonkey* profile, including browser data, mail messages, ChatZilla logs, etc., so please confirm if you are interested.
Here's is a gdb backtrace from my machine when firefox hangs.
(In reply to comment #49)
> Created attachment 522696 [details]
> Firefox's gdb backtrace when hanging.
> 
> Here's is a gdb backtrace from my machine when firefox hangs.

Awesome that gives us some good clues.

Looks like we might be deadlocked in the zipreader cache after reading a localised description. Taras, I think you know some of this code, any ideas why we might be hitting this?
I'm looking at this. It might be related to mwu's omnijar work
(In reply to comment #46)
> It might be helpful for people that are seeing this to zip up their profile
> folder and email it to me directly

Is it always necessary to send you some profile with the bug ? If yes, I can send one quickly.
Looks like a zip1->release -> zipcache->release -> zip2->release -> zipcache->release deadlock. Doesn't explain why it's linux only but at least we're getting somewhere.

One interesting thing to try may be to set the pref extensions.alwaysUnpack to true. It may be related to the nested jar code. Setting this pref and reinstalling packed extensions will avoid using the nested jar code path.
(In reply to comment #52)
> (In reply to comment #46)
> > It might be helpful for people that are seeing this to zip up their profile
> > folder and email it to me directly
> 
> Is it always necessary to send you some profile with the bug ? If yes, I can
> send one quickly.

No in general we don't need it, but sometimes when we are having difficulty reproducing a problem it can help to be testing it out with exactly the same settings that you are using
(In reply to comment #53)
> Looks like a zip1->release -> zipcache->release -> zip2->release ->
> zipcache->release deadlock. Doesn't explain why it's linux only but at least
> we're getting somewhere.
> 
> One interesting thing to try may be to set the pref extensions.alwaysUnpack to
> true. It may be related to the nested jar code. Setting this pref and
> reinstalling packed extensions will avoid using the nested jar code path.

Additionally, it would help to get some logs prior to setting mwu's pref.

Please do something like 
export MOZ_JAR_LOG_DIR=/tmp/jarlog/
 (trailing / is important)
Then run firefox and get it into a deadlock state. This should give us a good idea of what jar is causing this.
looks like u ppl are getting somewhere. im not as technically advanced as you are but i set extensions.alwaysUnpack to true and that really made a difference.

unfortunately a bad one.instead of firefox hanging my whole ubuntu maverick 64 hung and i found no other solution other than using the reset button. it was completely stuck

i repeated this twice just to be sure
(In reply to comment #55)
> Additionally, it would help to get some logs prior to setting mwu's pref.
> 
> Please do something like 
> export MOZ_JAR_LOG_DIR=/tmp/jarlog/
>  (trailing / is important)
> Then run firefox and get it into a deadlock state. This should give us a good
> idea of what jar is causing this.

I just created a new profile and installed several add-ons. I launched firefox w/ MOZ_JAR_LOG_DIR set as you suggested. Attached are the jarlogs that were generated.
Attachment #522819 - Attachment description: jar logs after hang → jar logs after hang (happened at the first launch after the add-ons were installed in a fresh profile.)
Attached patch safest fix (obsolete) — Splinter Review
The problem is in zipreader cache code. We didn't catch it in our testing because one has to have >16 zips(extensions) to trigger it. Will get rid of the cache on trunk to get rid of this special case.
Assignee: nobody → tglek
Attachment #522821 - Flags: review?(mwu)
(In reply to comment #58)
> Created attachment 522821 [details] [diff] [review]
> safest fix
> 
> The problem is in zipreader cache code. We didn't catch it in our testing
> because one has to have >16 zips(extensions) to trigger it. Will get rid of the
> cache on trunk to get rid of this special case.

Can you please drop a note here when the fixed trunk version is available?
Attachment #522821 - Flags: review?(mwu) → review+
(In reply to comment #59)
> 
> Can you please drop a note here when the fixed trunk version is available?

https://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tglek@mozilla.com-c4df5f3a4e89/

The 64bit build is ready now, 32bit is still building. Would be nice to get confirmation that this fixes the problem.
Keywords: checkin-needed
Blocks: 504217
Not sure why this is only affecting Linux based on what we know at this point but I think we should be spinning out a fix in a .x release.

Taras, is there a way we can automatically test this issue or is it too timing dependent?
blocking2.0: --- → ?
(In reply to comment #60)
> https://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tglek@mozilla.com-c4df5f3a4e89/
> 
> The 64bit build is ready now, 32bit is still building. Would be nice to get
> confirmation that this fixes the problem.

Did the following w/ the 64-bit build:

- exploded the tar.bz2 in ~/temp/
- launched it w/ the same profile as the one in comment #57 using the following script:
===
#!/bin/bash

cd /home/aslam/temp/firefox

export MOZ_JAR_LOG_DIR=/tmp/jarlog-fix/
./firefox -P tempProfile -no-remote &

exit
===

If this is the correct way to test, then this build does _not_ fix the hang.
(In reply to comment #60)
> (In reply to comment #59)
> > 
> > Can you please drop a note here when the fixed trunk version is available?
> 
> https://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tglek@mozilla.com-c4df5f3a4e89/
> 
> The 64bit build is ready now, 32bit is still building. Would be nice to get
> confirmation that this fixes the problem.

I've tested it (on Ubuntu 10.04 64bits) and for me works. Although there are extensions that have been disabled because they do not recognize the version 4.0pre.
To compensate for that were disabled, I installed some more and it still works correctly.
Well, there is still a problem. If after it restarts, after to install an extension, it is in "Get Add-ons" page and, while it load that page, I change to Extensions, it hangs.
unfortunately this new build behaved exactly like the regular ff4 on my ubuntu maverick 64. i added the exact same extensions that ff4 regular could handle before it would hang and, like on ff4 regular, it hangs on the extension tab if i add one more :(
Keywords: checkin-needed
Try both Tara's build, and rebuild Firefox 4 with Tara's patch, firefox still freeze for me. 
The work around to set the pref extensions.alwaysUnpack to true then reinstall add-ons seems to work ok. However, because of the randomness of the crash, I cannot be 100% sure.
Attached patch Fix it harder (obsolete) — Splinter Review
I screwed up.

Patch is getting built on try server - I'll post a link when they're ready.
Assignee: tglek → mwu
Attachment #522821 - Attachment is obsolete: true
Attachment #523121 - Flags: review?(tglek)
Attached patch Fix it harder, v2 (obsolete) — Splinter Review
Forgot to check the returned pointer for null.
Attachment #523121 - Attachment is obsolete: true
Attachment #523121 - Flags: review?(tglek)
Attachment #523124 - Flags: review?(tglek)
Attached patch Broken test (obsolete) — Splinter Review
Can't seem to write a test to cause this freeze.. the zip being released in ReleaseZip always seems to be the oldest one in the cache. Need to find a way to cause a mismatch.
(In reply to comment #69)
> Builds with the last patch available at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mwu@mozilla.com-e47a81aa02d0/

Tested the 64-bit build in the same way as before (see comment #62.)

This time it did not hang -- repeated the test 3 times, all successful. Looks like this build fixed the problem. Thanks!
Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110329 Firefox/4.2a1pre SeaMonkey/2.2a1pre ID:20110329225206

On this tinderbox-build I am able to select the Extensions pane, even take my time answering the "Add-on Compatibility reporter" menu for several extensions including ACR itself, and yet SeaMonkey doesn't hang, even (AFAIK) without the fix for this bug. Could this have been fixed by the fix for bug 627240 and/or by faking a version change (changing extensions.lastAppVersion in prefs.js while SeaMonkey was not running) after that fix had landed?
P.S. 42 addons enabled ATM, all in the profile now that bug 627240 has landed. (The only files still found in /usr/local/seamonkey/extensions/ are the *.xpi for the built-in themes and I'm using a 3rd-party one.)
yep this works. good work!
30ish extensions now, would crash around 22 before

when will it land in a ppa? alternatively how do i brand it as firefox with ff icon etc?
Thanks Tony for this hard work !
Is it possible to change manually a file for obtain the fix ?
If not, I will waiting the bug's correction in a ppa. (in mozilla daily, stable ?)

>alternatively how do i brand it as firefox with ff icon etc?
For UbuntUser like you, use this one (but the fix didn't happen yet) :
sudo add-apt-repository ppa:mozillateam/firefox-stable
sudo apt-get update
sudo apt-get upgrade
Attached patch Fix it harder, v3 (obsolete) — Splinter Review
Now with a working test for debug builds.
Attachment #523124 - Attachment is obsolete: true
Attachment #523173 - Attachment is obsolete: true
Attachment #523124 - Flags: review?(tglek)
Attachment #523343 - Flags: review?(tglek)
Comment on attachment 523343 [details] [diff] [review]
Fix it harder, v3

I think the try/catch in testcase is redundant.
Attachment #523343 - Flags: review?(tglek) → review+
Attachment #523343 - Attachment is obsolete: true
Duplicate of this bug: 646822
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Please, when will it be available in the official PPA repository (ppa:mozillateam/firefox-stable)?
Thanks.
(In reply to comment #81)
> Please, when will it be available in the official PPA repository
> (ppa:mozillateam/firefox-stable)?
> Thanks.

You'll have to speak to whoever maintains that repository, we don't control it.
Message has been sent to the maintainer of FF4-stable PPA in launchpad.net asking him to consider building new version.
(In reply to comment #82)
> (In reply to comment #81)
> > Please, when will it be available in the official PPA repository
> > (ppa:mozillateam/firefox-stable)?
> > Thanks.
> 
> You'll have to speak to whoever maintains that repository, we don't control it.

From where I can download this fixed version?
@Simon: see Comment 75, as soon as new build done.
(In reply to comment #85)
> @Simon: see Comment 75, as soon as new build done.

Thanks, but now I don't speak of unofficial PPAs. I ask for official mozilla releases.
This bug is serious and it affects many more people than voted this bug. 
It would be important to release a corrected version soon. We are talking about a bug which prevents using Firefox 4 to many people.
A nightly that's to be released later today will include a fix for this bug ( http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 )

Mind that it's a _nightly_ so it can have major problems - some of them may even preclude a normal web browsing (like hangs, crashes, inability to use core browsing features, etc.)
(In reply to comment #87)
> A nightly that's to be released later today will include a fix for this bug (
> http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 )
> 
> Mind that it's a _nightly_ so it can have major problems - some of them may
> even preclude a normal web browsing (like hangs, crashes, inability to use core
> browsing features, etc.)

Thanks, but that thread is about Windows version. I use Linux.
(In reply to comment #87)
> A nightly that's to be released later today will include a fix for this bug (
> http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 )
> 
> Mind that it's a _nightly_ so it can have major problems - some of them may
> even preclude a normal web browsing (like hangs, crashes, inability to use core
> browsing features, etc.)

E.g. many people report that page scrolling leads to some unpleasant rendeiring artifacts, see bug 647315.

The best way to have your Firefox 4.0 fixed, is to download its sources, apply this patch and compile Firefox (using -O2 -march=native -pipe CFLAGS/CXXFLAGS). It will take quite some time, but you will still have a stable Firefox release but without "extra" nightly brokenness.

(In reply to comment #88)
> 
> Thanks, but that thread is about Windows version. I use Linux.

Don't pay attention to a mozillazine forum page title. It's historically called "Windows" but when a Windows build is ready it usually means that MacOS and Linux builds are also ready.
(In reply to comment #89)
> (In reply to comment #87)
> > A nightly that's to be released later today will include a fix for this bug (
> > http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 )
> > 
> > Mind that it's a _nightly_ so it can have major problems - some of them may
> > even preclude a normal web browsing (like hangs, crashes, inability to use core
> > browsing features, etc.)
> 
> E.g. many people report that page scrolling leads to some unpleasant rendeiring
> artifacts, see bug 647315.
> 
> The best way to have your Firefox 4.0 fixed, is to download its sources, apply
> this patch and compile Firefox (using -O2 -march=native -pipe CFLAGS/CXXFLAGS).
> It will take quite some time, but you will still have a stable Firefox release
> but without "extra" nightly brokenness.

Ok, thanks.
The patch is this: http://hg.mozilla.org/mozilla-central/raw-rev/4a0faa67237d, no?
And the "stable" source of Firefox 4?
The trunk patch doesn't apply cleanly to Firefox 4.0 sources, here's a patch that works.
(In reply to comment #92)
> Created attachment 523777 [details] [diff] [review]
> Firefox 4.0 (branch) bug 637286 patch
> 
> The trunk patch doesn't apply cleanly to Firefox 4.0 sources, here's a patch
> that works.

Thanks.
One last question about compilation (it's an off-topic, sorry): how can I compile it in spanish?
(In reply to comment #93)
> (In reply to comment #92)
> > Created attachment 523777 [details] [diff] [review]
> > Firefox 4.0 (branch) bug 637286 patch
> > 
> > The trunk patch doesn't apply cleanly to Firefox 4.0 sources, here's a patch
> > that works.
> 
> Thanks.
> One last question about compilation (it's an off-topic, sorry): how can I
> compile it in spanish?

You can always install Spanish support via XPI ( http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0/linux-i686/xpi/ + setting general.useragent.locale in about:config ).

Anyways, please, don't use bugzilla as a support forum, ask your questions (not related to this bug report) on http://forums.mozillazine.org/ or http://irc.mozilla.org/
Thanks for the help and for the patch.
I've compiled Firefox 4 from sources (in spanish), optimized for my CPU and it works well with 38 extensions installed: 36 enabled and 2 disabled. :-)
Comment on attachment 523777 [details] [diff] [review]
Firefox 4.0 (branch) bug 637286 patch

Looking for approval to land this on the mozilla-2.0 branch to resolve this hang which affects users particularly on linux and with many extensions installed but taras tells me it is likely happening on windows too
Attachment #523777 - Flags: approval2.0?
(In reply to comment #84)
> (In reply to comment #82)
> > (In reply to comment #81)
> > > Please, when will it be available in the official PPA repository
> > > (ppa:mozillateam/firefox-stable)?
> > > Thanks.
> > 
> > You'll have to speak to whoever maintains that repository, we don't control it.
> 
> From where I can download this fixed version?

This fixed version of Firefox 4.2a1pre should appear no more than 24 hours after comment #79, at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ for Win32, Linux-i686 (32-bit), Linux-x86_64 and Mac (Universal binary for both 32- and 64-bit Intel machines). Use the appropriate *.installer.exe, *.tar.bz2 or *.dmg corresponding to your computer.

This nightly is compiled from the "bleeding-edge" development sources, and at the moment it is considered a "pre-alpha" build. USE AT YOUR OWN RISK!

This bugfix may or may not be retrofitted into earlier branches of the source tree. It isn't yet. If and when these "older but stabler" branches get the fix, the settings "status-2.0" (for Firefox 4.0), "status-1.9.2" (for Firefox 3.6.x) and/or "status-1.9.1" (for Firefox 3.5.x), near top right of this page, will change.
Are there any fixed and stable binary for Firefox 4.0 in mozilla repositories, not pre release ?
(In reply to comment #98)
> Are there any fixed and stable binary for Firefox 4.0 in mozilla repositories,
> not pre release ?

No, we have to wait to get approval to land the patch on the stable branch and even then it will only be in branch nightlies until the next Firefox 4.0.x is released.
Duplicate of this bug: 647640
We should add this case to Litmus. let's get this into Tumucumaque Macaw.
Flags: in-litmus?
blocking2.0: ? → Macaw+
Comment on attachment 523777 [details] [diff] [review]
Firefox 4.0 (branch) bug 637286 patch

This patch is incomplete and doesn't contain the data used for the test. Going to verify the test works and post a new patch.
Attachment #523777 - Attachment is obsolete: true
Attachment #523777 - Flags: approval2.0?
Newbie question: does "Status: RESOLVED FIXED" mean it will be fixed in an forthcoming patch? I landed here since I am experiencing this same issue.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:2.0) Gecko/20100101 Firefox/4.0 ID:20110318052756
(In reply to comment #105)
> Newbie question: does "Status: RESOLVED FIXED" mean it will be fixed in an
> forthcoming patch? I landed here since I am experiencing this same issue.

It will be fixed in Firefox 4.0.1
If you want a fixed version now, download and install Firefox from here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-2.0/

This URL contains Firefox that will become version 4.0.1
Artem -- thanks!
Can everyone verify that this patch fixed the hang issue in Firefox 4.0.1 and the upcoming Firefox 5?
Target Milestone: --- → mozilla5
Yes, it is in 4.0.1.

Thanks a lot, dev !
(In reply to comment #109)
> Can everyone verify that this patch fixed the hang issue in Firefox 4.0.1
> and the upcoming Firefox 5?

Yes, fixed in 4.0.1.
Thanks for your quick feedback. Marking this bug as verified fixed then.
Status: RESOLVED → VERIFIED
I think that would be a good candidate for our Mozmill endurance tests.
Whiteboard: [mozmill-test-needed][mozmill-endurance]
You need to log in before you can comment on or make changes to this bug.