← Back to branch summary

~mozillateam/firefox/firefox.yakkety

« back to all changes in this revision

Viewing changes to debian/patches/dont-reset-user-prefs-on-upgrade.patch

  • Committer: Chris Coulson
  • Date: 2011-09-24 18:13:00 UTC
  • mto: This revision was merged to the branch mainline in revision 879.
  • Revision ID: chris.coulson@canonical.com-20110924181300-3r9id02mgap6gop9
https://launchpad.net/bugs/758111
* Provide a useful error message when trying to build the source package
  with an out of date control file
  - update debian/rules
* Provide a way to prevent the source package from being built if the list
  of shipped locales changed upstream. Note that this is disabled on
  nightly and aurora
  - update debian/rules
  - add debian/extract-file.py
* Move custom scripts to debian/build
  - move debian/get-xpi-id.py to debian/build/get-xpi-id.py
  - move debian/refresh-supported-locales.pl to
     debian/build/refresh-supported-locales.pl
  - move debian/extract-file.py to debian/build/extract-file.py
  - update debian/rules
* Dropped patches fixed upstream:
  - remove debian/patches/build-fix-for-no-ENABLE_YARR_JIT.patch
  - remove debian/patches/compile-pldhash-as-C++.patch
  - update debian/patches/series
* Refresh patches:
  - update debian/patches/firefox-kde.patch
  - update debian/patches/mozilla-kde.patch
  - update debian/patches/ubuntu-codes-google.patch
* Update support for doing PGO builds:
  - Add "mk_add_options MOZ_PGO=1" to mozconfig when doing a PGO build,
    rather than changing the make target to "profiledbuild"
    - update debian/mozconfig.in
    - update debian/rules
  - Run the profiling 10 times
    - update debian/mozconfig.in
  - Don't turn off the crash reporter or force unofficial branding for PGO
    builds
    - update debian/rules
  - Don't force the compiler to gcc-4.5 when doing PGO builds. Instead,
    we will just rely on the default compiler and not enable PGO on
    Ubuntu versions which don't have a new enough toolchain
    - update debian/rules
* Shrink the default mozconfig right down, by using defaults rather than
  forcing things like --disable-system-cairo and friends. We still retain
  the ability to override the defaults though by setting MOZ_OVERRIDE_SHLIBS
  to either "tree" or "system", but we use upstream defaults now. We also
  drop the pkg-config checks in debian/rules which allowed a fallback build
  configuration when dependencies aren't satisfied. Really, the build should
  just fail here rather than continuing in some undesirable fallback mode
  - update debian/firefox-dev.install.in
  - update debian/firefox-dev.links.in 
  - update debian/mozconfig.in
  - update debian/pkgconfig/libxul.pc.in
  - update debian/control.in
  - update debian/rules
* Refresh build-depends, as this hasn't been done for a while:
  - Drop patchutils, libxft-dev, libxinerama-dev, libgnome2-dev and bzip2.
    These don't appear to be needed
  - Drop liborbit2-dev - only appears to be required if there is no libidl
  - Add libglib2.0-dev, libext-dev, libfontconfig1-dev and libpango1.0-dev,
    as the configure script checks for these directly
  - Add minimum versions to libgconf2-dev, libgnomevfs2-dev, yasm and
    libgnomeui-dev
  - Specify minimum versions for libnspr4-dev, libcairo2-dev, libsqlite3-dev
    and libnss3-dev when using system versions of those libs
* Disable gconf support on >= 11.10
  - update debian/rules
  - update debian/mozconfig.in
* Refresh binary dependencies:
  - Change ubufox recommends to xul-ext-ubufox
  - Drop psmisc and fontconfig depends. We don't appear to use any binaries
    from either of these packages
  - Drop debianutils dependency. This is an essential package
* Disable printing of a lot of makefile commands to reduce noise. Also
  add some headers in various places
  - update debian/rules
* Introduce a branch-specific config file (debian/config/branch.mk) which
  will hold settings that are tied to a specific branch, and which shouldn't
  be merged between branches when merging new Firefox versions (eg, whether
  the crash reporter should be enabled on a branch). The idea is to confine
  these types of settings to a single file
  - add debian/config/branch.mk
  - update debian/rules
* Move debian/locales.* to debian/config
  - move debian/locales.shipped => debian/config/locales.shipped
  - move debian/locales.unavail => debian/config/locales.unavail
  - move debian/locales.blacklist => debian/config/locales.blacklist
  - update debian/rules
  - update debian/build/refresh-supported-locales.pl
* Move debian/testsuite.mk to debian/build
* Don't open about:blank from the New Window quicklist entry
  - update debian/firefox.desktop.in
* We need to keep the complete list of language packs (shipped and
  transitional) in sync between branches. However, this was proving to be
  difficult because the list was split across 2 files (locales.shipped
  and locales.unavailable). Rework this so that we have a locales.all
  (containing the list of current and past language packs), and a
  locales.shipped. The locales.all can be easily kept in sync between
  branches now, so we end up with the correct transitional language packs
  on branches which have some languages disabled. This also makes it
  more complicated to add the language packs to debian/control though, so
  we offload this to a new perl script now rather than trying to do it all
  in bash
  - add debian/build/dump-langpack-control-entries.pl
  - update debian/build/refresh-supported-locales.pl
  - add debian/config/locales.all
  - update debian/config/locales.shipped
  - remove debian/config/locales.unavailable
  - update debian/control
  - update debian/rules
* Touch debian/control.in during clean to force a refresh of debian/control,
  so we can check if it is out-of-date and fail if it is
  - update debian/rules
* Ensure that we get the correct package relationships depending on the
  target distro version
  - update debian/control.in
  - update debian/rules
  - refresh debian/control
* Drop the mozilla-devscripts dependency. We were only using this for creating
  tarballs anyway. Instead, implement our own get-orig-source target, which
  also fixes some problems we were having
  - update debian/control.in
  - remove debian/moz-rev.sh
  - update debian/rules
  - remove debian/mozclient/firefox.mk
  - remove debian/mozclient/firefox.conf
  - update debian/config/branch.mk
  - add debian/build/create-source
  - add debian/build/get-orig-source.mk
* Drop the 'nobinonly' suffix from the version number. All this really does
  is make the version number longer without adding any useful information,
  because:
  - We don't strip all binary files as there are a lot remaining which are
    used by the test-suite (eg, images, fonts, videos, sqlite dbs, extensions)
  - Stripping binary files from the source tarball isn't the only change we
    make to it. We also merge in the upstream l10n data, but we don't
    indicate that in the version number
* Keep a copy of shipped-locales outside of the embedded tar.bz2. This
  makes it faster to verify the list of shipped locales when creating
  source packages
  - update debian/build/create-tarball.py
  - update debian/build/extract-file.py
  - update debian/rules
* When calling refresh-supported-locales, automatically refresh
  debian/control too
  - update debian/rules
* Fix LP: #758111 - update ubuntulinux.org bookmark - thanks to Jonathan
  Rothwell for the patch

Show diffs side-by-side

added added

removed removed

Lines of Context:
debian/patches/dont-reset-user-prefs-on-upgrade.patch
1
 
Description: This bug is due to the fact, applications are restarted before extension
2
 
 defaults are loaded.
3
 
 
4
 
 To reproduce, choose any preference and set the values like:
5
 
 system default:
6
 
   pref("prefkey",systemvalue);
7
 
 extension default:
8
 
   pref("prefkey", extensiondefault);
9
 
 user pref:
10
 
   user_pref("prefkey", systemvalue);
11
 
 
12
 
 Next, trigger application behaviour similar to upgrade by removing compreg.dat
13
 
 from profile and start the application.
14
 
 
15
 
 Result:
16
 
 User sees extensiondefault after upgrade, because the user_pref has been
17
 
 eliminated ... which is definitly not what the user expects because he explicitly
18
 
 had *systemvalue* set before the upgrade.
19
 
 
20
 
 Evaluation:
21
 
 The bug happens because restart is performed *before* extension defaults have been
22
 
 loaded and the prefapi.cpp always eliminate user preference if the user preference
23
 
 is equal to the actual default (which happens to be extensiondefault normally  - so
24
 
 no reset, but is systemvalue during restart).
25
 
 
26
 
 Fix:
27
 
 1. savePrefs should not try to be smart ... this patch removes the heuristic that guesses
28
 
 whether a setting can be eliminated or not; it should be sufficient to only eliminate
29
 
 prefs in hashPrefs.
30
 
 
31
 
 2. This patch prevents hashPrefs from eliminating the user pref in case we are in
32
 
 *startup* ... unfortunately no such state info exists, which lets us guess that
33
 
 we are in startup for the previously not dealt case: !set_default && 
34
 
 !pref_ValueChanged(pref->defaultPref, value, type) && !PREF_HAS_USER_VALUE(pref).
35
 
 
36
 
 If is the case we explicitly remember that this setting is a user-pref ...
37
 
 even though it might be temporarily equal to the default pref.
38
 
Author: Alexander Sack <asac@ubuntu.com>
39
 
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=467766
40
 
Bug-Ubuntu: https://launchpad.net/bugs/548866
41
 
Forwarded: https://bugzilla.mozilla.org/attachment.cgi?id=351173
42
 
 
43
 
---
44
 
 modules/libpref/src/prefapi.cpp |   16 ++++++++++++----
45
 
 1 file changed, 12 insertions(+), 4 deletions(-)
46
 
 
47
 
--- a/modules/libpref/src/prefapi.cpp
48
 
+++ b/modules/libpref/src/prefapi.cpp
49
 
@@ -328,10 +328,7 @@ pref_savePref(PLDHashTable *table, PLDHa
50
 
     // where we're getting our pref from
51
 
     PrefValue* sourcePref;
52
 
 
53
 
-    if (PREF_HAS_USER_VALUE(pref) &&
54
 
-        pref_ValueChanged(pref->defaultPref,
55
 
-                          pref->userPref,
56
 
-                          (PrefType) PREF_TYPE(pref))) {
57
 
+    if (PREF_HAS_USER_VALUE(pref)) {
58
 
         sourcePref = &pref->userPref;
59
 
     } else {
60
 
         if (argData->saveTypes == SAVE_ALL_AND_DEFAULTS) {
61
 
@@ -748,6 +745,17 @@ nsresult pref_HashPref(const char *key,
62
 
                 pref->flags &= ~PREF_USERSET;
63
 
                 if (!PREF_IS_LOCKED(pref))
64
 
                     valueChanged = PR_TRUE;
65
 
+            } else {
66
 
+                // this is tricky: we have !set_default ...
67
 
+                // thus we are setting a user pref; however the user
68
 
+                // pref set is same as *current default*; this normally
69
 
+                // means to un-set ... however since we have
70
 
+                // !PREF_HAS_USER_VALUE(pref) this can only be during
71
 
+                // startup
72
 
+                pref_SetValue(&pref->userPref, value, type);
73
 
+                pref->flags |= PREF_USERSET;
74
 
+                if (!PREF_IS_LOCKED(pref))
75
 
+                    valueChanged = PR_TRUE;
76
 
             }
77
 
         }
78
 
         else if ( !PREF_HAS_USER_VALUE(pref) ||