Open Bug 1036903 Opened 10 years ago Updated 3 years ago

SeaMonkey does not remember default client startup settings on Linux.

Categories

(SeaMonkey :: General, defect)

SeaMonkey 2.26 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: uhlar, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26.1 (Beta/Release)
Build ID: 20140629155734

Steps to reproduce:

Seamonkey 2.26.1 is asking for being default client for different protocols on each startup.
All possibilities are listed, but when I click OK, it does not remember the status.
This did not happen with 2.26 nor before.
does not happen on windows. Tried LXDE and olvwm without desktop environment.
Does this work if you use the GNOME window manager? SeaMonkey is a GTK+ application on Linux.
Summary: default client startup → SeaMonkey does not remember default client startup settings on Linux.
I have tried in gnome envinonment with openbox or metacity window manager, still the same
I also see this problem for quite some time now (also on beta, aurora and central) on Kubuntu 14.04 64-bit. SeaMonkey opens this dialog on each startup...
Someone pointed out to me that this might be because we don't build with support for gio (or was it gconf? - I'm not a Linux person). Will possibly be fixed when we move to the new CentOS builders. Currently we are on CentOS5 which have too old GTK+ libraries.
I should have pointed out that I make my own build (and did for 2.26 when it worked correctly) 

I have libgconf devel packages installed, libgconf seems to be loadded but not explicitly linked with any of seamonkey libraries (and was not with 2.26 libs, i still have them included).

I haven't change mu build process nor removed any devel packages between 2.26 and 2.26.1 builds.

If you need me to check/verify anything, just ask.
(In reply to Philip Chee from comment #5)
> Someone pointed out to me that this might be because we don't build with
> support for gio (or was it gconf? - I'm not a Linux person). Will possibly
> be fixed when we move to the new CentOS builders. Currently we are on
> CentOS5 which have too old GTK+ libraries.

I do my builds on my own on a CentOS 6 machine and because of that did not have to disable building gio and gconf support - and the bug still happens...
still happens with 2.29

I have libgconf2-dev debian package installed, just tell me if I have to use any of following:

libgconfmm-2.6-dev - C++ wrappers for GConf (development files)
libgconf2.0-cil-dev - CLI binding for GConf 2.24
libghc6-gconf-dev - transitional dummy package
libghc-gconf-dev - Binding to the GNOME configuration database system
libgconf-bridge-dev - Bind GObject properties to GConf keys (development files)

libgio2.0-cil-dev - CLI binding for the GIO I/O stack 2.22
libghc6-gio-dev - transitional dummy package
libghc-gio-dev - Binding to the GIO
libomxil-bellagio0-components-fbdevsink - Frame Buffer Video Sink components for Bellagio OpenMAX IL
libomxil-bellagio-dev - implementation of OpenMAX IL, development files

perhaps the C++ wrappers?
(please remember that this did not happen with 2.26)
still happens with 2.31.
I guess the problem lies in 
comm-release/suite/shell/src/nsGNOMEShellService.cpp

where the only changes between 2.26 ad 2.26.1 were 

MOZ_UTF16("brandShortName")

instead of 

NS_LITERAL_STRING("brandShortName").get(),

as parameter of brandBundle->GetStringFromName and several "nullptr" instead of "NULL" values
any idea how to debug functions?

nsGNOMEShellService::IsDefaultClient
nsGNOMEShellService::SetDefaultClient

Probably works when bug 1544739 is done.

Would be great if someone can try the next 2.53 from Bill:
http://www.wg9s.com/comm-253/

Depends on: 1544739
You need to log in before you can comment on or make changes to this bug.