firefox(-gnome-support) should get proxy from gconf

[David Mandelberg]

Maybe Solution:
  1. set config.use_system_prefs to true when -gnome-support package is installed?

-----------------------------

Firefox should get the proxy from gconf so users can use
gnome-network-preferences for all proxy info instead of having to maintain proxy
info in different places.

[Yinbolian (yinbolian)]

My plan is to add a module named "system-pref" under mozilla/pref, which like
autoconf will listen to NS_PREFSERVICE_READ_TOPIC_ID. On Notification it will
start a system-pref service, read some predefined settings from gconf to mozilla.

I have had some draft code, which seems work well for some basic funcs. The code
only for gconf will go into mozilla/pref/system-pref/gconf, other platform can
be supported in the same way.

Any suggestions on that?

[Bugzilla-iwaruna (bugzilla-iwaruna)]

bnesse's no longer at netscape.

[alecf (alecf)]

bolian: this sounds like a reasonable plan, but it belongs in extensions/pref
just like autoconf.

you might also want to take a look at the mac nsInternetConfigService to see how
they handle some of this stuff. (I haven't looked at it myself, so I don't know
if it takes a similar approach or not)

[Yinbolian (yinbolian)]

Oh yes. extensions! my mistake.
system-pref should be under mozilla/extensions/pref, at the same level with
autoconf.

[Yinbolian (yinbolian)]

Created attachment 116406
patch (it works now)

The initial version of the patch comes out.
Below is a brief introduction, Please add comments if you are interested in it:

======System Preference Extension Introduction====================
1.Environment
 The patch is aimed at Gnome2 platform. You need Gtk2 libs to get it build, and
gnome2 desktop to get the extension lib run. So if you are using RH8.0 you are
lucky.
 other platform support is welcome to be add (by who??? ). If you want to do
that please make a new dir under extensions/pref/system-pref, and put your code
there.

2. System Preference
  current only two prefs are added for test, they are http proxy and its port.
They are listed in file
extensions/pref/system-pref/src/gconf/gconf_pref_list.inc,
and its related mozilla prefs are listed in
extensions/pref/system-pref/src/sys_pref_list.inc

Other prefs are expected to be added without code hange
===============================================

Please review, comment, and give r= if you like it.
Thanks

[Bzbarsky (bzbarsky)]

Comment on attachment 116406
patch (it works now)

Why not just use nsIObserver instead of creating nsISystemPrefListener?

Why make the function names for GetInt, etc different from nsIPrefBranch?

Why does nsSystemPref::ReadSystemPref unconditionally lock the pref?

