maemo.org Bugzilla – Bug 3876
some modifications in about:config reset to default when browser restarted
Last modified: 2009-10-22 07:57:37 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
1. type about:config in browser's address bar
2. scroll down and we could see that advanced.mailftp is set to false
3. set this entry to true by input advanced.mailftp into the Name and true into
Value on the top of this page and then press the button Set Preference
4. scroll down again and we could see that this value has been changed to true
5. close browser
6. open browser again and type "about:config", we could see that
"advanced.mailftp" is reset to false
7. generally speaking, modifications to existing entries or newly added
key-value pairs won't retain after browser is closed
i just tried this w/ advanced.mailftp and it persisted.
there are quite a few prefs which are destroyed at startup (not technically
shutdown), however the one you picked isn't among them:
generally, the ones destroyed are visible in this list:
specifically this block:
there are a number of bugs in this block, and in most cases there's a bug in
this system about them.
...plus for example changing general.useragent.vendor (see bug 3868).
Ran into this myself yesterday. :-/
vendor is one of the ones that are explicitly replaced
the one you should be setting is:
instead of using vendor+friends.
I just get confused.
It seems that all the entries in "about:config" are listed in
/usr/lib/microb-engine/greprefs/all.js, and they are identical.
According to your comment, values in this file will be destoryed(be reset to my
understanding), so all the entries will restore from all.js when browser
restarted. If this is correct, this matches what I saw and can explain why
modifications don't retain.
But you said your testing persisted, and I found that "advanced.mailftp" does
exist in all.js, this conflicts you mentioned "however the one you picked isn't
Anything I have done wrong?
i'm not sure which link gave you the impression that i said that all.js entries
would be destroyed.
all.js has default values.
if you try to set a value to something that doesn't match all.js,
it should be saved.
if you try to set a custom value and it matches all.js,
the fact that it's a custom value will be lost (this is only interesting if
the default value later changes).
however. there is code in microb...eal (gmozillaweb.c) which is fairly stupid
(understatement) and it will just stomp over certain preferences that it thinks
need to be set.
if your pref isn't listed in that file, it should persist....
Sorry I misunderstood you.
What I thought(and what I see in my N800 so far) is that all entries in
"about:config" are restored with the default values in all.js if they are
modified, and newly added entries will simply be removed.
But you said that these values should be saved, unless be explicitly set by
I just don't know where the problem is. My system is clean, I didn't install
any package after I updated the firmware.
(In reply to comment #6)
> and newly added entries will simply be removed.
Does not happen here. Added "general.useragent.override" yesterday and it
remained after restarting.
(In reply to comment #7)
As to newly added entries, I just entered some arbitrary key-value pairs, say
with Name equals to "a" and Value equals to "b". Could this be a reason why
What happended to your device if you change the value of "advanced.mailftp"
from false to true and then restart browser? Will this value be saved or just
restored to false?
It will be restored to false.
Then it should be a bug.
And maybe invalid newly added entries would be removed?
sorry, there's no such thing as an invalid entry. if you create 'a' = 'b', it
can you ls -al `find ~ -name prefs.js` from a terminal?
it's possible some random .deb or equiv has changed ownership of prefs, if that
happens, it's not our fault (the bug's invalid, unless you want to use it in a
crusade against whichever package broke your prefs, however, i'd recommend a
-rw------- 1 user users 1942 Nov 23 13:43 /home/user/.mozilla/microb/prefs.js
It shouldn't be the case you mentioned someone else changed the ownership,
since I do the test as soon as I updated the firmware, not any other packages
I would be glad to provide more information if you want me to do.
I've found the reason. It is because the preference is not saved.
Adding the following code to gmozillaengine.c:load_finished_cb could fix this
bug, but I'm not sure if this is a clean and elegant way or not.
//ULOG_DEBUG_F("last_net_status: %i", self->last_net_status);
self->is_loading = FALSE;
+ // save preference here
+ gchar * location = gtk_moz_embed_get_location(embed);
+ const gchar *prefix = "about:config?prefname=";
+ if (location && g_ascii_strncasecmp(location, prefix, strlen(prefix))==0)
GWebEngineEncoding encoding = g_mozilla_engine_get_encoding (embed);
that's terribly broken. something somewhere in the code needs to handle saving
prefs when they change. preferably vaguely lazily and probably if dirty at
(In reply to comment #14)
> that's terribly broken. something somewhere in the code needs to handle saving
> prefs when they change. preferably vaguely lazily and probably if dirty at
So it's a ugly fix:(
I haven't studied the source code very carefully yet and I don't know how to do
just like you recommended ...
Waiting for better solution
Created an attachment (id=1066) [details]
patch for this issue
I couldn't have provided this patch without timeless's help, thanks!
Unfortunately this is a WONTFIX for Diablo (not enough priority).
Now wondering whether this will be still valid for Fremantle...
Changing "general.useragent.vendor" seems to work for me on Fremantle.
Even after a browser restart my own value is there.
Same with changing "advanced.mailftp".
Any other testcase or can I close this as WORKSFORME/FIXED in Fremantle?
zhihai: sorry i didn't get back to you, but indeed you found the right place.
the patch can be shortened to this:
Fremantle uses a different about:config than the one that shipped in Diablo.
the general bits in microb which stomp on preferences are still present. but
indeed the problem that zhihai's patch addresses is not a problem in Fremantle.
I have no idea how/why that line got lost when I wrote the html version :(.
Marking patches of interest to Diablo (Maemo4) community updates, please excuse