Firefox crash when a gnome theme is selected

[manuel]

Binary package hint: firefox

If Firefox is open while the user change the gnome theme, it crashes.

firefox 2.0+0dfsg-0ubuntu3

Ubuntu Edgy 6.10 RC updated as 10.23.06 9:59 PM GMT-4

[Bzbarsky (bzbarsky)]

I should note that if, God forbid, you don't have a current GNOME theme selected, simply opening the theme dialog will hang our app. That's what happened to me.

[Steve-england (steve-england)]

Dupe of / related to bug 318829?

[Bzbarsky (bzbarsky)]

Similar for sure. Might be a dup; hard to say. I'll try getting this profiled and fixed; at that point we can see whether bug 318829 is still around for that reporter. I wouldn't be surprised if there are multiple hang scenarios here...

[Bzbarsky (bzbarsky)]

So I waited for about 3 hours, with the app completely hung. Then I went to bed; in the morning things were ok... until I made the mistake of killing the gnome-theme-manager process, at which point the app went back to being hung. I'll probably try to get non-computer stuff done for the rest of the day, I guess, and see whether I can safely profile this somehow in the evening....

[Bzbarsky (bzbarsky)]

So the issue here is that with a single window and single tab open on a theme change we get 8 each of "notify::gtk-theme-name" and "notify::gtk-key-theme-name" all dispatched to 8 different widgets. This leads to 32 calls into nsPresContext::ThemeChanged, since nsWindow::ThemeChanged calls ThemeChanged on all child windows too. In practice, this means X calls to ClearStyleDataAndReflow on the chrome prescontext, X calls to ResizeReflow on the content prescontext, and 32-X calls to ClearStyleDataAndReflow on the content prescontext. I didn't bother to find out what X is. The upshot is that in my case I had 100+ documents open at the time of the theme change; reflowing each of them 30+ times just ... took a while.

Patch coming up that should make this saner. Certainly does over here.

[Bzbarsky (bzbarsky)]

Created attachment 237895
Handle GNOME theme changes lazily.

This is much faster. If we care, we could even suppress reflow in background tabs, but that would take a little more work... and I'm not sure that's desirable.

[Roc-ocallahan (roc-ocallahan)]

Comment on attachment 237895
Handle GNOME theme changes lazily.

mPending* could just be PRPackedBools.

[Bzbarsky (bzbarsky)]

> mPending* could just be PRPackedBools.

Er... good catch. I'll do that. Or rather make them bits in the bitfield we already have.

[Bzbarsky (bzbarsky)]

Created attachment 237902
Updated to comments

[Bzbarsky (bzbarsky)]

Fixed on trunk.

[Adam Guthrie (ispiked)]

Verified FIXED using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060912 Minefield/3.0a1.

I had about 20-30 tabs opened in one window, switched the theme and Firefox recovered in < 1 minute.

[Hussam Al-Tayeb (hussam)]

Is it possible to get this checked in for 1.8 branch for firefox2?

[Bzbarsky (bzbarsky)]

If someone ports it, does a bunch of testing, and then convinces the branch drivers to take it into an effectively code-frozen branch, sure. I really don't feel it's worth the trouble, myself.

[Caillon (caillon)]

Considering the major linux enterprise vendors will be shipping this, and this is not an uncommon task in the desktop, I think it should be worth at the very least consideration based on the fact that this hangs the entire browser.

Further investigation in the patch leads me to believe that this is scary only in the sense that "it touches the pres context", but a quick look at the patch tells me that at the worst, all this will break potentially is that theme updates don't get propogated at all (application still uses the old theme widgetry). That potential regression seems a smidgen better than hanging the entire application. But I can provide testing there, facilitated by the really easy backport. Creating a test build now with a backported patch I'll push after this is done.

Then of course, there are the platforms that don't hang, e.g. Windows (or does it? Not sure.) In which case better testing really *is* needed for those platforms which I am unable to provide, but hopefully others can.

With the small-ish risk involved and the considerably larger gain, I'd like to try and get this considered more seriously for branches. Are there known regressions from the trunk?

[Bzbarsky (bzbarsky)]

Chris, if you have the resources to deal with this, I have no problems with getting it in on branch per se. Just no time to do it myself. Please request blocking of 1.8.1 or 1.8.1.1 or whatever if you'd like this to block those.

Not sure what the Windows situation is, but it looks like it avoids most of the issues (at least if it only gets notified by the OS once), since it doesn't do the recursion thing GTK does. So I doubt there were hangs on Windows.

[Caillon (caillon)]

Created attachment 240193
Patch backported to Firefox 1.5.0.x

Only major differences here are the threading stuff, which needed to use the nsIEventQueue stuff.

[Bzbarsky (bzbarsky)]

Comment on attachment 240193
Patch backported to Firefox 1.5.0.x

Looks reasonable.

[Adam Guthrie (ispiked)]

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

[manuel (manuel-soto)]

Binary package hint: firefox

If Firefox is open when a theme is selected it scrash.

firefox 2.0+0dfsg-0ubuntu3

Ubuntu Edgy 6.10 RC updated as 10.23.06 9:59 PM GMT-4

[Jeff Greene (jeffgreene)]

Thanks for your bug report. Unfortunately, I am not able to reproduce this bug. Can you please attach a log of the crash to help diagnose the problem?

[manuel (manuel-soto)]

Automatic bug stack collection is not working, yesterday it says that it doesn't have a package. A dbg stack dump attached.

I have to select 3 themes today in order to produce the crash.

Later,
Manuel

[Adam Guthrie (ispiked)]

That stack doesn't have debugging symbols. Can you install the firefox-dbg package and try to crash again?

[manuel (manuel-soto)]

Today I get a crash report. File attached.

[manuel (manuel-soto)]

Stack dump

[Switching to Thread -1221026944 (LWP 18413)]
nsLookAndFeel::InitColors () at nsLookAndFeel.cpp:503
503 nsLookAndFeel.cpp: No existe el fichero ó directorio.
        in nsLookAndFeel.cpp

This error is translated as "Nor found file or directory"

Don't ask me way it is so small

[Weston (westont)]

I got the same issue, here is my crash log

[christoph (christoph-boeckle)]

I was checking out desktop themes while I had two tabs open in firefox (browsing a phpbb forum, one tab showing a thread, the other with a reply form).

I changed from human to one of those inverted colours, high contrast, large fonts.

Firefox went down when I asked to use the suggested fonts for the theme.

[John Vivirito (gnomefreak)]

Is this still an issue for you? We are trying to trying sort out the older Mozilla issues and would like to know if this still happens.
Im also leaning toward a GTK bug not so much firefox. can you please try using all different kinds of themes to reproduce this and lets see what happens. (if the bug is fixed no need to try themes)
Thank you.

[manuel (manuel-soto)]

Yes, the problem persist. I did change 2 themes and it crash, SVG apparently as the last one

[John Vivirito (gnomefreak)]

can you please attach the crash report when using firefox Version 2.0.0.1+0dfsg-0ubuntu0.6.10?

[Alexander Sack (asac)]

any chance to see this on the branches at some point?

[Alexander Sack (asac)]

This is confirmed upstream and a patch is underway to land in some future upstream release. Thus, state "In Progress".

You need not to send further info, until we ask you to verify that this bug is fixed.

Thanks for caring and taking the time to submit this report,

 - Alexander

[Bzbarsky (bzbarsky)]

Huh. Chris never requested approval?

Poke him to do it? Or do it yourself (with an explanation to drivers of why this should go on branches)? I'm happy to land the patch if it gets approved.

[Alexander Sack (asac)]

(In reply to comment #20)
> Huh. Chris never requested approval?
>

Chris, any comment? Any reasons that you did not request approval?

[Manoel B H Carvalho (manoelhc)]

The same thing with 2.0.0.1+0dfsg-0ubuntu0.6.10, see the attach.

[colpompidou (colpompidou-deactivatedaccount)]

Same here with Feisty. Firefox hangs when changing themes. That does not happen with upstream Firefox which can be donwloaded on mozilla website.

[Alexander Sack (asac)]

On Sun, Mar 04, 2007 at 12:45:30PM -0000, colpompidou wrote:
> Same here with Feisty. Firefox hangs when changing themes. That does not
> happen with upstream Firefox which can be donwloaded on mozilla website.
>

Upstream trunk has this fixed. Otherwise, this bug should exist in
upstream build as well.

 - Alexander

[Alexander Sack (asac)]

this is a duper candidate (by description) of our gtk_style_realize master bug

[Tristan Cragnolini (tri-cragno)]

the fix for this bug has been released

[Chris Thomas (CTho) (cst-yecc)]

> Poke him to do it? Or do it yourself (with an explanation to drivers of why
> this should go on branches)? I'm happy to land the patch if it gets approved.

Do you mean just setting the flag and writing a comment?

[Bzbarsky (bzbarsky)]

Yes.

[John Nelson (articpenguin3800-deactivatedaccount)]

my firefox is crashing when i change a theme in gutsy.

[Alexander Sack (asac)]

On Tue, Apr 08, 2008 at 05:10:43PM -0000, John Nelson wrote:
> my firefox is crashing when i change a theme in gutsy.
>

yes, its fixed in firefox 3 (>= hardy)

 - Alexander

[Everett Guerny (everett)]

Actually, Alexander, this appears to still be an issue in Hardy with Firefox 3.0b5.

[John Vivirito (gnomefreak)]

If you are still seeing this bug either wait until RC1 hits archives for Hardy as it might be in that release or try with a new profile and see if you can reproduce this with a new profile without extensions.
I havent seen this bug in Firefox-3.0 in a long time but i havent tested as heavey like i did for 2.0

[Everett Guerny (everett)]

Thank you for the insight, John.

I just tried this with a fresh profile and didn't get this to reproduce. I'll have to poke around more to see if this was as a result of the profile not being migrated from 2.* (as my primary one was), not having extensions, etc.

[John Vivirito (gnomefreak)]

Everett Guerny wrote:
> Thank you for the insight, John.
>
> I just tried this with a fresh profile and didn't get this to reproduce.
> I'll have to poke around more to see if this was as a result of the
> profile not being migrated from 2.* (as my primary one was), not having
> extensions, etc.
>
Most likely extensions but if you still have old profile move it back so
you can use it and run firefox -safe-mode in terminal and see if you can
reproduce it, If you cant reproduce it than extensions would be issue if
you can most likely a corrupt profile. Neither is promised but this is a
good base line to find out what exactly caused failure.

--
Sincerely Yours,
     John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246