I didn't include nalexander's MOZ_INSTALL_TRACKING suggestion because my make
skills are too shaky to make this worthwhile. Specifying a keyfile when
MOZ_INSTALL_TRACKING is disabled isn't harmful afaik (though it's a little
spammy).
Also, added code comment duplicated for emphasis:
# (bug 1277553) In Aurora -> Beta simulation builds, no update channel is
# specified, causing an assertion to throw that MOZ_INSTALL_TRACKING is
# specified but the keyfile is not. In this case, we add a default keyfile.
# This has the disadvantage that if our beta/release checks above ever
# fail, we'll come to this default case and the compile-time check to
# specify a valid keyfile will be broken. I don't have any better
# alternatives.
MozReview-Commit-ID: 7tmemvpDaW8
--HG--
extra : rebase_source : 96930d595ebc22c06dadea1d28782ec6a2c023c2
Additionally, we add this file to the tree so it can be used by bug 1277553.
The following commit will add the docs explaining how to use the file I
added.
The added file contents are slurped directly into
AdjustConstants.MOZ_INSTALL_TRACKING_ADJUST_SDK_APP_TOKEN. We get the sandbox
token from the previously working value in [1].
An alternative solution would be to remove the assertion that
`--with-adjust-sdk-keyfile` is specified and provide a default value if the key
is not specified. However, after investigating bug 1277553, I dislike this
approach because we lose the compile-time checks that a key file is specified,
which is dangerous for release/beta builds where the key file may not be valid,
we push a release, and we don't get the data we expect.
Ideally, we specify `--with-adjust-sdk-keyfile` for non-MOZILLA_OFFICIAL
builds, but I don't know how to do that.
[1]: https://hg.mozilla.org/mozilla-central/rev/ac75f8f4c01d#l1.26
MozReview-Commit-ID: HPNgiwfzU5p
--HG--
extra : rebase_source : 6ee6cf869624b2274338d76b63072d13cc3c8432
Existing keyboard shortcuts have been reimplemented using the new shortcut-key
api.
A keypress handler was removed on the breadcrumbs buttons, it had no use
since a focused button is always selected.
MozReview-Commit-ID: JTSRxwQGSlh
--HG--
extra : rebase_source : 4466162a2cf2bd77cb50ee77ea5843c973ceb5b2
aOutputLeft is null checked and then dereferenced twice more in this function,
and all callers pass a non-null pointer. So just remove the null check.
--HG--
extra : rebase_source : 8190a51fde8434ac346a4e23db5ed4703762778c
MozReview-Commit-ID: KFlaQoeGPRc
* I guess this has to be uplifted to aurora and included in the aurora->beta
merge
--HG--
extra : source : a285884cd669c248d9f2f40b9aaad73a4ac592a4
String.prototype.contains was removed from Firefox 48 completely after
it was renamed to String.prototype.includes. The test includes a
call to .contains() which is triggered whenever random JavaScript
error occurs during the test (hence the intermittency).
MozReview-Commit-ID: 7nbRm94JM7O
--HG--
extra : rebase_source : e969bc1ad46120509deec31066ea63ebbb7de9c9
We had two potentials rounding issue occurring. The one causing the problem is that adding an int64 with a float is a float, and would be limited to 24bits mantissa.
The other, could be that rounding would occur if the segment duration was over 16s long, as that too would exceed the representation range as we using microseconds representation internally.
MozReview-Commit-ID: FyBTGvfg25I
--HG--
extra : transplant_source : %D0%14u%E3%1E%C6%D2%FC4%A4%2B%C0%20k%05%E8%90qz%2B
We add URL metadata based on the base URL, we should retrieve it this way too.
MozReview-Commit-ID: ICP54V5vRgv
--HG--
extra : rebase_source : 967cf4843572b85b425735486700cd6f6c24887c
extra : source : e994f70de0490e77a2309793852434f2f1641ad7
We already pass the URL inside the JSON object.
MozReview-Commit-ID: J4RjxLAzdI
--HG--
extra : rebase_source : 49932580b5a34032e072b4b4e905ebe6daeb964a
extra : source : f685593ac3cc4ea3b8d6545e42eb7d225095161a
