18af2ea42a1e01e98273101fd7ed8dc0291e7a2d: Bug 1400466 - Cache the information loaded from src_comp.xdb into a structured clone buffer, r=jonco
Steve Fink <sfink@mozilla.com> - Fri, 08 Sep 2017 14:58:26 -0700 - rev 667088
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400466 - Cache the information loaded from src_comp.xdb into a structured clone buffer, r=jonco Note that this requires some enhancements to the JS engine to support reading and writing structured clone data from/to files.
383a2f567cebe59b0212e414b9a27d46123040bf: Bug 1400466 - Implement minimum necessary to allow saving and loading structured clone data, r=jonco
Steve Fink <sfink@mozilla.com> - Fri, 08 Sep 2017 13:56:04 -0700 - rev 667087
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400466 - Implement minimum necessary to allow saving and loading structured clone data, r=jonco
8d3d707fe0485a8900c4794a0c55018ad722c6de: Bug 1401019 - Cancel the current U2F API request before starting a new one r=jcj
Tim Taubert <ttaubert@mozilla.com> - Tue, 19 Sep 2017 16:55:38 +0200 - rev 667086
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1401019 - Cancel the current U2F API request before starting a new one r=jcj I wasn't sure what the right behavior for the U2F API is when `.sign()` or `.register()` is called but there's an ongoing request that wasn't fulfilled yet. I think it makes sense to deny the request (as we currently do) when a request of the same type is currently active. When however sign() -> register() or vice-versa is called then we should cancel the previous request and start the new one. From what I understand from reading the spec we definitely should call the callback before starting the new request. Bug #: 1401019 Differential Revision: https://phabricator.services.mozilla.com/D70
c8277ab2befdd4c5027741f12bc94a0870925542: Bug 1400559 - [u2f-hid-rs] rustfmt followup r=me
Tim Taubert <ttaubert@mozilla.com> - Tue, 19 Sep 2017 16:45:07 +0200 - rev 667085
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400559 - [u2f-hid-rs] rustfmt followup r=me
425b1969478e417db21ac1e35cdf481c1cd0be32: Bug 1401171 - Make nsIMultiplexInputStream not inherit from nsIInputStream. r=bkelly
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 19 Sep 2017 16:26:21 +0200 - rev 667084
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1401171 - Make nsIMultiplexInputStream not inherit from nsIInputStream. r=bkelly This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit from nsIInputStream: once via nsIMultipartInputStream and once via nsIAsyncInputStream. This causes problems once we end up with more multiplex streams that are async streams, because then some assingments to nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun by getting rid of the multiple inheritance.
bb274a08887161806afe21ec1916d48cda1199d7: Backed out changeset 3c9e25405f59 (bug 1401204) an request from baku for landing with wrong bug number. r=backout
Sebastian Hengst <archaeopteryx@coole-files.de> - Tue, 19 Sep 2017 16:25:20 +0200 - rev 667083
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Backed out changeset 3c9e25405f59 (bug 1401204) an request from baku for landing with wrong bug number. r=backout
3c9e25405f596871f714a8c3b10e6e9de9188554: Bug 1401204 - Make nsIMultiplexInputStream not inherit from nsIInputStream. r=bkelly
Boris Zbarsky <bzbarsky@mit.edu> - Sun, 11 Jun 2017 00:07:23 -0400 - rev 667082
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1401204 - Make nsIMultiplexInputStream not inherit from nsIInputStream. r=bkelly This is a preexisting issue that makes nsMultiplexInputStream multiple-inherit from nsIInputStream: once via nsIMultipartInputStream and once via nsIAsyncInputStream. This causes problems once we end up with more multiplex streams that are async streams, because then some assingments to nsCOMPtr<nsIInputStream> start asserting. This patch just removes the footgun by getting rid of the multiple inheritance.
5af3e3b70198dac5501d159d8d808ed738de9c06: Bug 1400898 part 4. Get rid of nsIDOMChromeWindow methods that are unused from C++, and mark the rest [noscript]. r=farre
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 19 Sep 2017 10:13:23 -0400 - rev 667081
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400898 part 4. Get rid of nsIDOMChromeWindow methods that are unused from C++, and mark the rest [noscript]. r=farre MozReview-Commit-ID: GtYmfg6XiaQ
081034bdc4d4f0ac15877565a805b737c8d91b5d: Bug 1400898 part 3. Make nsIDOMChromeWindow.browserDOMWindow readonly. r=farre
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 19 Sep 2017 10:13:23 -0400 - rev 667080
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400898 part 3. Make nsIDOMChromeWindow.browserDOMWindow readonly. r=farre C++ code only reads this attribute. Code that sets it comes via WebIDL bindings. MozReview-Commit-ID: 2itFAxUVTBo
aa4d0a9412c0bc4fe131115aa002ad2b7f2c7927: Bug 1400898 part 2. Get rid of the interface constants on nsIDOMChromeWindow. r=farre
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 19 Sep 2017 10:13:22 -0400 - rev 667079
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400898 part 2. Get rid of the interface constants on nsIDOMChromeWindow. r=farre MozReview-Commit-ID: 4FuJSgha5y3
a4ef5b6299e59859a0dec1996db87a717518db43: Bug 1400898 part 1. Remove the one script use of nsIDOMChromeWindow. r=farre
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 19 Sep 2017 10:13:22 -0400 - rev 667078
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400898 part 1. Remove the one script use of nsIDOMChromeWindow. r=farre MozReview-Commit-ID: I31eceiJP55
b2e90060a137b10b38ad7a394dab802841094861: Backed out changeset 5cd2ba3bc6c4 (bug 1336389) for failing new talos test cpstartup. r=backout
Sebastian Hengst <archaeopteryx@coole-files.de> - Tue, 19 Sep 2017 16:12:41 +0200 - rev 667077
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Backed out changeset 5cd2ba3bc6c4 (bug 1336389) for failing new talos test cpstartup. r=backout
9e0e34d815597d581777f822f591301e174c06ff: Bug 1400559 - Move runloop code into its own crate r=jcj
Tim Taubert <ttaubert@mozilla.com> - Tue, 19 Sep 2017 15:46:55 +0200 - rev 667076
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400559 - Move runloop code into its own crate r=jcj The runloop seems like a good candidate for moving into its own crate. I wasn't sure whether we want it under the Mozilla org on GitHub, so I pushed it to ttaubert/rust-runloop for a start. Moving the repository to mozilla/* is easy, and we'd just need to bump the crate version with the updated repository, if you think we should. Bug #: 1400559 Differential Revision: https://phabricator.services.mozilla.com/D62
9cabdd061402b2dda590d2a102a4b2d32b67f346: Bug 1401050 - Add vanishingly to the en-US dictionary. r=ehsan
Ekanan Ketunuti <ananuti@gmail.com> - Tue, 19 Sep 2017 07:01:39 +0700 - rev 667075
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1401050 - Add vanishingly to the en-US dictionary. r=ehsan
9016e255c36ced248b09b1745a293dee6981db81: Bug 1359289 - Add a "Learn More" link to Safe Browsing checkbox in about:preferences. r=jhofmann
Vedant Chakravadhanula <vedantc98@gmail.com> - Tue, 19 Sep 2017 12:33:28 +0530 - rev 667074
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1359289 - Add a "Learn More" link to Safe Browsing checkbox in about:preferences. r=jhofmann
762071fc48dda899efa95501e531cc5a39e09aff: Bug 1400141 - Use redo params from nightly with a jitter r=bhearsum
Nick Thomas <nthomas@mozilla.com> - Tue, 19 Sep 2017 15:21:22 +0200 - rev 667073
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1400141 - Use redo params from nightly with a jitter r=bhearsum MozReview-Commit-ID: BjU6A9pOpKE
9f8c6be7d2f4216d3f87e091f8cfe238bab8ca1a: Bug 1397407 - Apply deferred image key deletions to the next transaction. r=Gankro
Nicolas Silva <nsilva@mozilla.com> - Fri, 15 Sep 2017 13:24:31 +0200 - rev 667072
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1397407 - Apply deferred image key deletions to the next transaction. r=Gankro
3ff9cd026e70eacb71f9a182f633834eb837b24d: Bug 1380649 - Part 2. Ensure SourceSurfaceVolatileData does not forget its purged state. r=jrmuizel
Andrew Osmond <aosmond@mozilla.com> - Tue, 19 Sep 2017 08:19:48 -0400 - rev 667071
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1380649 - Part 2. Ensure SourceSurfaceVolatileData does not forget its purged state. r=jrmuizel Currently if SourceSurfaceVolatileData::Map fails due to being purged, we expect that the surface will be discarded by the caller. This has not consistently been the case, and as such, we should ensure we do not forget if a buffer was previously purged when we reacquire it. Since we do not at this time support repopulating an already allocated buffer with new data, we cannot reset this state once it has been set.
a23a810d95855a42f009ccd72604935db0680bd3: Bug 1380649 - Part 1. Ensure SurfaceCache::CollectSizeOfSurfaces removes purged volatile buffer-backed surfaces. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 19 Sep 2017 08:19:48 -0400 - rev 667070
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1380649 - Part 1. Ensure SurfaceCache::CollectSizeOfSurfaces removes purged volatile buffer-backed surfaces. r=tnikkel When we lookup a surface in the cache, we are careful to remove any surfaces which were backed by volatile memory and got purged before we could reacquire the buffer. We were not so careful in doing that when generating memory reports. ISurfaceProvider::AddSizeOfExcludingThis will cause us to acquire the buffer, and if it was purged, forget about its purged status. Later when we performed a lookup, we would forget the purged status, and assume we have the right data. This would appear as completely transparent for BGRA surfaces, and completely black for BGRX surfaces. With this patch, we now properly remove purged surfaces instead of including them in the report. This ensures that the cache state is consistent. This also resolves memory reports of surfaces which reported using no data -- they were purged when the report was generated. Additionally, there was a bug in SurfaceCache::PruneImage where we did not discard surfaces outside the module lock. Both PruneImage and CollectSizeOfSurfaces now free any discarded surfaces outside the lock.
74faaba5ecd2fae75df27f3186f9f6eb8d1fa4bc: Bug 1399944 - Check for valid GC cell pointers in various places r=sfink
Jon Coppeard <jcoppeard@mozilla.com> - Tue, 19 Sep 2017 12:31:31 +0100 - rev 667069
Push 80609 by bmo:mstriemer@mozilla.com at Tue, 19 Sep 2017 17:59:49 +0000
Bug 1399944 - Check for valid GC cell pointers in various places r=sfink
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip