This introduces a debugging pref, "services.sync.debug.ignoreCachedAuthCredentials".
This flag allows testers to disable caching of authentication credentials
to make debugging of expired and revoked credentials easier. This will
help expedite any visble auth errors resulting from a expired or revoked
FxA session token, e.g., from resetting or changing the FxA password.
This pref is not set by default.
This patch addresses a bug in the following scenario:
User has browser 1 connected to sync and open, and resets her password
on browser 2. Eventually the browser detects the need to reauthenticate
the user, and prompts the user. When the user entered her new password,
the browserid_identity module failed to re-derive a new syncKeyBundle
from the new password and happily used the old one. Chaos ensued.
This patch mitigate the problem by calling resetCredentials at the
start of initializeWithCurrentIdentity(), which will clear the
syncKeyBundle, along with other credentials. Previously this
function was only resetting this._shouldHaveSyncKeyBundle.
I also removed a misleading comment about the syncKeyBundle being
cleared when it wasn't.
It was observed that FHR was sending invalid JSON payloads to the
server. Specifically, JSON payloads contained invalid Unicode strings.
Investigation revealed that the culprint was CommonUtils.convertString()
silently swallowing high bytes. When the Bagheera client went to gzip
the JSON payload, the input buffer into gzip was missing high bytes.
This patch changes the bagheera client to UTF-8 encode strings before
gzip, thus ensuring all data is preserved. A corresponding change was
also added to the mock bagheera server implementation.
Alternatively, we could have changed CommonUtils.convertString() to
be high byte aware. However, many consumers rely on this function.
This patch is written with the intent of being uplifted and the change
performed is targeted at the specific problem.
Tests for Unicode preserving behavior have been added to both the
generic Bagheera client and to FHR. The latter test is arguably
not necessary, but peace of mind is a good thing, especially with
FHR.
See also bug 915850.
--HG--
extra : rebase_source : 4efddea7767c2e5f8cf19df247c3aba07c40eec6
extra : amend_source : ae3b6d89efa54fc9ed1794404476622946ad4b22
The data reporting notification was over-complicated. It wasn't
displayed for +24hr after first run and it had a weird, non-required
policy around what constituted acceptance of the policy.
The notification is now shown shortly after first startup.
The logic around "notification accepted" has been greatly simplified by
rolling it into "notification shown." Where we once were checking
whether the notification has been "accepted," we now check whether it
has been displayed. The overly complicated logic around the implicit
acceptance of the policy has also been removed.
The end result is the code for managing the state of the notification is
greatly simplified.
If recording FHR data during uploading raised an exception, it could
potentially abort the upload. This would appear to Mozilla as clients
that suddenly stopped using Firefox.
This patch adds explicit exception trapping around event record to
ensure this doesn't happen.
--HG--
extra : rebase_source : 7cd207b08a4f62be55093c71cb56e28832fd39d8
extra : amend_source : 9144ecea16a013370fffa5c2e833af4ec528ef5b
This patch makes EXTRA_{PP_,}JS_MODULES similar in functionality to
TESTING_JS_MODULES: we indicate the path relative to
$(FINAL_TARGET)/modules with an appropriate hierarchy of paths.
The v20140527.01 update hotfix deposited a JSON file in the profile
directory containing state. This file was purposefully not deleted
during hotfix uninstall so its contents could be later reported in
FHR.
This patch adds that reporting to FHR.
Currently, we only report a subset of the available fields. The
remaining "public" fields could be added easily enough. For now, it is
important that we capture the important ones.
--HG--
extra : rebase_source : 925d6ea04118296108327dc843323b150b87b208
The upcoming build system patches don't support hypthens in path names.
Changing this for that reason is kind of silly, but it's the easiest
way. Besides, nothing else uses hyphens in directory names.
--HG--
extra : rebase_source : 42dda2b1f16a3c0bfe17397a70092362e400530f
This introduces a new crash event type for submissions and handles
them in the Crash Manager. These crash submissions will also be counted
in FHR.
--HG--
extra : rebase_source : c37fc86cecc86aea0afdd8cfa7b31295aad3d6f8
The -*- file variable lines -*- establish per-file settings that Emacs will
pick up. This patch makes the following changes to those lines (and touches
nothing else):
- Never set the buffer's mode.
Years ago, Emacs did not have a good JavaScript mode, so it made sense
to use Java or C++ mode in .js files. However, Emacs has had js-mode for
years now; it's perfectly serviceable, and is available and enabled by
default in all major Emacs packagings.
Selecting a mode in the -*- file variable line -*- is almost always the
wrong thing to do anyway. It overrides Emacs's default choice, which is
(now) reasonable; and even worse, it overrides settings the user might
have made in their '.emacs' file for that file extension. It's only
useful when there's something specific about that particular file that
makes a particular mode appropriate.
- Correctly propagate settings that establish the correct indentation
level for this file: c-basic-offset and js2-basic-offset should be
js-indent-level. Whatever value they're given should be preserved;
different parts of our tree use different indentation styles.
- We don't use tabs in Mozilla JS code. Always set indent-tabs-mode: nil.
Remove tab-width: settings, at least in files that don't contain tab
characters.
- Remove js2-mode settings that belong in the user's .emacs file, like
js2-skip-preprocessor-directives.
