219c4dcda73b1c0bf207d46587c9241615a38a98: bug 1444532 - fix a leak in SHA256 in nsHttpConnectionInfo.cpp r?mcmanus draft
David Keeler <dkeeler@mozilla.com> - Fri, 09 Mar 2018 14:16:57 -0800 - rev 765618
Push 102119 by bmo:dkeeler@mozilla.com at Fri, 09 Mar 2018 22:20:36 +0000
bug 1444532 - fix a leak in SHA256 in nsHttpConnectionInfo.cpp r?mcmanus The original code (from bug 1200802) declared an XPCOM object as a static bare pointer, which for future reference is probably never the right thing to do. It might have worked if it was cleared before shutdown but it never was. MozReview-Commit-ID: EMe7wgzm6zv
d47d5f57ac2bc351b9fa34ab25be04c526aaa3af: Bug 1440346 - Replace abbreviated strings in the sync bookmark mirror's tree log with full names r?kitcambridge draft
Thom Chiovoloni <tchiovoloni@mozilla.com> - Fri, 09 Mar 2018 14:19:15 -0800 - rev 765617
Push 102118 by bmo:tchiovoloni@mozilla.com at Fri, 09 Mar 2018 22:20:30 +0000
Bug 1440346 - Replace abbreviated strings in the sync bookmark mirror's tree log with full names r?kitcambridge MozReview-Commit-ID: 2TqZPWVHIUm
429cbb0fe08de0ddae9c6aa3f90f1cdb5734fbcb: Bug 1444534 - Part 2: Fold m/a/base/locales into m/a/base. r?ted.mielczarek draft
Nick Alexander <nalexander@mozilla.com> - Thu, 08 Mar 2018 14:19:13 -0800 - rev 765616
Push 102117 by nalexander@mozilla.com at Fri, 09 Mar 2018 22:19:35 +0000
Bug 1444534 - Part 2: Fold m/a/base/locales into m/a/base. r?ted.mielczarek At last, another part of our long nightmare bites the dust. We had a complicated system where m/a/base used a FORCE $(MAKE) to produce l10n-dependent pieces in m/a/base/locales, foiling sensible recursive Make dependencies and causing much pain and suffering. Now that things are in moz.build, we can fold this into m/a/base, simplifying the dependencies. This gets us one step closer to expressing the APK generation that consumes the dependencies in moz.build. MozReview-Commit-ID: FzLtgR8AMue
63f9bb1abb5de151df4e1360fadfd43c8838ba4f: Bug 1444534 - Part 1: Allow "locales/en-US" relative paths in localized inputs. r?ted.mielczarek draft
Nick Alexander <nalexander@mozilla.com> - Thu, 08 Mar 2018 14:12:44 -0800 - rev 765615
Push 102117 by nalexander@mozilla.com at Fri, 09 Mar 2018 22:19:35 +0000
Bug 1444534 - Part 1: Allow "locales/en-US" relative paths in localized inputs. r?ted.mielczarek This cleans up a few things, including simplifying the look of backend.mk by keeping the relsrcdir in MERGE_RELATIVE_FILE similar to the source path in the tree. Before, the locales/ floated around, which is hard to understand but doesn't matter, since it's stripped by MERGE_RELATIVE_FILE. This also tests both relative and topsrcdir-absolute paths. MozReview-Commit-ID: 1v3y9xGiNfL
a9a33101d1b99446ae17cbc5d6f3de09c89ebcd2: Bug 1444534 - Pre: Don't generate JNI wrappers for multi-locale builds or single-locale repacks. r?ted.mielczarek draft
Nick Alexander <nalexander@mozilla.com> - Fri, 09 Mar 2018 10:39:46 -0800 - rev 765614
Push 102117 by nalexander@mozilla.com at Fri, 09 Mar 2018 22:19:35 +0000
Bug 1444534 - Pre: Don't generate JNI wrappers for multi-locale builds or single-locale repacks. r?ted.mielczarek As the comment says, these aren't useful during the final stage of assembling a multi-locale build (when AB_CD=multi is set -- they're definitely useful for the initial build, when AB_CD is unset and implicitly en-US). And single-locale repacks don't do any compilation, so they're definitely not useful there. By guarding, we avoid having to be specific about what we're building in the build invocations that will be moved out of |mach package| and into different parts of the multi-locale build and single-locale repack processes. Subsequent tickets will migrate this whole JNI wrapper generation mechanism to GENERATED_FILES anyway, moving the JNI wrapper generation closer to the build steps that need the wrappers and avoiding the problem entirely: those build steps won't be invoked at all for multi-locale builds or for single-locale repacks. MozReview-Commit-ID: Lt2d6uFm5Dq
f35957cd1b37877438ed673e0b0b1522d15a8726: Bug 1444534 - Pre: Don't hide l10n Make invocations. r?ted.mielczarek draft
Nick Alexander <nalexander@mozilla.com> - Wed, 07 Mar 2018 12:25:26 -0800 - rev 765613
Push 102117 by nalexander@mozilla.com at Fri, 09 Mar 2018 22:19:35 +0000
Bug 1444534 - Pre: Don't hide l10n Make invocations. r?ted.mielczarek There's just no need for this: it makes interpreting build logs that little bit harder. MozReview-Commit-ID: 7gq73I8I3Bt
5aea0279344d4267747dd82785cbd6f451639121: Bug 1440195 Actually integrate the context mix-in into the hash function calculation draft
Tom Ritter <tom@mozilla.com> - Thu, 08 Mar 2018 14:43:00 -0600 - rev 765612
Push 102116 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:14:28 +0000
Bug 1440195 Actually integrate the context mix-in into the hash function calculation MozReview-Commit-ID: 4k7w683UJOY
778ad8d9aa4f461d453215741728f6e6a636b09f: Bug 1440195 Address CSS Animations draft
Tom Ritter <tom@mozilla.com> - Mon, 05 Mar 2018 15:58:46 -0600 - rev 765611
Push 102116 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:14:28 +0000
Bug 1440195 Address CSS Animations For now, we are going to make _all_ CSS Animations related timer fuzzing only applicable in Resist Fingerprinting Mode (addressing the last couple that had not already been configured that way.) We hardcode their content mix-ins as zero, but leave comments indicating how they should behave. MozReview-Commit-ID: KhmV7wO8Pt5
f2cd280028bef1c94734da705c8e74e64a4a69e4: Bug 1440195 Add a random context seed to the Performance APIs draft
Tom Ritter <tom@mozilla.com> - Mon, 05 Mar 2018 16:29:40 -0600 - rev 765610
Push 102116 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:14:28 +0000
Bug 1440195 Add a random context seed to the Performance APIs We attach it to WorkerPrivate and DOMNavigationTiming so it will be re-used when it should. WorkerPrivate is used in the Performance APIs, Performance Storage Worker, and Event. DOMNavigationTiming is used only in the Performance APIs, but the crucial part is that when the individual DOMNavigationTiming object is re-used, so will the context seed. This in particular came up with the nav2_test_document_open.html Web Platform Test which illustrated the fact that even if you .open() a new document, the performance navigation data is not supposed to change. MozReview-Commit-ID: GIv6biEo2jY
495dc42e749094023cce773f7b26d20beb22d651: Bug 1440195 Add a random context seed for AudioContext and MediaStream draft
Tom Ritter <tom@mozilla.com> - Thu, 01 Mar 2018 11:00:12 -0600 - rev 765609
Push 102116 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:14:28 +0000
Bug 1440195 Add a random context seed for AudioContext and MediaStream MozReview-Commit-ID: sHpVCgd8Fs
2be6541172a6320f314a7d14f9be583dd74b3864: Bug 1440195 For timestamps that are absolute, specify a null context pointer draft
Tom Ritter <tom@mozilla.com> - Wed, 28 Feb 2018 15:37:26 -0600 - rev 765608
Push 102116 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:14:28 +0000
Bug 1440195 For timestamps that are absolute, specify a null context pointer Note that by not using the same context pointer for all timestamps within a single 'communication group' (that is, all things that can communication to each other in JavaScript), it's possible to observe time going backwards. Imagine comparing performance.timeOrigin + performance.now() < new File([], "").lastModified In theory this should always be true. However, if performance.now() was jittered up (using one context pointer, because it is a relative timestamp) and File was jittered down (using a null context pointer, because it is an absolute timestamp) then this may evaluate to False. I think this is okay. MozReview-Commit-ID: BfgbmGS8XdD
13ec5da2ccb26c54629c465544566d8d9c829d68: Bug 1440195 Add a per-context mix-in value for our Timer Precision Reduction Functions draft
Tom Ritter <tom@mozilla.com> - Mon, 05 Mar 2018 16:25:29 -0600 - rev 765607
Push 102116 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:14:28 +0000
Bug 1440195 Add a per-context mix-in value for our Timer Precision Reduction Functions We need to include a seed for each context (origin, iframe, worker, etc) we reduce the time precision of. This prevents a replay attack of the random midpoint sequence. MozReview-Commit-ID: EFoHev1SrTM
4402e1ef60fcb0a5a9182b610882f2f8de2a67d5: Bug 1443943 Do not clamp/jitter event timestamps if it's a system principal draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 10:00:23 -0600 - rev 765606
Push 102115 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:13:28 +0000
Bug 1443943 Do not clamp/jitter event timestamps if it's a system principal This patch has an annoying gap in it. I follow the pointer chain up like so: mPresContext->Document()->NodePrincipal() However, sometimes either mPresContext or mPresContext->Document() is null. I don't know why. MozReview-Commit-ID: KvVJpvu4elN
161221f5226ecef7f069d3ae514c814d0e63d2e7: Bug 1443943 Do not clamp/jitter in the JS Engine if it's system context draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 09:49:28 -0600 - rev 765605
Push 102115 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:13:28 +0000
Bug 1443943 Do not clamp/jitter in the JS Engine if it's system context MozReview-Commit-ID: LqL7xaYoHCT
baad642aa2db26840f77e578311b2a558831a630: Bug 1443943 Port the performance APIs only to only clamping/jittering on non-System Principal draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 09:29:33 -0600 - rev 765604
Push 102115 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:13:28 +0000
Bug 1443943 Port the performance APIs only to only clamping/jittering on non-System Principal MozReview-Commit-ID: FKYLI5Yc1kX
63763afdd41fd06ad058592315cbf7360caa8c63: Bug 1443943 Move LRUCache Initialization to startup rather than lazily draft
Tom Ritter <tom@mozilla.com> - Fri, 09 Mar 2018 11:52:33 -0600 - rev 765603
Push 102115 by bmo:tom@mozilla.com at Fri, 09 Mar 2018 22:13:28 +0000
Bug 1443943 Move LRUCache Initialization to startup rather than lazily Before, we would initialize LRUCache on the first instance of calling the Timer Precision Reduction functions. We would both allocate and initialize it, and call ClearOnShutdown. ClearOnShutdown can only be called on the Main Thread, but it just so happened that we always did that, so there was no problem. Now that we are not calling precision reduction for system callers, we were initializing on a non-main-thread and we need to avoid that. In the future, we could reduce memory use IF we are not using the timer precision reduction functions by figuring out how to initialize this lazily but still on the main thread. For now, because we are using the timer precision reduction functions, doing so would not save us any memory. MozReview-Commit-ID: GqkfouVSeG8
844f09651ee1477c6dab0328bd80745043d76953: Bug 1444252 - Check if program is linked in GetActiveUniforms. - r=kvark draft
Jeff Gilbert <jgilbert@mozilla.com> - Mon, 26 Feb 2018 12:03:55 -0800 - rev 765602
Push 102114 by bmo:jgilbert@mozilla.com at Fri, 09 Mar 2018 22:13:16 +0000
Bug 1444252 - Check if program is linked in GetActiveUniforms. - r=kvark MozReview-Commit-ID: EBbgWlzdC3A
09ecb6d589490df1abb869bf025ce094ba87bcac: Backed out 2 changesets (bug 1435899) for failing android at modules/libpref/test/unit/test_defaultValues.js pn a CLOSED TREE
Andreea Pavel <apavel@mozilla.com> - Fri, 09 Mar 2018 23:14:32 +0200 - rev 765601
Push 102114 by bmo:jgilbert@mozilla.com at Fri, 09 Mar 2018 22:13:16 +0000
Backed out 2 changesets (bug 1435899) for failing android at modules/libpref/test/unit/test_defaultValues.js pn a CLOSED TREE Backed out changeset 925adb267211 (bug 1435899) Backed out changeset f22f1ab67c5a (bug 1435899)
ac6bc78dadb9d7fb66d8c8b67d65948e1ed64b9a: Bug 1442040. Remove unnecessary classinfo for the nsIDOMXUL* interfaces. r=peterv
Boris Zbarsky <bzbarsky@mit.edu> - Fri, 09 Mar 2018 16:04:11 -0500 - rev 765600
Push 102114 by bmo:jgilbert@mozilla.com at Fri, 09 Mar 2018 22:13:16 +0000
Bug 1442040. Remove unnecessary classinfo for the nsIDOMXUL* interfaces. r=peterv MozReview-Commit-ID: C4brIXnpiV0
5b750710adaa157b6fb593a5744bae758379f616: Bug 1444286. Common up the Get*ObjectHandle methods in bindings. r=peterv
Boris Zbarsky <bzbarsky@mit.edu> - Fri, 09 Mar 2018 16:04:11 -0500 - rev 765599
Push 102114 by bmo:jgilbert@mozilla.com at Fri, 09 Mar 2018 22:13:16 +0000
Bug 1444286. Common up the Get*ObjectHandle methods in bindings. r=peterv This reduces codesize, at the cost of a bit more includes in the binding headers. MozReview-Commit-ID: 40dLELF36Oh
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip