80b3b0c839b0eb68fb989bec372adf78a148bf82: No bug, Automated HSTS preload list update from host bld-linux64-spot-034 - a=hsts-update
ffxbld - Tue, 21 Nov 2017 11:48:49 -0800 - rev 444585
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
No bug, Automated HSTS preload list update from host bld-linux64-spot-034 - a=hsts-update
b270965df801fbb0a9a77aa42760f7a22bfd482c: No bug, Automated HPKP preload list update from host bld-linux64-spot-030 - a=hpkp-update
ffxbld - Tue, 21 Nov 2017 11:14:55 -0800 - rev 444584
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
No bug, Automated HPKP preload list update from host bld-linux64-spot-030 - a=hpkp-update
472098f21676535d02474ae40c36cb1e96dd5c8d: No bug, Automated HSTS preload list update from host bld-linux64-spot-030 - a=hsts-update
ffxbld - Tue, 21 Nov 2017 11:14:52 -0800 - rev 444583
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
No bug, Automated HSTS preload list update from host bld-linux64-spot-030 - a=hsts-update
72ee4800d4156931c89b58bd807af4a3083702bb: Merge inbound to mozilla-central r=merge a=merge
Tiberius Oros <toros@mozilla.com> - Tue, 21 Nov 2017 11:55:23 +0200 - rev 444582
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Merge inbound to mozilla-central r=merge a=merge
effb563bb7e5692cf7d911725b5870f1b7f6c41c: Bug 1418467 - Privatize PrefHashEntry::m{Default,User}Value. r=glandium
Nicholas Nethercote <nnethercote@mozilla.com> - Sat, 18 Nov 2017 07:40:01 +1100 - rev 444581
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418467 - Privatize PrefHashEntry::m{Default,User}Value. r=glandium MozReview-Commit-ID: 9Fzaf4ifF0N
85eea5172cd8c6efe4ee8c060d1bd58b377b4caf: Bug 1418467 - Add PrefHashEntry::SetValue(). r=glandium
Nicholas Nethercote <nnethercote@mozilla.com> - Sat, 18 Nov 2017 07:38:24 +1100 - rev 444580
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418467 - Add PrefHashEntry::SetValue(). r=glandium It's a horrible method, but the horribleness was pre-existing. I hope to make it nicer in a follow-up bug. MozReview-Commit-ID: 3tMTEeBNVax
8fe0a8c0c579627cb4fb30da60b06f715c0d0461: Bug 1418467 - Partly move value getting into PrefHashEntry. r=glandium
Nicholas Nethercote <nnethercote@mozilla.com> - Sat, 18 Nov 2017 07:28:29 +1100 - rev 444579
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418467 - Partly move value getting into PrefHashEntry. r=glandium MozReview-Commit-ID: 4ouh3XFxPZr
3526eb2a959c4c95dc73ae365671d3171748d683: Bug 1418467 - Add PrefHashEntry::UserValueToStringForSaving(). r=glandium
Nicholas Nethercote <nnethercote@mozilla.com> - Sat, 18 Nov 2017 07:27:06 +1100 - rev 444578
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418467 - Add PrefHashEntry::UserValueToStringForSaving(). r=glandium This moves part of pref_savePrefs() into PrefHashEntry. This requires moving StrEscape() higher up to avoid a forward declaration. Note that clang-format insists on indenting an unrelated comment, I don't know why. MozReview-Commit-ID: 7gww3r7t9y4
b2a88540faa79dc1bb551f9bee51538eec8b9f51: Bug 1418467 - Move pref_ValueChanged() into PrefValue. r=glandium
Nicholas Nethercote <nnethercote@mozilla.com> - Sat, 18 Nov 2017 07:19:42 +1100 - rev 444577
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418467 - Move pref_ValueChanged() into PrefValue. r=glandium And invert its sense, renaming as Equals(), because that is easier to think about. The patch also reorders some conditions so that HasDefaultValue()/HasUserValue() is tested before Equals(). This isn't strictly necessary, but it reads better. MozReview-Commit-ID: JeGrevDwqKz
ced8af085927bba7a6f4d07e4b0a1532ed61a6ce: Bug 1410276 - Add a canary field to nsStringBuffer r=bz
Paul Bone <pbone@mozilla.com> - Thu, 09 Nov 2017 15:17:35 +1100 - rev 444576
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1410276 - Add a canary field to nsStringBuffer r=bz This version of the patch hopefully causes fewer performance regressions. It might be good to apply this and catch some more assertions.
95338f62791dedfead40c28fc196e66e65a15878: Bug 1417267 - Output structured logs for jstests and jit-tests in automation, r=jonco
Steve Fink <sfink@mozilla.com> - Tue, 14 Nov 2017 15:36:47 -0800 - rev 444575
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1417267 - Output structured logs for jstests and jit-tests in automation, r=jonco
29cc33a514b6dfe6d4ae20d9de61b90b12883ee9: Bug 1366083 - diagnostic patch for ObjectValue(nullptr), r=jonco
Steve Fink <sfink@mozilla.com> - Tue, 14 Nov 2017 12:14:17 -0800 - rev 444574
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1366083 - diagnostic patch for ObjectValue(nullptr), r=jonco
c84df10506004cd3055b263e2de32401a8f8263a: Bug 1418048 - Part 3: Accept callbacks passed to async-returning SendXXX methods as rvalue references on a CLOSED TREE, a=bustage
Nika Layzell <nika@thelayzells.com> - Mon, 20 Nov 2017 18:53:02 -0500 - rev 444573
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418048 - Part 3: Accept callbacks passed to async-returning SendXXX methods as rvalue references on a CLOSED TREE, a=bustage MozReview-Commit-ID: 7M1uuWr0fMM
83af876d4fa01fe675e7249c071659db55750e81: Bug 1410528 - Suppress minidumps for crash tests, r=jonco
Steve Fink <sfink@mozilla.com> - Fri, 03 Nov 2017 16:04:35 -0700 - rev 444572
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1410528 - Suppress minidumps for crash tests, r=jonco
55903b8dbfbd61522213eca321223ef4dbd2136f: Bug 1410528 - When running via autospider.sh, make the shell generate a minidump on crashes, r=jonco,ted
Steve Fink <sfink@mozilla.com> - Sun, 05 Nov 2017 09:54:46 -0800 - rev 444571
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1410528 - When running via autospider.sh, make the shell generate a minidump on crashes, r=jonco,ted
2bb133c24dca29fc04a9862f2f173cae0f2515cf: Bug 1410528 - Add a --dll flag to the JS shell for loading shared libs, r=ted,jonco
Steve Fink <sfink@mozilla.com> - Mon, 13 Nov 2017 10:00:16 -0800 - rev 444570
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1410528 - Add a --dll flag to the JS shell for loading shared libs, r=ted,jonco
29e4123595f521b540cf8349837308e176211833: Bug 1418048 - Part 2: Pass callbacks by rvalue reference when possible, a=bustage
Nika Layzell <nika@thelayzells.com> - Mon, 20 Nov 2017 18:12:21 -0500 - rev 444569
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418048 - Part 2: Pass callbacks by rvalue reference when possible, a=bustage MozReview-Commit-ID: 4KsbRJ9AEdB
82dbe444d5e3cc4f1a184e5bcf38e0d9b39b9872: Bug 1419090 - Remove StableStateEventTarget, r=smaug
Nika Layzell <nika@thelayzells.com> - Mon, 20 Nov 2017 16:42:18 -0500 - rev 444568
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1419090 - Remove StableStateEventTarget, r=smaug MozReview-Commit-ID: 7dYAkp9bEGQ
ea19dfc66ee0a3711d4c6f9050a2ae69a545eada: Bug 1416728 - Process the CreateWindow reply message in order with other PContent IPC messages, r=bz
Nika Layzell <nika@thelayzells.com> - Thu, 16 Nov 2017 15:59:52 -0500 - rev 444567
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1416728 - Process the CreateWindow reply message in order with other PContent IPC messages, r=bz Previously we used the MozPromise interface for calling an async-message over IPC with a reply. Unfortunately, MozPromise processes the reply asynchronously, potentially allowing other IPC messages to be processed before the `->Then` callback is processed. In the original CreateWindow patch I tried to work around this by setting the target of the `->Then` callback to be StableStateEventTarget. This worked, however as it isn't safe to run scripts etc. in the stable state, we instead tried to exit the nested event loop immediately after the runnable ran, and then performed processing of the reply. Unfortunately, this bug exposed a problem with that design. If we have multiple nested event loops then we cannot guarantee that we'll exit the nested event loop immediately after recieving the `->Then` callback, which meant that we could still process other IPC messages before we processed the CreateWindow reply. The fix to this was to add a new API to allow passing callbacks directly into IPC send methods, ensure that those callbacks are called in IPC order, and fully process the CreateWindow reply in the callback, rather than waiting for the nested event loop to exit. MozReview-Commit-ID: D6zaMJRxhXd
e37007fcbd347557bb6f7935037536a46c91fcbd: Bug 1418048 - Add a callback-based Send API to async returning IPDL methods, r=billm
Nika Layzell <nika@thelayzells.com> - Thu, 16 Nov 2017 15:12:06 -0500 - rev 444566
Push 8527 by Callek@gmail.com at Thu, 11 Jan 2018 21:05:50 +0000
Bug 1418048 - Add a callback-based Send API to async returning IPDL methods, r=billm Currently if you write an async IPDL method which has a return value, we expose a SendXXX method which returns a MozPromise. This MozPromise can then be ->Then-ed to run code when it is resolved or rejected. Unfortunately, using this API loses ordering guarantees which IPDL provides. MozPromise::Then takes an event target, which the resolve runnable is dispatched to. This means that the resolve callback's code doesn't have any ordering guarantees relative to the processing of other IPC messages coming over the same protocol. This adds a new overload to SendXXX with two additional arguments, a lambda callback which is called if the call succeeds, and a lambda callback which is called if the call fails. These will be called in order with other IPC messages sent over the same protocol. MozReview-Commit-ID: FZHJJaSDoZy
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip