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
nsLayoutStatics::Initialize is sometimes too early to know whether a process
is an e10s parent process, or a non-e10s main process, because some prefs
get loaded later on. So we unconditionally initialize some Servo data in
nsLayoutStatics::Initialize, but we still check later on whether we are
really a non-e10s main process or e10s content process when deciding whether
to preload Servo style sheets, choose our document backend type, etc.
MozReview-Commit-ID: 93tPCvuTdzl
--HG--
extra : rebase_source : 07092bab376310867fa1a87210ba6c3eddb9cc8e
This isn't a super essential feature, and is just a change to try to bring us in
line with chromium and the spec. As this has apparent web compat issues, and
DataTransfer is a hard to test area, this patch moves the changes behind a pref,
which we can come back to turning on after we ship 57.
In the printing preview, we create continuous table frame if table is too
long to containing in a page. But the default value of
NeedToCalcHasBCBorders is false which means we don't calculate
HasBCBorders for continuous table frame. Thus, the border collapse is
not shown when printing preview.
MozReview-Commit-ID: IqhLSYuWj30
The old code doesn't work because mScriptHandlingObject is a nsWeakPtr,
which cannot be casted to nsPIDOMWindowInner directly.
Since scriptHandlingObject is a strong reference to the same object, we
can just try casting that.
MozReview-Commit-ID: JRBs5N6xxc0
--HG--
extra : rebase_source : cd0237553198182b00ff9c667a17271b23464567
This matches the behaviour of mouse events over a scroll thumb.
MozReview-Commit-ID: ArLzC6JXfos
--HG--
extra : rebase_source : 96f83e6b312dabd3c5573d73c1ce3f01e53055e5
This ensures that, if the touch event is over a scrollbar thumb and
makes it into nsSliderFrame::StartAPZDrag(), nsSliderFrame knows
that the event went through APZ and that therefore APZ will handle
the drag.
MozReview-Commit-ID: 92wAc1l9Pqz
--HG--
extra : rebase_source : 94ac60bc8b38dad3d8abaa39b5a94de88ec0f6b0
This just adds two basic tests, one for a passing test and another for a
failing one. In mochitest, we use privileged APIs to also tests crashes,
assertions, asan and leaks. But these APIs aren't available to reftests
so I'm not sure how we can test these things.
I figure it's not worth holding the framework up on this though, I'll file
a follow-up to figure out something to do for that.
MozReview-Commit-ID: 59TSbsugT5T
--HG--
extra : rebase_source : 72ecd817017c8b7d55eab879db4f6ad5fecc54c0
Expose the API to get/set inherited scale from stacking context and we can
use these APIs to calculate correct scale for OMTA
MozReview-Commit-ID: DZEkodHTy8v
--HG--
extra : rebase_source : be3c978c8f48c9b1bfcd01cff6bb8200092b5e60