Some content in Makefile.in is removed because after this change, the
scripts no longer invoke the preprocessor and thus don't have unknown
dependencies anymore outside what is provided in their inputs array.
The order of exports.PREFERENCES in properties-db changes because the
data file has shorthands placed after longhands. The only usage of it
is in test_css-properties-db.js which doesn't care about the order.
MozReview-Commit-ID: AMjzTRf2HYN
--HG--
extra : rebase_source : 7976e48e7c7bba467d77a34ab0d7709cde1ecdf4
Some content in Makefile.in is removed because after this change, the
scripts no longer invoke the preprocessor and thus don't have unknown
dependencies anymore outside what is provided in their inputs array.
The order of exports.PREFERENCES in properties-db changes because the
data file has shorthands placed after longhands. The only usage of it
is in test_css-properties-db.js which doesn't care about the order.
MozReview-Commit-ID: AMjzTRf2HYN
--HG--
extra : rebase_source : f9db0659a81bea28b335806ac70e23dc0d36e493
We need to add the system font keywords separately in InspectorUtils so
that we don't regress values listed in inspector.
MozReview-Commit-ID: 7a8CKGeSn4K
--HG--
extra : rebase_source : 12a1fcd0294b42568d8da596639b2733ba57186e
It only has one use, has the same effect that "auto", and should have no effect
in <a> elements anyway (plus it's not overridden or used in that file at all
anyway), so we can remove its only use instead.
I can also change that use to "auto" if you want, but bug 760876 doesn't mention
-moz-user-input at all, so I think this is quite useless...
See the intent to unship for research on out of the tree usage:
https://groups.google.com/d/msg/mozilla.dev.platform/E6tfP__wkwg/YVW6nPX9CQAJ
MozReview-Commit-ID: 8EzQlzu9drE
This fixes InspectorUtils::getCSSValuesForProperty to return the
correct values for line-style-type.
MozReview-Commit-ID: 72Tes6y15j8
--HG--
extra : rebase_source : fa893f59cafc433f554353cf42d0f9495cdd5b23
This changes getCSSValuesForProperty to return the correct values for
the "content" property.
MozReview-Commit-ID: 2F5LQPbSIFs
--HG--
extra : rebase_source : 290df953c8234888801b7a8a6ef5668a11a59bea
This fixes getCSSValuesForProperty for clip and clip-path.
Although clip is deprecated, it seemed harmless to fix it as well;
when it is removed this code will also be readily found and removed.
It wasn't clear to me if setting the keyword table for clip-path in
nsCSSPropList.h would be ok, so I added a special case in
InspectorUtils.
MozReview-Commit-ID: Ghawr17HjKk
--HG--
extra : rebase_source : 29c094afd678019b4f3f49ac55493ef0d7d6848f
This fixes InspectorUtils.getCSSValuesForProperty to return the
correct values for box-shadow and text-shadow. It also takes a small
step toward the goal of getting rid of
InspectorUtils.cpp:PropertySupportsVariant, in favor of having all
variants listed in nsCSSPropList.h.
MozReview-Commit-ID: Dwh5s0IvYTX
--HG--
extra : rebase_source : eba2d3e7337af63c264bf3d596740f311c4aa017
getCSSValuesForProperty was not including "calc" for object-position
and perspective-origin. Fixed by updating the variants in
nsCSSPropList.h.
MozReview-Commit-ID: 8STipRhqFwT
--HG--
extra : rebase_source : 70cbb9fc1a9b3a1084bd8846f065f0876daccd75
Currently, InspectorUtils::GetCSSValuesForProperty will not return
"match-parent" for "text-align". The bug is that InspectorUtils uses
an out-of-date approach to finding the end of the keyword table; and
this approach conflicts with the special "unsafe" handling in
TextAlignUnsafeEnabledPrefChangeCallback:
https://dxr.mozilla.org/mozilla-central/rev/21ddfb9e6cc008e47da89db50e22697dc7b38635/layout/base/nsLayoutUtils.cpp#317-321
MozReview-Commit-ID: 58qfKQwIyMX
--HG--
extra : rebase_source : 022a8c970c121cbe76533a29d0439a64ead63085
This bug notes that getCSSValuesForProperty does not mention the
"none" value for counter-increment and counter-reset. This fixes the
problem by mentioning the variants in the entries in nsCSSPropList.h.
MozReview-Commit-ID: HpZIMIIejHc
It seemed valid to simply set the expected variants in
nsCSSPropList.h; other properties (e.g., align-content) do this as
well.
MozReview-Commit-ID: HVZGOofkwi1
--HG--
extra : rebase_source : 53388e48c491843a3fd93a3c46fdcd9c9bd3cc41
The "all" property in the devtools CSS database included all possible
property values; however only a few are truly appropriate. This patch
adds a special case for "all" to
InspectorUtils::GetCSSValuesForProperty to fix this.
MozReview-Commit-ID: HEnrvCJylHI
--HG--
extra : rebase_source : 4738129974b95e2c231cd92cd5e4bc04e6708409
devtools/shared/css/generated/properties-db.js is generated by running
"./mach devtools-css-db"
MozReview-Commit-ID: 1U4yoQTDwxi
--HG--
extra : rebase_source : 16049b4253ae9a3f6e24cc30896ed53f65ebaf7a
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