(I didn't read the guts of the code, just the interfaces mostly).

[alecf (alecf)]

I'm with bz - furthermore, I think you should just implement nsIPrefBranch
instead of nsISystemPrefService.. since nsIPrefBranch is frozen, this should be
safe...

[Yinbolian (yinbolian)]

Yes, I can use nsIObserver. But I think nsISystemPrefListener is simpler, only
one string to pass as parameter.

nsIPrefBranch is too large, most things in it is useless here. furthermore,
nsISystemPrefService also include the stuff that is in nsIPrefBranchInternal.
nsISystemPrefService can be replaced by "nsIPrefBranch + nsIPrefBranchInternal"
with many things left unimplemented, why not create a simple
nsISystemPrefService instead, and it also has a good name for that purpose.

>> Why does nsSystemPref::ReadSystemPref unconditionally lock the pref?
That is because I think all the preference coming from system has higher
priority and should be readonly, if user chose to read them from the system.

[Bzbarsky (bzbarsky)]

I think the idea is to reuse existing interfaces that do what you want instead
of creting new custom ones... This _definitely_ applies to the observer
interface. nsIObserver exists so we don't have hundreds of differently named
observer interfaces that all basically have the same method on them.

As for locking; if I understand correctly, the code, as written, will mean a
user cannot set a pref in Mozilla to override the system pref. That seems
backwards to me.

[Yinbolian (yinbolian)]

I think user can choose whether or not he will read prefs from system settings.
If yes, he can only change prefs from system-provided tools outside mozilla. If
user choose not to read prefs from system, he can change anything. Do you think
it is acceptable?

[Bzbarsky (bzbarsky)]

Um... I was under the impression that we would automatically pick up all system
prefs unless the user has overriden them explicitly inside Mozilla (this is what
we do for helper applications, browser appearance, and pretty much every other
place where the system can be overriden).

[Yinbolian (yinbolian)]

What you said applys to the mozilla default setttings. I think we can give a
specail consideration to system preference settings. For example, if users
choose to use system http proxy, and they find mozilla is still using the http
proxy set locally in mozilla. that will be stange.
I think all applications should use system prefs if they choose to do that. In
that way the whole system looks more integrated. Furthermore this is useful for
system administrator to control the settings system wide. At last, user can
override the system setttings in another way, by choose not to use system
settings in mozilla prefs.

[Bzbarsky (bzbarsky)]

So in your setup if I want to override the system HTTP proxy I have to not use
_any_ system prefs in Mozilla?

[Yinbolian (yinbolian)]

Yes. But I know it is not very good.

[Bzbarsky (bzbarsky)]

So what is the downside of the other approach? I can see how users who upgrade
may get confused if they already have Mozilla prefs set for something....

[Yinbolian (yinbolian)]

We can turn off this extension by default.

An alternative could be: system prefs only override mozilla default prefs, and
user prefs can override system prefs. But in that way, if user have prefs, he
can never see the related system prefs, even that feature is turn on, unless he
manaully delete the prefs from his prefs.js.

[Yinbolian (yinbolian)]

Created attachment 116748
patch_v1

Hi a new patch is uploaded according to your comments:
no new idl files added this time, use old ones

Mind to have a look again?

[Yinbolian (yinbolian)]

Created attachment 117156
pach_v2 (add pref to enable/disable system-pref feature)

This patch add the pref to enable/disable system-pref feature.
for example: pref("config.system-pref", enabled)

[Bzbarsky (bzbarsky)]

Comment on attachment 117156
pach_v2 (add pref to enable/disable system-pref feature)

I'm not the right person to review this, since I don't know the GNOME APIs.
(Also, I still think that this is being very poorly integrated with existing
Mozilla preferences.)

[Yinbolian (yinbolian)]

Hi, I want to give more comments on the patch, hope it helpful for reviewers
-------------------------------------------------------------------------
This patch used some GConf APIs, no other Gnome APIs used.
However, the gconf lib is load manually, in order to build/run successfully
whether there is gconf lib or not.

The files in extensions/pref/system-pref/ is assumed to work for all desktops,
only extensions/pref/system-pref/gconf is for gnome (which uses gconf).

The system-pref module listens to the NS_PREFSERVICE_READ_TOPIC_ID just like
extensions/pref/autoconf does, and merge system-prefs into mozilla.

The system-pref is read-only for mozilla and has higher priority than prefs in
mozilla profile. This feature is useful for user/administrator to configure
applications system wide. This feature is disabled by default, users need it can
enable it by add the following line in his pref.js:
  user_pref("config.system-pref", true);

When this feature is enabled, and user want to change the prefs that is read
from system, the only method is to use the system provided pref editor, such as
gconf-editor in gnome.

Currently only two prefs are read from system-pref module, they are used for
examples, other prefs can be added freely. The tow prefs used in the patch are:
"network.proxy.http" and "network.proxy.http_port"
(see system-pref/src/sys_pref_list.inc)
--END-------------------------------------------------------------------------

[Christian Biesinger (cbiesinger)]

Comment on attachment 117156
pach_v2 (add pref to enable/disable system-pref feature)

+ printf("...FAil to Get config\n");

that line should be removed or made ifdef DEBUG.

+enum SysPrefType {

can system preferences not be boolean? or do I misunderstand the purpose of
this enum?

(this is not a review. these are just two comments on the patch.)

[Bzbarsky (bzbarsky)]

OK. Can we at least disable Mozilla UI for prefs when changing them in that UI
would do absolutely nothing? Or should we dump that on the sysadmin? There's
some sort of pref-locking scheme we have in place....

[Christian Biesinger (cbiesinger)]

right - this code should lock the preferences, imho. does it not do it? I
thought bz mentioned something about this in an earlier comment.

[Bzbarsky (bzbarsky)]

It locks them in the pref service. Does that disable the UI?

[Christian Biesinger (cbiesinger)]

If it doesn't, then I either misunderstood the purpose of locking, or the
preferences frontend is broken...

[Christian Biesinger (cbiesinger)]

yup,
http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/content/nsPrefWindow.js#366
checks locked-ness, and sets .disabled=true if so. (it uses nsIPref though...
shouldn't matter, I guess)

[Yinbolian (yinbolian)]

Thanks, Christian and bz

> + printf("...FAil to Get config\n");
> that line should be removed or made ifdef DEBUG.
I will fix that.

+enum SysPrefType {
I forgot to remove this definition, it is not used in the code.

About UI, some code breaks the UI locking feature. see bug 196814, I provide a
patch, and now add you and bz in that CC list.

[Yinbolian (yinbolian)]

Created attachment 117543
patch (remove printf, and unused definition)

[Bryner (bryner)]

Should this be consolidated with widget/src/gtk2/nsGConfInterface.cpp? It seems
like there's some code duplication.

[Yinbolian (yinbolian)]

Yes, widget/src/gtk2/nsGConfInterface.cpp can be removed with this part checked in.

[alecf (alecf)]

Comment on attachment 117543
patch (remove printf, and unused definition)

+ if (!enabled) {
+ SYSPREF_LOG(("...Config config.system-pref is disabled\n"));
+ return NS_ERROR_FAILURE;
+ }

is this really an error condition to Observe()? Just return NS_OK (I think
Observe() results are ignored anyway, but just for good measure..)

+struct SysPrefItem {
+ const char *prefName;
+ PRInt32 prefType;
+};

why store the preftype? you can get it by calling getPrefType()

+static SysPrefItem sysPrefList[] = {
+#include "sys_pref_list.inc"
+ {nsnull, nsnull},
+};

globals (Even when static) should be prefixed with "g" as in "gSysPrefList" -
and you don't need to null terminate it (see below)

also, lists like this should be "const" so they get stored in a read-only
section of memory.

Loops like this:
+ while (sysPrefList[prefIndex].prefName) {
+ ReadSystemPref(prefIndex);
+ SYSPREF_LOG(("Add Listener on %s\n",
sysPrefList[prefIndex].prefName));
+ sysPrefBranchInternal->AddObserver(sysPrefList[prefIndex].prefName,
+ this, PR_TRUE);
+ ++prefIndex;
+ }

you should be using

#define SYSPREFLIST_LENGTH (sizeof(syspreflist) / sizeof(syspreflist[0]))
for (i=0; i<SYSPREFLIST_LENGTH; i++)

actually, it looks like you can share the pref list between your
prefNameMapping (which should have been gPrefNameMapping) and your sysPrefList
maps - why not just have one big map, instead of two maps that you have to keep
in sync?

[Yinbolian (yinbolian)]

>actually, it looks like you can share the pref list between your
>prefNameMapping (which should have been gPrefNameMapping) and your sysPrefList
>maps - why not just have one big map, instead of two maps that you have to keep
>in sync?

Hi Alecf, Thanks for your comments.

I think I should explain the reasons why there are two pref list. "sysPrefList"
and "prefNameMapping" are used for different purposes, they are not needed to be
in sync, and their sizes maybe differ greatly. So they should not be combined
into one.

"prefNameMapping" is the name mapping between Mozila prefs and host system prefs
(i.e. gconf on gnome). I hope to list as many items as possible in
"prefNameMapping". In other systems there may be a very different mapping list.

"sysPrefList" tells mozilla what prefs should be read from system if they are
available in the current version.

For all other things in the comments, I will change in the next revision of the
patch.

-Bolian

[Yinbolian (yinbolian)]

Created attachment 118391
patch (add Alecf's comments)

1. static variable name changes: sysPrefList --> sSysPrefList
2. remove pref type from list
3. while loop --> for loop.
4. return NS_OK instead of NS_ERROR_FAILURE when system config is not enabled.

[alecf (alecf)]

Comment on attachment 118391
patch (add Alecf's comments)

+PR_STATIC_CALLBACK(void)
+ nsSystemPrefModuleDtor(nsIModule *aSelf)
+{
+}
+
+NS_IMPL_NSGETMODULE_WITH_DTOR(nsSystemPrefModule,
+ components,
+ nsSystemPrefModuleDtor)

you don't need the destructor if you aren't implementing one...use use
NS_IMPL_NSGETMODULE

+ nsresult ReadSystemPref(PRUint32 aPrefIndex);

Looking at the code, I don't see why you need ReadSystemPref to go through this
extra level of indirection of passing around an integer. Why can't this just
take const char*? it seems like it would simplify the code quite a bit.. for
instance:

+ for (PRInt16 index = 0; index < sysPrefLen; ++index) {
+ if (!strcmp(aTopic, sSysPrefList[index])) {
+ ReadSystemPref(index);
+ break;
+ }
+ }

Why do this whole loop? it seems like you could just say

ReadSystemPref(aTopic);

...if ReadSystemPref took the pref string directly.

and I think you do need to keep these lists in sync, look:

+static const char* sSysPrefList[] = {
+ "network.proxy.http",
+ "network.proxy.http_port",
+};

and

Index: ./system-pref/src/gconf/gconf_pref_list.inc
===================================================================
+ {"network.proxy.http", "/system/http_proxy/host"},
+ {"network.proxy.http_port", "/system/http_proxy/port"},

I just don't understand why you can't just use the 2nd list as your list of
prefs...

we're getting there...

[Yinbolian (yinbolian)]

>you don't need the destructor if you aren't implementing one...use use
>NS_IMPL_NSGETMODULE
Ok, I will change that in the next patch.

>I don't see why you need ReadSystemPref to go through this
>extra level of indirection of passing around an integer.
My aim is to check whether the "aTopic" is the pref in interested (in the
table). In case we receive some garbage.

> and I think you do need to keep these lists in sync, look:
I am not understood, I think. Ok, think of this situation,

static const char* sSysPrefList[] = {
    "network.proxy.http",
};

and

Index: ./system-pref/src/gconf/gconf_pref_list.inc
===================================================================
    {"network.proxy.http", "/system/http_proxy/host"},
    {"network.proxy.http_port", "/system/http_proxy/port"},
    {"network.http.connect.timeout", "/system/network/http/connect/timeout"},
    {"network.http.request.timeout", "network/http/request/timeout"},
    {"font.default", "/system/font/default"},
    {"font.size.variable.ar", "/font/size/variable/ar"},
    {"font.size.fixed.ar", "font/size/fixed/ar"},

The first list stands for mozilla, it says "I only want these prefs read from
system".

The second list stands for the system prefs, it says "Currently I support all
these prefs in mozilla".

So I think, they are not needed to be in sync.
I wait for your comments on this and on other parts of the patch before I made
another patch. Thanks.

[alecf (alecf)]

You don't have to worry about getting garbage in... HOWEVER you've got one thing
a little mixed up! the topic ona pref change will ALWAYS be
NS_PREFBRANCH_PREFCHANGE_TOPIC_ID - so thats what you can use to verify that
you're getting a prefchanged notification, and that guarantees that the pref in
question is one you've requested observation on.

as for the two lists.. first of all you need to document that very heavily. you
need to explain what it means to be 'kept in sync' - you should also refer to
the gconf list, and explain the difference between the two.

In fact, you need to go through this whole patch and add comments all over the
place.. this code needs to be very heavily documented. Thanks.

also here:
+ nsresult GetAtomForMozKey(const char *aMozKey, PRUint32 *aAtom) \
+ {return GetAtom(aMozKey, 0, aAtom); }
+ const char *GetMozKey(PRUint32 aAtom) \
+ {return GetKey(aAtom, 0); }

you don't need the "\" at the end of the line - this isn't a macro, and the \
will confuse editors like emacs.

[Yinbolian (yinbolian)]

Ok, I will remove that unneccessary checking.
And I will add more comments.

[Yinbolian (yinbolian)]

Created attachment 118755
patch (add many comments)

[Yinbolian (yinbolian)]

Comment on attachment 118755
patch (add many comments)

alecf, mind to continue the review?

[Alexander Sack (asac)]

In order to apply new patches we need to submit this upstream and get r+sr first. Probably this is already in bugzilla.

[Brad (brad-lackey)]

Any movement on this? Has it been submitted upstream? This bug is a year and a half old, and other distros have figured this out. It's time to have a unified proxy configuration.

[Freddy Martinez (freddymartinez9)]

Anyone have an upstream link?

[John Vivirito (gnomefreak)]

I just did a quick look upstream and didnt see one. Can you please file it upstream and give me the link to it. I will keep looking in the meantime.

[John Vivirito (gnomefreak)]

Here is the upstream search https://bugzilla.mozilla.org/buglist.cgi?quicksearch=proxy but i didnt see your exact issue.

[Alexander Sack (asac)]

On Tue, Mar 13, 2007 at 01:18:30PM -0000, John Vivirito wrote:
> Here is the upstream search
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=proxy but i didnt
> see your exact issue.
>

The bugzilla gnome integration bug master bug is

 https://bugzilla.mozilla.org/show_bug.cgi?id=233462

if its not in one of the Depends On: bugs listed it has probably not
been requested upstream.

For your convenience the list of bugzilla bugs you should check before
submitting a new bug:

    18732 93789 110647 118294 118295 118296 118299 118302
    118303 118308 118312 119735 123197 164776 171349 174629
    174639 175095 175099 175236 175567 178713 180741 187274
    190031 193001 195708 198855 214715 215092 215219 225148
    230144 231035 232102 233242 233305 233456 233460 233461
    235895 236579 237534 237535 237542 237822 238052 242254
    242255 242897 242900 244787 245497 247654 252242 262258
    285775 296443 306434 308368 311340 320122 331162 336270
    353785

If you find the right one or posted a new one, please drop the bug
number here.

 - Alexander

[Anderson Lizardo (lizardo)]

According to https://bugzilla.mozilla.org/show_bug.cgi?id=195708 (which seems the correct upstream bug for this) the bug has been marked "RESOLVED FIXED" and not "REJECTED". Any reason why it has been marked this way?

[Alexander Sack (asac)]

thanks for finding upstreawm bug. Looking at the patch attached to it I saw that this must be supported since 2003 somehow.

Can you please test to set the following preference to true in about:config:

  config.use_system_prefs

then restart firefox and let me know if proxy settings are properly pulled in from gconf. In addition, the following settings should be taken from your gconf instead of mozilla system pref. Please verify if all work as well:

    {"network.proxy.http", "/system/http_proxy/host"},
    {"network.proxy.http_port", "/system/http_proxy/port"},
    {"network.proxy.ftp", "/system/proxy/ftp_host"},
    {"network.proxy.ftp_port", "/system/proxy/ftp_port"},
    {"network.proxy.ssl", "/system/proxy/secure_host"},
    {"network.proxy.ssl_port", "/system/proxy/secure_port"},
    {"network.proxy.socks", "/system/proxy/socks_host"},
    {"network.proxy.socks_port", "/system/proxy/socks_port"},
    {"network.proxy.no_proxies_on", "/system/proxy/ignore_hosts"},
    {"network.proxy.autoconfig_url", "/system/proxy/autoconfig_url"},
    {"network.proxy.type", "/system/proxy/mode"},

[Alexander Sack (asac)]

setting upstream bug

[Mads Chr. Olesen (shiyee)]

In my testing, it does NOT work.
When setting config.use_system_prefs the settings you listed become "locked", and the firefox network dialog becomes grayed out.
The settings from gconf is however not used, in about:config e.g. type is 0 (no proxy) and the various host fields are blank.

I have tried to get debug info using
export NSPR_LOG_FILE=/tmp/firefox-debug.log
export NSPR_LOG_MODULES="all:5"
firefox

but the only mention of system-pref is:
-1221551264[805c548]: Loaded library /usr/lib/firefox/components/libsystem-pref.so (load lib)

Currently compiling firefox with DEB_BUILD_OPTIONS=debug to see if that makes any difference to the debug output.

[Alexander Sack (asac)]

On Fri, Jun 22, 2007 at 10:16:28AM -0000, Mads Chr. Olesen wrote:
> In my testing, it does NOT work.
> When setting config.use_system_prefs the settings you listed become "locked", and the firefox network dialog becomes grayed out.
> The settings from gconf is however not used, in about:config
> e.g. type is 0 (no proxy) and the various host fields are blank.

Hmm the lock of preferences is ment to happen. I am unsure if one
should see the gnome settings in about:config ... but i assume one
should be able to see them live. I assume you really tested if it
works or not, right? Or did you just look at settings?

 - Alexander

[Mads Chr. Olesen (shiyee)]

Yes, I also tested whether it works, admittedly only by setting the proxy and seeing that i'm still able to connect which should not be possible if it used the non-accessible proxy server.

[Alexander Sack (asac)]

On Fri, Jun 22, 2007 at 02:31:33PM -0000, Mads Chr. Olesen wrote:
> Yes, I also tested whether it works, admittedly only by setting the
> proxy and seeing that i'm still able to connect which should not be
> possible if it used the non-accessible proxy server.
>

Hmmm ... that sounds like a 'negative-test' which probably is good
enough, but might be wrong. Who knows for sure what magic is build in
somewhere and what happens in case proxy cannot be reached ;).

Anyway, I will read the code, as at a glance it looked reasonable to
me.

Stay tuned,

 - Alexander

[Matthew Tighe (tighem)]

I'm just confirming this in Firefox 3.0 under Hardy. Certainly would be nice if network proxy settings worked for all default applications, especially firefox.

[Alexander Sack (asac)]

yes, the gconf backend should be fixed to allow you to use your gconf proxy configuration.

We have a patch for that in midbrowser which we should consider to take for hardy.

 - Alexander

[Alexander Sack (asac)]

this definitly won't be fixed in firefox 2 anymore.

[Alexander Sack (asac)]

this is a xulrunner-1.9 bug.

[Alexander Sack (asac)]

... not firefox one.

[Alexander Sack (asac)]

fyi, firefox 3 now supports to use system proxy settings. those should indirectly be inherited from gconf and cover a good proportion of use cases that require this fix at least.

[Matthew Tighe (tighem)]

Alex,

This is still not working. The proxy tab now has an option for taking the settings from the system, but I still cannot connect via firefox when that is set. Manually setting the proxy server does work.

[Matthew Tighe (tighem)]

I did some more testing this evening. This works from gnome-terminal, but not from the menu. Start FF from the terminal and it uses the proxy server defined in the Network Proxy applet, but not if run from the menu. The big difference between the two is FF run from the menu has a parent process ID of 1 (/sbin/init), while FF from the terminal has a parent process ID of gnome-terminal.

[Anderson Lizardo (lizardo)]

It means that firefox is probably getting proxy information from $http_proxy environment variable (which is set by gnome-terminal).

[Alexander Sack (asac)]

midbrowser gconf patch ... needs cleanup

[Alexander Sack (asac)]

clean version of the patch (thanks to jimmy!)

[Alexander Sack (asac)]

applies cleanly. only issue i currently see with putting this into libxul is that it will pull in more dependencies.

I think we might be able to fix this, by building the gconf specific backend somewhere else and shipping it in gnome-support.

[Uwe Gottschling (uwe-gottschling)]

Crash while starting google video.

[Uwe Gottschling (uwe-gottschling)]

crash while starting flash player 9 video

[Juan Carlos (jcrodriguez02)]

It keeps freezing and crashing in the middle of any process. Sometimes I have to force it to quit.

Juan Carlos Rodríguez Abreu
Independent Business Owner - IBO
Cel.: 809 707 8403 / 809 754 1080
www.quixtar.com
<email address hidden> / <email address hidden>

"Representante exclusivo de Nutrilite® & Artistry®"

> From: <email address hidden>
> To: <email address hidden>
> Date: Mon, 14 Apr 2008 17:03:06 +0000
> Subject: [Bug 23369] Re: firefox(-gnome-support) should get proxy from gconf
>
> crash while starting flash player 9 video
>
> --
> firefox(-gnome-support) should get proxy from gconf
> https://bugs.launchpad.net/bugs/23369
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Mozilla Firefox Browser: Fix Released
> Status in Source Package "firefox" in Ubuntu: Won't Fix
> Status in Source Package "firefox-3.0" in Ubuntu: Invalid
> Status in Source Package "xulrunner-1.9" in Ubuntu: Triaged
>
> Bug description:
> Maybe Solution:
> 1. set config.use_system_prefs to true when -gnome-support package is installed?
>
>
> -----------------------------
>
> Firefox should get the proxy from gconf so users can use
> gnome-network-preferences for all proxy info instead of having to maintain proxy
> info in different places.

_________________________________________________________________
Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how.
hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_skydrive_packup_042008

[Alexander Sack (asac)]

moblin needs to clean up this patch to make the gconf part an independent component that we can push to -gnome-support package. otherwise this would add gconf for all firefox users, which is not acceptable from a general distro pov.

Unless someone comes up with an improved patch i keep the patch commented in xulrunner-1.9 and thus it will miss the inital hardy train. Remilestoning to 8.04.1 accordingly.

[Uwe Gottschling (uwe-gottschling)]

Crash while playing radio stream : http://www.dradio.de/aodflash/player.php?station=&/

[Murray Cumming (murrayc)]

Uwe Gottschling, I think you have the wrong bug. You are making a mess of this one.

[Ogrok (roch1200)]

Sorry i will check before sent! thanks

2008/4/15, Murray Cumming <email address hidden>:
>
> Uwe Gottschling, I think you have the wrong bug. You are making a mess
> of this one.
>
>
> --
> firefox(-gnome-support) should get proxy from gconf
> https://bugs.launchpad.net/bugs/23369
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Vicenç Roch

[Ogrok (roch1200)]

I can listen that radio playing, the problem is when i try to see a youtube
video it chrashes down, but if i try again sometimes works! i couldn't
understantd!
thanks!

2008/4/15, Uwe Gottschling <email address hidden>:
>
> Crash while playing radio stream :
> http://www.dradio.de/aodflash/player.php?station=&/
>
>
> --
> firefox(-gnome-support) should get proxy from gconf
> https://bugs.launchpad.net/bugs/23369
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Vicenç Roch

[John Vivirito (gnomefreak)]

Ogrok,
File a seperate bug report and attach your crash report to the new bug. This bug is not about a crash its more about how fireefox-gnome-support handles proxies.

[Uwe Gottschling (uwe-gottschling)]

crash while starting firefox.

[John Vivirito (gnomefreak)]

Uwe,
 Please do not comment on this bug report about seeing the same problem its just causing spam for most people, please file a seperate bug report and attach your crash report to that bug report.

[cwong1 (carl-wong)]

Please try the latest midbrowser and Xulrunner. It worked for me.

[Alexander Sack (asac)]

On Thu, May 22, 2008 at 04:34:37PM -0000, cwong1 wrote:
> Please try the latest midbrowser and Xulrunner. It worked for me.
>
> ** Changed in: moblin-browser
> Status: New => Invalid
>

err, this bug tracks the progress, moving the code into the main
xulrunner code. It only works for you when using the build in mobile
ppa.

 affects moblin-browser
 status confirmed

 - Alexander

[Alexander Sack (asac)]

On Mon, Jun 02, 2008 at 12:26:19PM -0000, Zhao Fan wrote:
> ** Changed in: moblin-browser
> Importance: Undecided => Low
>

if you think that this is importance low, then i dont understand why
we maintain this patch in ~ubuntu-mobile PPA. Please clarify about the
importance.

De facto, having this bug open means: no gconf proxy setting in in
distributions.

 - Alexander

[Twalker (twalker)]

mass remove verifyme requests greater than 4 months old