eec946b5936068af4034b536735710e6f15d2e2a: Bug 1412090 - patch 3 - Check the sandbox policy to verify font files will be readable by the content process before including them in the system font list. r=gps
Jonathan Kew <jkew@mozilla.com> - Thu, 09 Nov 2017 16:54:30 +0000 - rev 441835
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1412090 - patch 3 - Check the sandbox policy to verify font files will be readable by the content process before including them in the system font list. r=gps
72a6f5f3512c49acc3e3735dbadd1007f9ddc54c: Bug 1412090 - patch 2 - Rework the fontconfig-based platform font list implementation to pass the list of available font patterns from chrome to content, instead of letting the content process get it directly from fontconfig. r=lsalzman
Jonathan Kew <jkew@mozilla.com> - Thu, 02 Nov 2017 20:29:33 +0000 - rev 441834
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1412090 - patch 2 - Rework the fontconfig-based platform font list implementation to pass the list of available font patterns from chrome to content, instead of letting the content process get it directly from fontconfig. r=lsalzman
ea8ee40ed426ff032fb9ba0345cc45bf6097bd23: Bug 1412090 - patch 1 - Wrap the font family record used to pass font info from chrome to content on macOS in a union, in preparation for using the same mechanism with a different type of font record on Linux. (No functional change here, just the added union type and some renamings from 'font family list' to 'font list' to be more generic.) r=lsalzman
Jonathan Kew <jkew@mozilla.com> - Thu, 02 Nov 2017 17:23:16 +0000 - rev 441833
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1412090 - patch 1 - Wrap the font family record used to pass font info from chrome to content on macOS in a union, in preparation for using the same mechanism with a different type of font record on Linux. (No functional change here, just the added union type and some renamings from 'font family list' to 'font list' to be more generic.) r=lsalzman
a48c10a1e0644ae267d26c9d5d4a7c358852ed13: Bug 1415880 - Remove the obsolete mIsValid flag from gfxFontEntry, as nothing depends on it any more. r=jrmuizel
Jonathan Kew <jkew@mozilla.com> - Thu, 09 Nov 2017 16:54:02 +0000 - rev 441832
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1415880 - Remove the obsolete mIsValid flag from gfxFontEntry, as nothing depends on it any more. r=jrmuizel
4ef361678c07c388cdae9c807a7d6f3796ab20fa: Bug 1393441 - Disable test_bug293235.xul for on-going frequent intermittent failures; r=me,test-only
Geoff Brown <gbrown@mozilla.com> - Thu, 09 Nov 2017 09:33:03 -0700 - rev 441831
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1393441 - Disable test_bug293235.xul for on-going frequent intermittent failures; r=me,test-only
dbdadf5e2691bb6a159ffcefae97221110d3d533: Bug 1413442 - Disable test browser_inspector_highlighter-eyedropper-events.js on Windows for on-going frequent intermittent failures; r=me,test-only
Geoff Brown <gbrown@mozilla.com> - Thu, 09 Nov 2017 09:33:00 -0700 - rev 441830
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1413442 - Disable test browser_inspector_highlighter-eyedropper-events.js on Windows for on-going frequent intermittent failures; r=me,test-only
e47ee65540ba07f65f194908157834edd41a2272: Bug 1414632 - Prevent division by zero in webrtc::Merge::SignalScaling; r=jesup
Dan Minor <dminor@mozilla.com> - Wed, 08 Nov 2017 12:39:53 -0500 - rev 441829
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1414632 - Prevent division by zero in webrtc::Merge::SignalScaling; r=jesup A zero input_length here would be caused by a decoder error in NetEqImpl::Decode(). Looking at the code in GetAudioInternal() which calls Decode() it appears that the intention is to continue processing even if no new audio data is decoded. Based on this, it seems safest to just skip muting in SignalScaling if the input_length is zero. The other potential cause of a division by zero here is if fs_mult_ is zero which should not normally happen. But there's no harm in checking for that as well. MozReview-Commit-ID: J0pd2wbjeZl
7d9324e2ab34946539be9f17d74f639aae5ba7e5: Don't reuse a back buffer after a swap if the content or surface changed (bug 1399692 part 9, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Sun, 05 Nov 2017 10:38:47 -0500 - rev 441828
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Don't reuse a back buffer after a swap if the content or surface changed (bug 1399692 part 9, r=bas) MozReview-Commit-ID: HGAxkeyESbc
76bf99decf0906f0a6a4ad99539fd40f97c4539f: Don't copy over regions that will be painted in this frame (bug 1399692 part 8, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Sat, 04 Nov 2017 14:52:31 -0400 - rev 441827
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Don't copy over regions that will be painted in this frame (bug 1399692 part 8, r=bas) We do the same in FinalizeFrame, so we should do it here. MozReview-Commit-ID: JTKDj8yrtI2
0fc2414f146d8f5d08c97e5b7eedb25c5632ab2d: Replay buffer commands on paint thread when OMTP is enabled (bug 1399692 part 7, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Thu, 26 Oct 2017 00:47:17 -0400 - rev 441826
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Replay buffer commands on paint thread when OMTP is enabled (bug 1399692 part 7, r=bas) This commit does the work of actually dispatching the recorded buffer operations to the paint thread, and removing some main thread asserts from TextureClient. MozReview-Commit-ID: CN3RoQPz9fP
f235b12eda6efe0bdec8e6590d813738f53ffe82: Record buffer operations to a struct for replaying on paint thread (bug 1399692 part 6, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Wed, 25 Oct 2017 10:20:49 -0400 - rev 441825
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Record buffer operations to a struct for replaying on paint thread (bug 1399692 part 6, r=bas) This commit adds a CapturedBufferState which is used to record all the operations that are necessary for preparing the buffers. The commands are then instantly executed to preserve the same behavior, but in the following commit they will be dispatched to the paint thread. Note: RotatedBuffer's aren't thread safe and so a shallow copy needs to be made for sending to the paint thread. This complicates the code for AdjustTo as it can fail naturally and the buffer parameter changes are needed later in BeginPaint. So the code for AdjustTo is split up a bit to accomodate that. MozReview-Commit-ID: FwSwFay887o
467532fd5b7a2385ba0dbdb9201e28e8f2b4a583: Simplify copying the front buffer to the back buffer (bug 1399692 part 5, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 18:27:53 -0400 - rev 441824
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Simplify copying the front buffer to the back buffer (bug 1399692 part 5, r=bas) To sync the back buffer with the front buffer, we set the back buffer rect and rotation to the front buffer's, and then copy over the pixels that different. We used to do the updating of the rect and rotation before BeginPaint, but that isn't necessary and we can move it to be with the copying of pixels. MozReview-Commit-ID: HzBKvMZkn1
dce585be0737f3c9b6b241afb0851d85fb9453c9: Don't create back buffer for front buffer until we know what type to create. (bug 1399692 part 4, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 15:33:40 -0400 - rev 441823
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Don't create back buffer for front buffer until we know what type to create. (bug 1399692 part 4, r=bas) This commit is an optimization for double buffering that delays the creation of a back buffer until we know what kind of content type it needs to be. Before this commit, we would EnsureBackBufferIfFrontBuffer before BeginPaint, then in BeginPaint we could determine that we actually needed a different kind of buffer because the content changed type, and recreate it. This was needed because BeginPaint would copy the old front buffer to the buffer created by EnsureBackBufferIfFrontBuffer, and then if anything failed or we had determined we couldn't reuse the buffer, we would create a new one and copy that "temporary" back buffer over, and use the new one. This is unnecessary because we only need read access on that "temporary" back buffer, and so we can just use the current front buffer instead. This optimization only affects the double buffered case, and the single buffered or basic cases should remain the same. Note: Because we now need the front buffer for copying into the new back buffer, we cannot Clear() it away in some error cases. Note: The code in FinalizeFrame assumes that the back and front buffer have the same size. This was implicitly enforced before, and now needs to be explicitly enforced. This commit tries to preserve the exact same behavior, although the restriction should be removed as long as the back buffer is large enough for the visible region. MozReview-Commit-ID: 2hyrrUhA4zO
b971c1aa5a78c17d49d1d64389516437024be72a: Remove BufferContentType and add ValidBufferSize (bug 1399692 part 3, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 14:56:13 -0400 - rev 441822
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Remove BufferContentType and add ValidBufferSize (bug 1399692 part 3, r=bas) BufferContentType and BufferSizeOkFor make more sense as general functions for any RotatedBuffer, and this helps out in a later patch. MozReview-Commit-ID: EAVodvl4WTu
8ba8bda8521a6460b1213d2d0f14ebefc0a3e14a: Simplify the code for creating a new back buffer (bug 1399692 part 2, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Mon, 23 Oct 2017 12:40:01 -0400 - rev 441821
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Simplify the code for creating a new back buffer (bug 1399692 part 2, r=bas) MozReview-Commit-ID: D28JNYWD9Uc
2c41a712dff22de4fb2bbfd7c5a418fbc3a26f11: Remove unneeded lambda capture in paint thread (bug 1399692 part 1, r=bas)
Ryan Hunt <rhunt@eqrion.net> - Tue, 31 Oct 2017 01:55:24 -0400 - rev 441820
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Remove unneeded lambda capture in paint thread (bug 1399692 part 1, r=bas) MozReview-Commit-ID: 71X22PHRTRz
eadac792a9e36ff1bca0aad5edb790953d9525df: Bug 1414974 - Part 7: Remove nsGlobalWindow::Cast in favor of nsGlobalWindow{Inner,Outer}::Cast, r=smaug
Nika Layzell <nika@thelayzells.com> - Tue, 07 Nov 2017 11:40:21 -0500 - rev 441819
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1414974 - Part 7: Remove nsGlobalWindow::Cast in favor of nsGlobalWindow{Inner,Outer}::Cast, r=smaug MozReview-Commit-ID: DCyyvQ0xKOj
cd4b951a1f54bdab2e8c5adfc1bf699e5cc6b10c: Bug 1414974 - Part 6: Change WebIDL bindings to refer to nsGlobalWindowInner rather than nsGlobalWindow, r=bz
Nika Layzell <nika@thelayzells.com> - Mon, 06 Nov 2017 17:52:14 -0500 - rev 441818
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1414974 - Part 6: Change WebIDL bindings to refer to nsGlobalWindowInner rather than nsGlobalWindow, r=bz MozReview-Commit-ID: KbCpDFoWyTe
32a9df9f2b077cc08972c0fe2cef46c1d1e2a318: Bug 1414974 - Part 5: Rework nsWindowMemoryReporter to only examine inner windows, r=mccr8
Nika Layzell <nika@thelayzells.com> - Mon, 06 Nov 2017 14:48:02 -0500 - rev 441817
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1414974 - Part 5: Rework nsWindowMemoryReporter to only examine inner windows, r=mccr8 MozReview-Commit-ID: 3be0C8OXSKo
ca6ed81bfc6789042be3b1947b7cc170dfef429f: Bug 1414974 - Part 4: Split WindowByIdTable into two separate tables for inner and outer windows, r=bz
Nika Layzell <nika@thelayzells.com> - Mon, 06 Nov 2017 17:59:12 -0500 - rev 441816
Push 8134 by ryanvm@gmail.com at Fri, 10 Nov 2017 21:18:48 +0000
Bug 1414974 - Part 4: Split WindowByIdTable into two separate tables for inner and outer windows, r=bz MozReview-Commit-ID: LH3lKkFqTgG
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip