Oneric: On boot up Firefox always displays the “Well, This Is Embarrassing” screen.

Bug #867424 reported by philinux on 2011-10-04
This bug affects 38 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
firefox (Ubuntu)
Chris Coulson
Chris Coulson
thunderbird (Ubuntu)

Bug Description

This happens on every restart or boot. Firefox fails to load previous tabs.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: firefox 7.0.1+build1+nobinonly-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-12.19-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
NonfreeKernelModules: nvidia
AddonCompatCheckDisabled: False
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices: aplay: device_list:240: no soundcards found...
ApportVersion: 1.23-0ubuntu2
Architecture: amd64
ArecordDevices: arecord: device_list:240: no soundcards found...
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/pcmC0D1p', '/dev/snd/pcmC0D2c', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
BuildID: 20110929022028
CRDA: Error: [Errno 2] No such file or directory
Channel: release
Date: Tue Oct 4 13:15:01 2011
ForcedLayersAccel: False
 auto lo
 iface lo inet loopback
IncompatibleExtensions: NoScript - ID={73a6fe31-595d-460b-a920-fcc0f8843232}, Version=2.1.4rc2, minVersion=1.9a2, maxVersion=1.9.6, Location=app-profile, Type=extension, Active=Yes
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110910)
 default via dev eth0 proto static dev eth0 scope link metric 1000 dev eth0 proto kernel scope link src metric 1
 lo no wireless extensions.

 eth0 no wireless extensions.
Profiles: Profile0 (Default) - LastVersion=7.0.1/20110929022028 (Running)

RunningIncompatibleAddons: True
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
UserJS: general.useragent.vendor - Firefox 01/23/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0304
dmi.board.asset.tag: To Be Filled By O.E.M. M3A78-EH
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0304:bd01/23/2008:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM3A78-EH:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

philinux (philcb) wrote :
gluxon (gluxon) wrote :

Firefox displays the "Well, this is embarrassing" screen when the app hutdown improperly. How are you turning off your computer?

philinux (philcb) wrote :

I think this maybe a glitch in the profile now.

I copied it from Natty. I'll give it a whirl with a new profile.

philinux (philcb) wrote :

Yep that was it. I'll mark as invalid.

Changed in firefox (Ubuntu):
status: New → Invalid
Chris Coulson (chrisccoulson) wrote :

No, this is a real bug. This is because Firefox still depends on libgnome to talk to the session manager, without declaring this in the packaging. libgnome got removed from the CD due to other cleaning this cycle, but there's not really any replacement to libgnome (specifically GnomeClient) for cross-desktop apps like Firefox. The solutions are:

1) Do what other gnome applications do and use the gnome-session dbus API directly, but this breaks integration on all non-GNOME desktops
2) Embed a copy of smclient from
3) Use libsm directly rather than relying on GnomeClient or EggSMClient as a higher level wrapper, which I think is what Metacity does

This dropped off my radar because I have other things pulling in libgnome on my system, and nobody else reported it as an issue until now :(

I wonder if we should SRU this for now to pull in libgnome for now, although that's not a good long term solution. Martin, what do you think?

Changed in firefox (Ubuntu):
importance: Undecided → High
status: Invalid → Triaged
philinux (philcb) wrote :

I also realised that this happens on a bad shutdown where REISUB had to be used. On a clean shutdown it does not happen.

Martin Pitt (pitti) wrote :

SRUing this with a new dependency to libgnome sounds OK to me as an unintrusive workaround for oneiric. For precise onwards this should have a better solution, though, like talking to gnome-session through D-Bus perhaps?

Changed in firefox (Ubuntu Oneiric):
importance: Undecided → High
status: New → Triaged
Changed in firefox (Ubuntu):
importance: High → Medium
Changed in thunderbird (Ubuntu Oneiric):
importance: Undecided → High
Changed in thunderbird (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in thunderbird (Ubuntu Oneiric):
status: New → Triaged

Firefox still depends on libgnome and libgnomeui (specifically, GnomeClient - see toolkit/xre/nsNativeAppSupportUnix.cpp) for talking to the session manager. The problem with this is:

1) Those are both deprecated, and have been for a long time
2) They have quite heavy dependencies on a lot of other deprecated libraries (orbit, bonobo, gnomevfs, gconf, glade, gnomecanvas)

We dropped these entirely from the default install in Ubuntu, and this now results in Firefox not shutting down cleanly when users log out of their session (leading to the "Well, this is embarassing" screen when they next start Firefox.

Unfortunately, there isn't really a good replacement for GnomeClient, but the options are:

1) Use the gnome-session DBus interface directly. However, this won't work outside of gnome.
2) Use libsm directly to talk to the session managers xsmp interface, rather than relying on a higher level library. This is more work, but lighter dependencies and would work outside of gnome too.
3) Embed a copy of EggSMClient from , which has a xsmp backend and is light on dependencies (just libsm AFAICT)

Gnome applications seem to do a combination of 1 and 3, but I think option 1 is a non-starter for us, as the dbus interface is completely gnome-specific and doesn't have any API stability guarantees. The only software I know which does 2 is metacity.

What do other people think?

Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed

Considering first option: I understand that using dbus is suitable only for Gnome but libgnome(ui) is also Gnome-only, right? So far only Gnome platform was supported.

I also like third option but I'm unsure what's Mozilla's attitude to embedding foreign sources.

What is for sure that we need to get rid of libgnome(ui). Sooner is better.

(In reply to jhorak from comment #1)
> Considering first option: I understand that using dbus is suitable only for
> Gnome but libgnome(ui) is also Gnome-only, right? So far only Gnome platform
> was supported.

No: libgnome/libgnomeui are using xsmp, so this (supposedly) works on all desktops.

Indeed, libgnome/libgnomeui does work on all desktops. The fact that it pulls in half of gnome to work is unfortunate, but it does work

I like the third option too. If we can get some agreement that that is the best way to go, then I will start work on this

Hmm, EggSMClient is LGPL only, right?

Not sure but I think that this is not compatible with Mozilla's tri-license when embedded codewise.

Wolfgang: ah, good point. We can ask the code to be relicensed if needed, I guess. There shouldn't be tons of contributors to it (a quick count gives me 13 people, most of them being well-known and easy to reach).

Changed in firefox (Ubuntu Precise):
importance: Medium → High
Changed in thunderbird (Ubuntu Precise):
importance: Medium → High
Changed in firefox (Ubuntu Precise):
assignee: nobody → Chris Coulson (chrisccoulson)

Any news on this subject? I may try to create some patch for this one.

Ah, I've already got one for it here. Will attach what I have in a moment, but I'm just doing something else first

Created attachment 608321
Stop using libgnome and libgnomeui on Linux

This is what I've got so far, although it's not ready for review just yet. I haven't made any corresponding changes in or any other part of the build system yet.

Any feedback is welcome on the approach.

This makes session manager integration work without embedding eggsmclient, depending on the GNOME-specific dbus interface, adding any other desktop-specific dependencies or depending on Gtk 3.4 (which has session management in GtkApplication)

It should work outside of GNOME too, although I didn't try this yet.

I've not added a runtime dependency on libSM or libICE, as there wasn't one before. There is a build-time dependency on these though, although the headers for these are already installed on the build machines.

I made a couple of other changes to the behaviour too:
- It now only sends the "session-save" notification when the save style is SmSaveLocal or SmSaveBoth. Saving internal state with a save style of SmSaveGlobal is actually incorrect. This means that Firefox now distinguishes between a normal session exit and a session exit with session saving enabled.
- As "quit-application-requested" might pop up a dialog, it only does this if the interact style is not SmInteractStyleNone
- "quit-application-requested" is only sent after sending SmcInteractRequest and receiving an interact message. If we were using eggsmclient, this would actually happen transparently anyway (using the EggSMClient::quit_requested signal)

I have to say, libSM and libICE are probably the most horrible API's I've ever had to work with :)

tags: added: rls-mgr-p-tracking

I'm getting "IO error occured doing Protocol Setup on connection" when calling SmcOpenConnection.
Libs used:
it dies somewhere in _IceRead function.

Adolfo Jayme (fitojb) on 2013-02-26
no longer affects: firefox (Ubuntu Oneiric)
no longer affects: thunderbird (Ubuntu Oneiric)

Ignore last comment, problem was with Fedora's Gnome shell.

Basically it looks like it's working fine. Problem is that Firefox quit, ie. nsIAppStartup::Quit takes some time and session manager is sometimes impatient and kills Firefox sooner that it actually quits which leads to another 'Well, this is embarrassing' page.

There seems to be session saving code missing yet. Session saving should be supported in eggsmc.

I think problem is that nsIAppStartup::Quit have some async calls and returns sooner than application is actually quit. The session manager is expecting that Firefox quit is finished when it returns from nsNativeAppSupportUnix::DieCB method.

We need to wait in nsNativeAppSupportUnix::DieCB until application actually finish quitting. Is there something for this in current code?

(In reply to jhorak from comment #12)
> I think problem is that nsIAppStartup::Quit have some async calls and
> returns sooner than application is actually quit. The session manager is
> expecting that Firefox quit is finished when it returns from
> nsNativeAppSupportUnix::DieCB method.
> We need to wait in nsNativeAppSupportUnix::DieCB until application actually
> finish quitting. Is there something for this in current code?

We don't need to wait in DieCB() until the app has done most of the quit, but I expect SmcCloseConnection() should not be called until later in the shutdown sequence.

Perhaps there is some later message that can be used to close the SM connection.
Perhaps nsINativeAppSupport::Stop() is appropriate. I'm not clear from the docs that Stop() will always be called.

Perhaps reordering the operations in DieCB() to close the SM connection after nsIAppStartup::Quit may be sufficient.

I wonder whether GnomeClient was explicitly closing the connection, or whether is just got closed with the Display connection.

The SmcCloseConnection called after nsIAppStartup::Quit improved situation a bit, but it's not 100%. The best so far was not to call SmcCloseConnection from DieCB at all. Destructor of nsNativeAppSupportUnix calls DisconnectFromSM and according to my testing it seems to be working just fine.

so what is the status of this bug now? i'm sorta confused based on the last comment. Also, should it be a blocker for wayland support?

There is really no good reason for this code to exist anymore. I ended up with libgnome installed as a dependency for another old program and my Firefox install started misbehaving as a (nearly untracable) sideeffect of that. It took me quite a while to figure out that a Firefox bug could be triggered as a result of installing an unrelated program.

The fact that I didn't have libgnome installed before, and everything was working just fine, is as much of an indication as any that this code needs to die.

Changed in firefox:
status: Confirmed → Fix Released
Fabrizio Gennari (fabrizio-ge) wrote :

This is marked as fixed upstream. So why does is still occur on Artful and Firefox Quantum 59.0.2?

Fabrizio Gennari (fabrizio-ge) wrote :

It also affects bionic and Firefox Quantum 60.0

Fabrizio Gennari (fabrizio-ge) wrote :

In the most recent version (example: Firefox 63.0.3 on Cosmic) the behaviour is different. Firefox actually blocks the restart/shutdown process by showing a popup "X tabs will be closed". But the whole OS also creates a modal dialog box, asking whether to cancel, reboot or turn off, and the modal dialog boxes actually prevents the user from closing Firefox properly using the Firefox pop-up window. If "reboot" or "turn off" are chosen, Firefox will show the dreaded "Well, This Is Embarrassing" screen.

This is an improvement from the previous versions. However, a proper shutdown sequence should allow the user to close applications properly right after initiating the reboot/shutdown procedure.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.