0f9c02e66eb6ca9dbd0d24b9cc53212748260392: Bug 1387594 - Add a chrome-only CSS property called -moz-font-smoothing-background-color. r?dbaron draft
Markus Stange <mstange@themasta.com> - Wed, 16 Aug 2017 17:06:12 -0400 - rev 663843
Push 79540 by bmo:mstange@themasta.com at Wed, 13 Sep 2017 12:47:31 +0000
Bug 1387594 - Add a chrome-only CSS property called -moz-font-smoothing-background-color. r?dbaron This property accepts a color. It's inherited and defaults to transparent. Its value is respected on macOS when rendering text into transparent pixels. This property should be used for text that is placed on top of "vibrant" -moz-appearances, in order to achieve high quality text rendering for such text. In most cases, the property should be set to a named system color; an upcoming patch in this patch series will add one such color for each vibrant -moz-appearance value. However, in some cases it can also be useful to use a custom color: If text is rendered into an intermediate surface, for example because a mask is applied to it, and the background color behind that intermediate surface is known, then this property can be set to that background color in order to achieve subpixel AA for the text inside the mask effect. In that case, the font smoothing background color is respected because text is rendered into transparent pixels *inside the intermediate surface*. At the moment, the only example of that use case is the text of the active tab in the state where the text is overflowing. MozReview-Commit-ID: D98qQnxoFaq
021e527b4982641c34f5d9aeaf3de4f04fa2c4d3: Bug 1398057 - Not all command arguments are printed to the log. draft
Henrik Skupin <mail@hskupin.info> - Wed, 13 Sep 2017 09:15:42 +0200 - rev 663842
Push 79539 by bmo:hskupin@gmail.com at Wed, 13 Sep 2017 12:43:00 +0000
Bug 1398057 - Not all command arguments are printed to the log. By logging the used browser arguments from geckodriver only the -marionette argument ends up in the log. Instead mozrunner should be used which knows about any of them. MozReview-Commit-ID: J9px0pWSwQm
9b7fe1fabf0c73d1024abe70240ca58043bf3b9e: Bug 1387594 - Sprinkle -moz-font-smoothing-background-color declarations over the CSS. r?dao draft
Markus Stange <mstange@themasta.com> - Wed, 13 Sep 2017 13:49:08 +0200 - rev 663841
Push 79538 by bmo:mstange@themasta.com at Wed, 13 Sep 2017 12:18:41 +0000
Bug 1387594 - Sprinkle -moz-font-smoothing-background-color declarations over the CSS. r?dao There's only one interesting case here: the active tab. When rendering the label of an overflowing active tab into the fadeout mask surface, text rendering must not use the font smoothing background color for dark vibrancy. Instead, it needs to use the color of the tab itself for best results. Alternatively, we could set the font smoothing background color of the active tab to "transparent", because this text is not on top of a vibrant background. However, doing so would lose the subpixel AA and would not look as crisp. MozReview-Commit-ID: 28MKCz1vmb9
6abbf80d0b26974b256f41f7607596d8a909ad66: Bug 1387594 - Add system colors for use in conjunction with -moz-font-smoothing-background-color and vibrant -moz-appearances. r?dbaron draft
Markus Stange <mstange@themasta.com> - Wed, 13 Sep 2017 13:48:07 +0200 - rev 663840
Push 79538 by bmo:mstange@themasta.com at Wed, 13 Sep 2017 12:18:41 +0000
Bug 1387594 - Add system colors for use in conjunction with -moz-font-smoothing-background-color and vibrant -moz-appearances. r?dbaron MozReview-Commit-ID: IxXZwONxy41
567a7b3d7aed2d2ccebe3e47ce521a1cfa20e0b4: Bug 1387594 - Respect the font smoothing background color in pushed layers again. This backs out bug 1386643. r?jrmuizel draft
Markus Stange <mstange@themasta.com> - Thu, 17 Aug 2017 15:59:46 -0400 - rev 663839
Push 79538 by bmo:mstange@themasta.com at Wed, 13 Sep 2017 12:18:41 +0000
Bug 1387594 - Respect the font smoothing background color in pushed layers again. This backs out bug 1386643. r?jrmuizel MozReview-Commit-ID: KNsd7tKuRk1
4dbc4a9fb0e10ec44c6bbb79c16ee3af83d8bdf6: Bug 1387594 - Set the font smoothing background color based on the -moz-font-smoothing-background-color property. r?mattwoodrow draft
Markus Stange <mstange@themasta.com> - Thu, 17 Aug 2017 15:59:04 -0400 - rev 663838
Push 79538 by bmo:mstange@themasta.com at Wed, 13 Sep 2017 12:18:41 +0000
Bug 1387594 - Set the font smoothing background color based on the -moz-font-smoothing-background-color property. r?mattwoodrow MozReview-Commit-ID: B3PVIvMswf8
59ff33f6f865dc8e6f4be43f250d4724ff7964ec: Bug 1387594 - Stop getting the font smoothing background color from the theme. r?mattwoodrow draft
Markus Stange <mstange@themasta.com> - Thu, 17 Aug 2017 15:58:31 -0400 - rev 663837
Push 79538 by bmo:mstange@themasta.com at Wed, 13 Sep 2017 12:18:41 +0000
Bug 1387594 - Stop getting the font smoothing background color from the theme. r?mattwoodrow MozReview-Commit-ID: 2r1B8SvEkEl
d1b330eebfc10ccfc2ab1e88f1fac702cabb4ed3: Bug 1387594 - Add a chrome-only CSS property called -moz-font-smoothing-background-color. r?dbaron draft
Markus Stange <mstange@themasta.com> - Wed, 16 Aug 2017 17:06:12 -0400 - rev 663836
Push 79538 by bmo:mstange@themasta.com at Wed, 13 Sep 2017 12:18:41 +0000
Bug 1387594 - Add a chrome-only CSS property called -moz-font-smoothing-background-color. r?dbaron This property accepts a color. It's inherited and defaults to transparent. Its value is respected on macOS when rendering text into transparent pixels. This property should be used for text that is placed on top of "vibrant" -moz-appearances, in order to achieve high quality text rendering for such text. In most cases, the property should be set to a named system color; an upcoming patch in this patch series will add one such color for each vibrant -moz-appearance value. However, in some cases it can also be useful to use a custom color: If text is rendered into an intermediate surface, for example because a mask is applied to it, and the background color behind that intermediate surface is known, then this property can be set to that background color in order to achieve subpixel AA for the text inside the mask effect. In that case, the font smoothing background color is respected because text is rendered into transparent pixels *inside the intermediate surface*. At the moment, the only example of that use case is the text of the active tab in the state where the text is overflowing. MozReview-Commit-ID: D98qQnxoFaq
4dc3ec796be235e21dec211794bf1585777d3555: Bug 1394284 - add fallback discrete interpolation procedure for transform animation. draft
Jeremy Chen <jeremychen@mozilla.com> - Wed, 13 Sep 2017 17:39:07 +0800 - rev 663835
Push 79537 by bmo:jeremychen@mozilla.com at Wed, 13 Sep 2017 12:12:08 +0000
Bug 1394284 - add fallback discrete interpolation procedure for transform animation. According to the spec, if one of the matrices for transform interpolation is non-invertible, the used animation function must fall-back to a discrete animation. However, in the current implementation, we always use an identity matrix as a fallback for the non-invertible matrix. Decompose2DMatrix and Decompose3DMatrix both return a boolean, but we just never use it. So, in this patch, we use the returned boolean from the matrix decomposition as a condition, and add the fallback discrete interpolation procedure for the non-invertible matrices case. MozReview-Commit-ID: E7i1a1MJOXN
b2a0c9b69e4b729ecb463c7f686b22cc2bf821c9: Bug 1394284 - add wpt test for fallback discrete type of transform animation. draft
Jeremy Chen <jeremychen@mozilla.com> - Tue, 12 Sep 2017 13:29:04 +0800 - rev 663834
Push 79537 by bmo:jeremychen@mozilla.com at Wed, 13 Sep 2017 12:12:08 +0000
Bug 1394284 - add wpt test for fallback discrete type of transform animation. According to the spec, if one of the matrices for transform interpolation is non-invertible, the used animation function must fall-back to a discrete animation. Add wpt tests so we can ensure the web compability for this behavior. Note that we don't add 'discrete' type for transform property in property-list.js. Because the 'discrete' type also tests discrete addition and accumulation, however, the fallback behavior is just for interpolation. So, we add tests in testInterpolation of transformListType in property-types.js. MozReview-Commit-ID: 3JGvgqbBqZp
43d0b3d102c99ee160b4522834b1c507c6f1ed72: Bug 1394284 - stylo: do not handle the fallback discrete animation inside the Animate trait. draft
Jeremy Chen <jeremychen@mozilla.com> - Mon, 11 Sep 2017 16:04:12 +0800 - rev 663833
Push 79537 by bmo:jeremychen@mozilla.com at Wed, 13 Sep 2017 12:12:08 +0000
Bug 1394284 - stylo: do not handle the fallback discrete animation inside the Animate trait. At present, we do the fallback discrete animation for non-invertible matrices in ComputedMatrix.animate(). However, according to the spec, we should fallback to discrete animation for cases like: 1. animation between transform with single non-invertible matrix 2. animation between transform with matched transform functions that have at least one non-invertible matrix 2. animation between transform with mismatched transform functions that have at least one non-invertible matrix. The current implementation only handles the first case. Moreover, we already have fallback discrete animation procedures in CSS Animation and Web Animation, so we should be able to not doing any fallback inside the Animate trait. In this patch, we let the animation between non-invertible matrices to return Err(). So, we can propagate the Err() to the callers, and let the fallback discrete animation procedure stay at the Servo_MatrixTransform_Operate, which is ouside the Animate trait. MozReview-Commit-ID: D1ObSj5kP5q
5f00d2f72889e6d1a4f67ddfa49cf67284e89faf: Bug 1397325 - Fix broken font size for in-content pages r?dao draft
Ricky Chien <ricky060709@gmail.com> - Thu, 07 Sep 2017 14:51:32 +0800 - rev 663832
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397325 - Fix broken font size for in-content pages r?dao MozReview-Commit-ID: ASbgxVQJA82
1888ec2f277f6bb26271b8808e08914a21db9efe: merge autoland to mozilla-central. r=merge a=merge
Sebastian Hengst <archaeopteryx@coole-files.de> - Wed, 13 Sep 2017 13:32:44 +0200 - rev 663831
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
merge autoland to mozilla-central. r=merge a=merge MozReview-Commit-ID: 9SALJlvWgoZ
95bb616125726c8bd4c300a1eb182fc8268c7141: Bug 1397717 - Using GenericPrinter for DEBUG-only C++ dump() APIs;r=nbp
David Teller <dteller@mozilla.com> - Thu, 07 Sep 2017 15:22:38 +0200 - rev 663830
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397717 - Using GenericPrinter for DEBUG-only C++ dump() APIs;r=nbp We have a host of DEBUG-only dump()-style APIs that output either to stderr or to a FILE*. Unfortunately, this means that we cannot use these dumps e.g. for unit tests. This patch ports most of the dump() APIs to use GenericPrinter, which is more flexible. Some parts of the code have not been ported, in particular TypeInference, which still uses stderr. MozReview-Commit-ID: A5WGOPyIPTa
784819df6f88b7fd90c63fb3448e422e3bac37e6: Bug 1397141 - part8 : update test for video under 48x48. r=jya
Alastor Wu <alwu@mozilla.com> - Wed, 13 Sep 2017 15:38:24 +0800 - rev 663829
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397141 - part8 : update test for video under 48x48. r=jya In patch3, we remove the minimum resolution check, now the video under 48x48 can be playback successfully. Therefore, removing them from error test and we should ensure they can be playback. MozReview-Commit-ID: BvLtr4DN1hU
578f746a2721df45602ded9a4f95dad1eaaddbd4: Bug 1397141 - part7 : update error description in MFR. r=jya
Alastor Wu <alwu@mozilla.com> - Wed, 13 Sep 2017 15:38:06 +0800 - rev 663828
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397141 - part7 : update error description in MFR. r=jya MozReview-Commit-ID: 9Sb5ogX2Bf2
14249cad9e8ea3c3141a167f268da12bed6820ce: Bug 1397141 - part6 : use MediaResult to replace nsresult r=jya
Alastor Wu <alwu@mozilla.com> - Wed, 13 Sep 2017 15:37:50 +0800 - rev 663827
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397141 - part6 : use MediaResult to replace nsresult r=jya Return MediaResult instead of using nsresult, because it can contain more detailed error information. We could also return this error with our rejected decode promise. MozReview-Commit-ID: 80yEAbxqvWu
5af7f08bcaab7c8cacf7fb344b802474cc3e6705: Bug 1397141 - part5 : update error description from GPU process. r=jya,mattwoodrow
Alastor Wu <alwu@mozilla.com> - Wed, 13 Sep 2017 15:37:24 +0800 - rev 663826
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397141 - part5 : update error description from GPU process. r=jya,mattwoodrow MozReview-Commit-ID: 9aKyYftBnUo
57edd7246a041f3162bea3d60aa3b4b10b1eb38e: Bug 1397141 - part4 : change mLastError type to MediaResult r=jya
Alastor Wu <alwu@mozilla.com> - Wed, 13 Sep 2017 15:05:52 +0800 - rev 663825
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397141 - part4 : change mLastError type to MediaResult r=jya Change mLastError type to MediaResult and send it as parameter to PDM::CreateVideoDecoder in order to get detailed error description. MozReview-Commit-ID: 4sIRXTHsrzr
81a7bf2ee0988cdd98cd9a506071ab4b5ba2f0d3: Bug 1397141 - part3 : remove the minimum resolution check. r=jya
Alastor Wu <alwu@mozilla.com> - Wed, 13 Sep 2017 15:05:45 +0800 - rev 663824
Push 79536 by bmo:rchien@mozilla.com at Wed, 13 Sep 2017 12:07:56 +0000
Bug 1397141 - part3 : remove the minimum resolution check. r=jya After bug 1392143, we won't enable HW decoding for the resolution < 132 pixels. In addition, software decoder doesn't have the minimum resolution limit, so we can remove the minimum resolution check. MozReview-Commit-ID: 7MiLpwjiq3s
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip