MASTER Firefox Crash [@gtk_style_realize] [@nsFilePicker::Show]

[Sitsofe Wheeler]

fixed by workaround in totem bug 90333

Steps to reproduce (taken from upstream bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210151 ):
0) Install totem plugin, start firefox
1) Go to a site with movie links, for example
http://digital-desert.com/mpg-videos/
2) Open a non-movie link in a new tab, close the new tab [not sure this step is
necessary]
3) Open a movie link in a new tab; wait for it to load in the totem plugin;
close the tab
4) Right-click the movie link, Save Target As

[Aleksej (aleksejrs)]

Debian testing
totem-mozilla 2.16.2-2

Crash when closing Firefox (with [X]):

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Talkback ID: TB25758224X.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1
Talkback ID: TB25757932W.

[Adam Guthrie (ispiked)]

Just curious, but have you tested to see if it crashes with a build with your patch from bug 241535 in it?

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

Those talkbacks match bug 241535, and are fixed by the patch there.
This bug isn't fixed by the patch there.

[Sitsofe Wheeler (sitsofe)]

Description of the problem:
I tried to watch the video on http://macslow.thepimp.net/?p=26 by clicking on it but received an error message that the plugin could not play the video by streaming it and that I should try and download it first. I clicked the back button pressed the right mouse button to do save as and after a few seconds of high CPU usage firefox crashed.

Steps to reproduce:
1. Visit http://macslow.thepimp.net/?p=26 .
2. Click on the picture near the top.
3. Wait for the totem plugin to say it can't play that video.
4. Click back.
5. Press the right mouse button over the picture and choose Save Link As...

Expected result:
To be able to download the video to disk.

Actual result:
Crash.

Additional information:
Almost certainly a duplicate of bug #70875 .

[David Farning (dfarning)]

hey sitsofe,
Looks like you have aother gtk_style_realize issue.

Dave

[Sitsofe Wheeler (sitsofe)]

Hey Dave,

Certainly does look like this is a dup of Bug #74576 . I had a spate of firefox crashes and tried to get them filed as quickly as possible without really looking closely at the stacktraces before you isolated it.

I hate forward duping (because I always feel the bug reported first should get the credit) but 74576 now has a lot of information swimming about in it...

By the way, I've been running a few of the "full" crash dumps on other firefox bugs through apport-retrace thus decoding more pieces of the stacktrace. As mentioned previously Bug #70875 initial report looks like another gtk_style_realize issue. Some I can't decode (people who were testing edgy before it was released were using a beta .deb of firefox 2 which is seemingly no longer available) and a few seem to have a very strange addresses like 0x0000000b in them which I don't really understand. Stack corruption perhaps?

[David Farning (dfarning)]

Hey Sitsofe,

Nice work finding apport-retrace. It is providing a lot of additional information for us to work with. I had never seen it used before.

I've stopped marking issues as dups. Because I'm even though the stack trace is similar they may end up being separate issues. For now I am moving the original issue title to the top line of the description and replacing the title with what looks like a identifiable bit of the stack trace.

David

[Reinout van Schouwen (reinout-gmail)]

This bug still causes many duplicate crash reports for both Epiphany and Galeon.

[Timeless-bemail (timeless-bemail)]

<email address hidden>: that's nice. are you volunteering to work on it?

[Alexander Sack (asac)]

ok ... this will be our new master crash for nsFilePicker::Show variant.

[Alexander Sack (asac)]

maybe patch is in https://bugzilla.mozilla.org/show_bug.cgi?id=241535

[Alexander Sack (asac)]

Aleksej, can you still reproduce this with both branch and trunk builds?

[Aleksej (aleksejrs)]

totem-mozilla 2.16.5-2, latest Firefox (2007030104)
1.8: TB29817710W
Trunk: TB29817976K

[Alexander Sack (asac)]

I'll give it a try. stay tuned.

[Sitsofe Wheeler (sitsofe)]

I cannot reproduce this bug using the "new" steps under Feisty herd 5 (with no extra gstreamer codecs installed).

[Alexander Sack (asac)]

ok ... try totem-xine ... should still be present

[Alexander Sack (asac)]

Created attachment 257133
maybe this (1.8 branch)

As mentioned by reporter, destructor is not called when nsPluginNativeWindowGtk2 gets removed. In consequence window/widget does not get properly removed from gtk widget hierachy.

This patch removed widget properly from hierachy.

I did not change destructor code (which does basically the same, but is not called), but instead set mGtkSocket = 0 in this patch ... so should be safe.

Should be the same on trunk.

Someone can please verify that this fixes 1.8 + trunk build so i can ask for review?

[Alexander Sack (asac)]

On Sat, Mar 03, 2007 at 02:58:45PM -0000, Sitsofe Wheeler wrote:
> I cannot reproduce this bug using the "new" steps under Feisty herd 5
> (with no extra gstreamer codecs installed).
>

i added a patch to upstream bug. Test builds (i386) are available in
mozilla team feisty preview archive [1]. So please verify if this fixes
issue for you.

[1] - https://wiki.ubuntu.com/MozillaTeam/PreviewArchives

 - Alexander

[Sitsofe Wheeler (sitsofe)]

OK I have managed to reproduce the problem with totem-gstreamer (which was what the original report was filed with). Using firefox_2.0.0.2+1-0ubuntu1.mt2_i386.deb seems to work around the problem in both the originally filed report and the upstream report.

[John Vivirito (gnomefreak)]

Sitsofe, that package is not a work around its a testing package. We use the PreveiwArchives to test patches before we add them to firefox/thunderbird in repos.

[Sitsofe Wheeler (sitsofe)]

John:

Sure, but if you read the upstream bug in from which the patch came from it indicates that the true cause for why nsPluginNativeWindowGtk2 was failing to be destroyed should be searched for and this band-aid removed when a real fix has been added.

[Alexander Sack (asac)]

On Tue, Mar 06, 2007 at 08:08:36AM -0000, Sitsofe Wheeler wrote:
> John:
>
> Sure, but if you read the upstream bug in from which the patch came from
> it indicates that the true cause for why nsPluginNativeWindowGtk2 was
> failing to be destroyed should be searched for and this band-aid removed
> when a real fix has been added.
>

The reason you don't see the crash is a different patch than the one
you refer to. However its still not a real fix, so you are right in general.

 - Alexander

[Alexander Sack (asac)]

Comment on attachment 257133
maybe this (1.8 branch)

this patch breaks other plugins.

[Alexander Sack (asac)]

ok the bug is due to broken implementation of NPPVpluginKeepLibraryInMemory ... fix is not simple, so we worked around this by dropping that option from totem:

The workaround patch for totem is here:

http://bugzilla.gnome.org/show_bug.cgi?id=415389

However NPPVpluginKeepLibraryInMemory should be fixed or completely disabled at some point. So this bugs should be kept open.

[Alexander Sack (asac)]

this bug should be gone with latest totem upload to feisty.

[Alexander Sack (asac)]

ah forgot ... we keep this *open* to catch more duplicates for now.

[Alexander Sack (asac)]

Sitsofe, what plugins do you regularaly use? I ask that because I need someone who is willing to test a new firefox package with as much plugins as possible (at best in regular use)

[mench (pmench)]

Alexander (if I may),

Here's my list of plugins. Is this enough?

Paul

 Installed plug-ins
Find more information about browser plug-ins at
mozilla.org<https://pfs.mozilla.org/plugins/>.

Help for installing plug-ins is available from plugindoc.mozdev.org.
------------------------------
Shockwave Flash
File name: libflashplayer.so Shockwave Flash 9.0 r31 MIME Type Description
Suffixes Enabled application/x-shockwave-flash Shockwave Flash swf Yes
application/futuresplash FutureSplash Player spl Yes Java(TM) Plug-in
1.5.0_08-b03
File name: libjavaplugin_oji.so Java(TM) Plug-in 1.5.0_08 MIME Type
Description Suffixes Enabled application/x-java-vm Java
Yes application/x-java-applet Java
Yes application/x-java-applet;version=1.1 Java
Yes application/x-java-applet;version=1.1.1 Java
Yes application/x-java-applet;version=1.1.2 Java
Yes application/x-java-applet;version=1.1.3 Java
Yes application/x-java-applet;version=1.2 Java
Yes application/x-java-applet;version=1.2.1 Java
Yes application/x-java-applet;version=1.2.2 Java
Yes application/x-java-applet;version=1.3 Java
Yes application/x-java-applet;version=1.3.1 Java
Yes application/x-java-applet;version=1.4 Java
Yes application/x-java-applet;version=1.4.1 Java
Yes application/x-java-applet;version=1.4.2 Java
Yes application/x-java-applet;version=1.5 Java
Yes application/x-java-applet;jpi-version=1.5.0_08 Java
Yes application/x-java-bean Java
Yes application/x-java-bean;version=1.1 Java
Yes application/x-java-bean;version=1.1.1 Java
Yes application/x-java-bean;version=1.1.2 Java
Yes application/x-java-bean;version=1.1.3 Java
Yes application/x-java-bean;version=1.2 Java
Yes application/x-java-bean;version=1.2.1 Java
Yes application/x-java-bean;version=1.2.2 Java
Yes application/x-java-bean;version=1.3 Java
Yes application/x-java-bean;version=1.3.1 Java
Yes application/x-java-bean;version=1.4 Java
Yes application/x-java-bean;version=1.4.1 Java
Yes application/x-java-bean;version=1.4.2 Java
Yes application/x-java-bean;version=1.5 Java
Yes application/x-java-bean;jpi-version=1.5.0_08 Java
Yes VLC Multimedia Plugin
File name: libvlcplugin.so Version 0.8.6 Janus, copyright 1996-2006 The
VideoLAN Team
http://www.videolan.org/ MIME Type Description Suffixes Enabled
audio/mpeg MPEG
audio mp2,mp3,mpga,mpega Yes audio/x-mpeg MPEG audio mp2,mp3,mpga,mpega Yes
video/mpeg MPEG video mpg,mpeg,mpe Yes video/x-mpeg MPEG video mpg,mpeg,mpe
Yes video/mpeg-system MPEG video mpg,mpeg,mpe,vob Yes
video/x-mpeg-system MPEG
video mpg,mpeg,mpe,vob Yes video/mpeg4 MPEG-4 video mp4,mpg4 Yes
audio/mpeg4 MPEG-4 audio mp4,mpg4 Yes application/mpeg4-iod MPEG-4 video
mp4,mpg4 Yes application/mpeg4-muxcodetable MPEG-4 video mp4,mpg4 Yes
video/x-msvideo AVI video avi Yes video/quicktime QuickTime video mov,qt
Yes application/x-ogg Ogg stream ogg Yes application/ogg Ogg stream ogg
Yes application/x-vlc-plugin VLC plugin vlc Yes video/x-ms-asf-plugin Windows
Media Video asf,asx Yes video/x-ms-asf Windows Media Video asf,asx Yes
application/x-mplayer2 Windows Media
Yes video/x-ms-wmv Windows Media wmv Yes
application/x-google-vlc-plugin Google
VLC plugin
Yes audio/wav WAV audio wav Yes ...

[Jamie (jamie-jamiet)]

unsubscribe launchpad

[Sitsofe Wheeler (sitsofe)]

(offtopic)

Drowning in a sea of duplicate bug reports is bug #46237 ...

[Sitsofe Wheeler (sitsofe)]

Hmm I don't want to unsubscribe from this bug as I am the "original reporter". However if you are working on a duplicate of this bug can you please retrace it and comment on it BEFORE you mark it as a duplicate of this one? I mean on the one hand I'm impressed at the speed at which duplicates are being resolved however the amount of mail being produced is gigantic and anything to cut it back is appreciated...

[Sitsofe Wheeler (sitsofe)]

Alexander:

Strange though this may sound I actually only use one plugin - the totem one. I like to try and stay as close to stock Ubuntu as possible to decrease the chances of unusual problems that other people can't reproduce (I currently don't even have any extensions installed). I also don't browse many flash sites so I have no great need to install the flash plugin. Most of my browsing is restricted to tech news sites and the occasional video from gametralers.com so I'm not even that representative of your typical person browsing popular sites like youtube, facebook, myspace, flickr (see other top 100 websites here: http://www.alexa.com/site/ds/top_sites?ts_mode=lang&lang=en )... I only started actively looking for troublesome video after you the totem-plugin fix with the sole intent on seeing whether it would break again...

However if you think it would be helpful then I can test new mozilla snapshots (once upon a time years ago I used to do this for mozilla nightles). However I think I most likely to do this during Ubuntu alpha/beta testing periods..

[Hilario J. Montoliu (hjmf) (hmontoliu)]

El lun, 09-04-2007 a las 17:24 +0000, Sitsofe Wheeler escribió:
> Hmm I don't want to unsubscribe from this bug as I am the "original
> reporter". However if you are working on a duplicate of this bug can you
> please retrace it and comment on it BEFORE you mark it as a duplicate of
> this one? I mean on the one hand I'm impressed at the speed at which
> duplicates are being resolved however the amount of mail being produced
> is gigantic and anything to cut it back is appreciated...
>

Sorry from our part Sitsofe, but AFAIK we retrace and comment every
report BEFORE we are able to tag it as a duplicate (which in fact is the
last step). We need the retrace previous to check if the report is
already a dup. or not (some may be commented after tagging as dup, but
it's not usual).

[Sitsofe Wheeler (sitsofe)]

Hilario:
Thanks for replying. This sounds like a launchpad bugs where it is sending messages posted before a bug was marked at a duplicate together with announcement that the bug is a duplicate.

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

Bug 371387 comment 19 and 20 indicate that this crash also happens for plugins which don't use NPPVpluginKeepLibraryInMemory.

[Alexander Sack (asac)]

(In reply to comment #12)
> Bug 371387 comment 19 and 20 indicate that this crash also happens for plugins
> which don't use NPPVpluginKeepLibraryInMemory.

Yes, it happens with latest totem too. It just needs a modified testcase:

(From: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334)

Steps to reproduce:
1. Visit
http://www.apple.com/getamac/ads/
2. Wait for "Hello I'm a Mac" then click on the "Tech Support" video at the bottom left. A video should start to play.
3. Repeat step 2 until video area no longer starts playing the video.
4. Start
gnome-theme-manager .
5. Change the theme from Human to Mist.

[Todd Whiteman (toddw)]

This is also happening with Komodo and the Scintilla plugin, which does not use NPPVpluginKeepLibraryInMemory.

Way to reproduce this bug within Komodo:
1) After closing an opened file (plugin is removed) and then opening the native file open dialog.
2) After closing an opened file (plugin is removed) and then changing the theme.

The gdb stacktrace for Komodo is the same as posted in the main part of the bug above.

Reference: http://bugs.activestate.com/show_bug.cgi?id=64037

[Reed Loden (reed)]

Is this still a problem on trunk with all the fixes that have landed in the plugins code?

[Todd Whiteman (toddw)]

I *cannot* reproduce this exact problem using a "Komodo on Mozilla trunk" build, but I am getting some nasty looking GTK errors when shutting down the application:

(gecko:10908): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed
(gecko:10908): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(gecko:10908): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
(gecko:10908): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
(gecko:10908): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed
(gecko:10908): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed
(gecko:10908): Gdk-CRITICAL **: gdk_screen_get_display: assertion `GDK_IS_SCREEN (screen)' failed
(gecko:10908): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

.... (same errors repeat numerous times)

[Alexander Sack (asac)]

verified that the testcase in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334 doesn't crash firefox beta 3.

Closing bug.

[Alexander Sack (asac)]

verified that this is now fixed in xulrunner-1.9+firefox-3.0.

[Alexander Sack (asac)]

firefox 2 most likely wont see a fix. setting status accordingly.

Thanks all for your patience. firefox 3 will be the default browser in hardy.

 - Alexander

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

asac: Have you also verified that it doesn't crash anymore with the steps from comment 14 ?

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

BTW, I think http://bugzilla.gnome.org/show_bug.cgi?id=467698 sheds some light on what's really going on here that's caused/causing the crash.

[Sam Morris (yrro)]

I've hit this a few times recently with xulrunner 1.9. Various beta versions and most recently with rc2.

[Sam Morris (yrro)]

A trace can be found at http://bugzilla.gnome.org/show_bug.cgi?id=538522.

[Sam Morris (yrro)]

A trace can be found at http://bugzilla.gnome.org/show_bug.cgi?id=538522. How can I re-open the bug?

[Reinout van Schouwen (reinout-gmail)]

Reopening bug as requested.

[Timeless-bemail (timeless-bemail)]

reclosing. <email address hidden>: don't reopen bugs without getting people to specify versions.

<email address hidden>: don't complain about xulrunner 1.9 beta 5 when the current release of gecko is 1.9 <final>.

<email address hidden>: this bug is a bug in gtk not a bug in gecko, and you haven't specified the version of gtk you were using. you have otoh managed to make a hash out of this bug system.

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

@timeless:
- Comment 20 mentions that it also occurred on rc2, which is about code-identical to final.
- On what grounds do you claim that this is a gtk bug? In comment 19 I linked to a gnome bug report that indicates that gecko's use of gtk_widget_set_parent_window might be responsible for this problem.

[Timeless-bemail (timeless-bemail)]

sorry, i was looking at http://bugzilla.gnome.org/show_bug.cgi?id=467698#c48

if you have some evidence that a bug is still valid, you're welcome to reopen it. however i do not want qa to reopen bugs based on requests which point to old versions of products and do not specify versions of relevant libraries (the fix there is for gtk2.12, so knowing the gtk version is important).

[Sam Morris (yrro)]

Well am using gtk 2.12.9.

[Sam Morris (yrro)]

And I ran into this again with GTK+ 2.12.11. Please can someone re-open this bug?

[Sam Morris (yrro)]

Oh, and xulrunner 1.9.0.1 this time.

[Karlt (karlt)]

Sam, can you indicate which steps to reproduce cause a crash for you, please?

[Sam Morris (yrro)]

Unfortunately I am unable to reproduce the crash to a recipe. All I know is that Epiphany will sometimes crash with this stack trace when I close it. :(

I'll attach the exact backtrace that I got yesterday, hopefully it will help.

[Sam Morris (yrro)]

Created attachment 333248
backtrace with gtk 2.12.11 and xulrunner 1.9.0.1

[Gb-public (gb-public)]

Hi, I don't think this issue is caused by bug #469538.

However, I looked briefly at XEMBED (through GtkPlug / GtkSocket) while debugging a problem for nspluginwrapper. It turns out Firefox never destroys the plugin window cleanly, and its not really its fault. First, Firefox never propagates NPP_SetWindow(NPP, (NPWindow){ .window = NULL }); down to the plugin. Then, DoStopPlugin() will generally delay destroy of the page window, not the plugin window. That window is destroyed at the Gdk level (through a simple g_object_unref() IIRC). However, in the best cases, that "toplevel" window destruction will trigger the destruction of the GtkSocket, but not the underlying X window.

Something important to note: GtkPlug / GtkSocket work differently depending on whether the other GtkPlug is in-process or out of process. In out-of-process case, destroying a window will destroy all subsequent windows in the hierarchy, including the plugins X windows and windows in the other process. However, in the in-process case, the X window (exposed to the plugin) is never destroyed. Nada, no call to XDestroyWindow() with that XID.

AFAIK, this is a problem for Flash that doesn't expect someone else destroying its plugin window from behind its back. It currently works in Firefox because the plugin XID is never destroyed for the lifetime of the program. However, when run through nspluginwrapper, and since I tried to respect the NPAPI specs and destroying the windows around NPP_Destroy(), it fails.

I will probably open another bug entry for this specific issue, though this is not really Firefox's fault (rather Gtk2). However, Firefox could have been cool and send NPP_SetWindow() with a NULL NPWindow::window, as mentioned in the specs. Though, Flash (even version 10) doesn't handle that case either anyway. So, we are left with a possible Gtk2 bug.

Note: I workarounded the issue at the nspluginwrapper level by forbidding propagation of WM_DELETE_EVENT (that the GtkSocket sends) + other tricks.

I am not sure I was clear enough as I was typing this away from the actual Firefox sources, but rather dumped what I had in memory. ;-)

[Alexander Sack (asac)]

(In reply to comment #33)
> I will probably open another bug entry for this specific issue, though this is
> not really Firefox's fault (rather Gtk2). However, Firefox could have been cool
> and send NPP_SetWindow() with a NULL NPWindow::window, as mentioned in the
> specs. Though, Flash (even version 10) doesn't handle that case either anyway.
> So, we are left with a possible Gtk2 bug.

This bug is not only about flashplugin; we saw this crash mostly with totem and other plugins; so while flash currently might not handle it, it might still be worthwhile to consider this anyway.

BTW, which "specs" are you referring to exactly?

>
> Note: I workarounded the issue at the nspluginwrapper level by forbidding
> propagation of WM_DELETE_EVENT (that the GtkSocket sends) + other tricks.
>
> I am not sure I was clear enough as I was typing this away from the actual
> Firefox sources, but rather dumped what I had in memory. ;-)

It made a bit sense at least :) ... thanks for your ideas on this!

[Timeless-bemail (timeless-bemail)]

yes, @nokia we learned about flash ignoring setwindow null. i had suggested it as a fix for something (in fact, quite possibly a crash w/ this signature) and then an engineer mentioned that the flash side ignored it. i was heartbroken.

[varunH (varunkubuntu)]

Jaunty release is not stable to lenovo laptop (N3000 200 series)

I have a problem in Hda intel sound driver.But in earlier version i have no problem in (Intrepid).So please i request u to release a stable version of Jaunty(Beta version).It is helpful for me to use for education purpose. Compiz also not working in jaunty release.

[varunH (varunkubuntu)]

please I request u to change the package file name of kubuntu (ie libsexy,libproxy,ktorrent....).In your college there is a proxy connection these pakages are not installed in kubuntu(intrepid) and jaunty release also.so please i request u to change the name of packages.

[John Vivirito (gnomefreak)]

varunH, Jaunty is not a stable release at this time. Expect bugs they will lessen the closer to release we get. If you want stable apps and very little bugs please use Intrepid of Hardy

[varunH (varunkubuntu)]

John Vivirito, Ok thank u for giving good suggestion.

[varunH (varunkubuntu)]

Did they change the name of packages such as (libsexy,pythonsexy,ktorrent).Because in my college there is a proxy setting are available.They block this packages.So i cant update my packages in synaptic package manager.So please i request u to solve this problem.

[John Vivirito (gnomefreak)]

On 03/05/2009 01:48 PM, varunH wrote:
> Did they change the name of packages such as
> (libsexy,pythonsexy,ktorrent).Because in my college there is a proxy
> setting are available.They block this packages.So i cant update my
> packages in synaptic package manager.So please i request u to solve this
> problem.
>
The names are the same. You can not download them due the the work sexy
and im betting because of the torrent part of it. Most callages in US
install a babysitter package that blocks these as it sees it as porn.
There is nothing we can do to solve that for you, You can talk to your
instructor/professor into helping you out with that.

--
Sincerely Yours,
    John Vivirito

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

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[steveo (mrbrooks9)]

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of John
Vivirito
Sent: Friday, March 06, 2009 7:21 AM
To: <email address hidden>
Subject: Re: [Bug 72018] Re: MASTER Firefox Crash[@gtk_style_realize]
[@nsFilePicker::Show]

On 03/05/2009 01:48 PM, varunH wrote:
> Did they change the name of packages such as
> (libsexy,pythonsexy,ktorrent).Because in my college there is a proxy
> setting are available.They block this packages.So i cant update my
> packages in synaptic package manager.So please i request u to solve this
> problem.
>
The names are the same. You can not download them due the the work sexy
and im betting because of the torrent part of it. Most callages in US
install a babysitter package that blocks these as it sees it as porn.
There is nothing we can do to solve that for you, You can talk to your
instructor/professor into helping you out with that.

--
Sincerely Yours,
    John Vivirito

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

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

--
MASTER Firefox Crash [@gtk_style_realize] [@nsFilePicker::Show]
https://bugs.launchpad.net/bugs/72018
You received this bug notification because you are a direct subscriber
of a duplicate bug.

[dotancohen (dotancohen)]

> we keep this *open* to catch more
> duplicates for now

I think that this bug can safely be closed now. The issue is resolved, and the last dupe was filed two years ago.

[Micah Gersten (micahg)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is marked as Won't Fix in Firefox, and Fix Released in Xulrunner
1.9 and Firefox 3.0
It is effectively closed.

dotancohen wrote:
>> we keep this *open* to catch more
>> duplicates for now
>
> I think that this bug can safely be closed now. The issue is resolved,
> and the last dupe was filed two years ago.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqQ0igACgkQTniv4aqX/Vn38wCeMhSTYEOMx6F1uf+8EBX5+oip
lfUAni520yPplkCsTO5zIQGcAUPIQQSD
=+iXd
-----END PGP SIGNATURE-----

[Vseerror (vseerror)]

gtk_style_realize is not found in crash-stats.
Do you stilll see this problem?

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334 last status is WONTFIX
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/72018 is also WONTFIX

[Piero Mazzini (pieromazzini)]

No, thank you.
The problem is solved.

Regards,

Piero Mazzini

Il giorno 25/mag/2013, alle ore 23.40, Vseerror ha scritto:

> gtk_style_realize is not found in crash-stats.
> Do you stilll see this problem?
>
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/91334 last status is WONTFIX
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/72018 is also WONTFIX
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (86619).
> https://bugs.launchpad.net/bugs/72018
>
> Title:
> MASTER Firefox Crash [@gtk_style_realize] [@nsFilePicker::Show]
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/firefox/+bug/72018/+subscriptions

[Georg-fritzsche (georg-fritzsche)]

Closing here, please comment if there are still configurations where this is relevant.