This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 11a5264758ab3b2d8faef1e50a666981988457f2
I manually diffed the generated lists and the original ones from in
nsCSSProps.cpp. All generated lists seem to contain the same set of
subproperties as their old correspondents.
There are still some differences:
Order of subproperties of many shorthands is changed. There are many
comments in the old lists stating that the order is important, but they
are mostly for serialization. I auditted all users of the subproperty
lists, and it doesn't seem to me any of them relies on the order.
gOutlineRadiusSubpropTable is renamed to gMozOutlineRadiusSubpropTable
which I don't think is a problem at all, but maybe worth mentioning.
MozReview-Commit-ID: 190SBZfxVOW
--HG--
extra : rebase_source : cd5e8b1667a4550542c361d31361e45456c6b6a3
This removes the extra template file and uses the script to generate
the whole nsCSSPropsGenerated.inc file directly, because it doesn't
seem to really make much sense to have them separate.
One behavior change to this refactor is that, the static assertions
no longer include aliases. Other parts of the generated data all ignore
aliases, so checking property id of aliases isn't really useful. It
makes the code simpler everywhere to just strip aliases from the list
at the very beginning.
MozReview-Commit-ID: BYYvnCOqJwC
--HG--
extra : rebase_source : d683f2dd54e38c6b580435568820c8bc3f52cd70
This patch changes ServoCSSPropList.py to use classes for properties.
This allows extending the data in the file without needing to update all
users of this file.
Sorting in GenerateCSSPropsGenerated.py is removed because the data file
has the right order already.
MozReview-Commit-ID: D74bItCfpPH
--HG--
extra : rebase_source : e0138c255f77515f491496fcb8680686362f4e9e
The parsevariant field is not removed from nsCSSPropList.h since that
file is going away soon anyway.
MozReview-Commit-ID: 3nRBQtmZRKG
--HG--
extra : source : dcb6ff9ec9f61d2ea99253cd34a9d904f89cfe17
This causes various changes to properties-db.js and also many devtools
tests get updated.
There are two changes affect multiple tests:
* `calc` gets removed from everywhere. We never have it listed in all
properties which deserve it, and doing so without much false positive
(i.e. properties don't deserve but get it) can be pretty tricky.
So they are just removed for now.
* The complete color keyword list is no longer included, and instead,
"COLOR" is prepended to the list directly. We can probably remove
the related code which replaces color keywords with "COLOR" from
devtools. Note that, with stylo enabled, the list is already unrelated
to what the parsing code uses. We should eventually re-enable the
disabled test here after we can get the color list from cssparser
in bug 1456715.
Other changes to properties-db.js seem to be valid, some of them also
affect tests:
* `{-webkit-,}align-{content,items,self}` get `first baseline`, `safe`,
`unsafe`, and lose `left` and `right`.
* `{-moz-,-webkit-,}{animation,transition}{,-timing-function}` has a
new `frame` keyword which is a function value in `<timing-function>`.
* `{background,{-webkit-,}mask}-position-x` lose `top` and `bottom`, and
correspondingly `{background,{-webkit-,}mask}-position-y` lose `left`
and `right`. They don't deserve those values.
* `{background,{-webkit-,}mask}{,-size}` get `auto`.
* `border` shorthand loses `<image>` values as well as other keyword
values for `border-image-*` subproperties, because they aren't parsed
on the shorthand.
* `{-moz-,}border-image{,-width}` get `auto`.
* `-moz-context-properties` gets `none`.
* `cursor` get some -moz-prefixed values as well as `url`.
* `fill` and `stroke` get the color keywords.
* `{-webkit-,}filter` get the keywords and function names.
* `font` shorthand loses values from many of `font-variant-*` properties
because they are not parsed there.
* `font-variant` and `font-variant-alternates` get function values of
the longhand.
* `font-variant-{east-asian,ligatures,numeric}` get `normal`, and
`font-variant-ligatures` in addition gets `none`.
`font-{feature,variation}-settings` also get `normal`.
* `grid` and `grid-template-{areas,columns,rows}` get `none`.
* `grid`, `grid-template`, and `grid-template-{columns,rows}` get
`auto`, `fit-content`, `minmax`, and `repeat`.
* `grid-auto-{columns,rows}` get `auto`, `fit-content` and `minmax`.
* `-moz-image-region` gets `auto` and `rect`.
* `{-webkit-,}justify-content` lose `baseline`, `last baseline`, and
get `safe` and `unsafe`.
* `{justify,place}-items` get `first baseline`, `legacy`, `safe`,
`unsafe` and lose `auto`.
* `{justify,place}-self` and `place-content` get `first baseline`,
`safe`, and `unsafe`.
* `outline{,-style}` get `hidden`.
* `scroll-snap-coordinate` gets `none`, and `scroll-snap-points-{x,y}`
gets `none` and `repeat`.
* `shape-outside`, `text-emphasis{,-style}` get all the keyword values
and function names they deserve.
* `stroke-dasharray` gets `none`.
* `text-combine-upright` drops `digits` which we never implemented.
* `{-moz-,-webkit-,}transform` and `-moz-window-transform` get their
transform function list. `accumulatematrix` and `interpolatematrix`
aren't real CSS value but they have `#[css(function)]` specified.
We should probably remove them at some point.
* `will-change` gets `auto`.
* All properties accept `<image>` value now gets -webkit-prefixed
gradient function names, including
* `background{,-image}`,
* `{-moz-,-webkit-,}border-image{,-source}`, and
* `{-webkit-,}mask{,-image}`.
MozReview-Commit-ID: E7Y0CFUFYgW
--HG--
extra : source : bab732c8c531cfca1bcd233f769c25bb2e373773
This is the basic structure of the stuff. Following patches will fill
the gap between Gecko and Servo on value generating, and finally hook
it into InspectorUtils.
MozReview-Commit-ID: KNLAfFBiY6e
--HG--
extra : source : e9e5d72857746710ead3cd42481b805efc771389
System font keywords are not a valid value for those properties.
The newly-added #[css(skip)] would be reused by deriving algorithm of
SpecifiedValueInfo to skip them as well.
MozReview-Commit-ID: EmnhkaA9RR5
--HG--
extra : source : d2fc92ed32f497ff6826228181b19787c1b48cc4
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Shipped since Firefox 48, other browsers have similar impls, and the related
spec has been in CR since a while ago.
The syntax of this property as implemented should be considered to be pretty
stable, so we can remove this pref.
MozReview-Commit-ID: H7lDsdbUamD
--HG--
extra : rebase_source : fda63805d9dea49a55d57153c841426508a882f6
Test changes for removal of PopupBoxObject and popup.xml methods, some reflow tests now have different stacks now that they are not going through popup.xml binding methods, test_popupanchor.xul changes due to need to wait for popuppositioned event after resizing. The old code would just adjust the arrow directly when sizeTo was called, but the new code does this through an asynchronous popuppositioned event. Changes to some places that check for XULElement class.
--HG--
rename : dom/webidl/PopupBoxObject.webidl => dom/webidl/XULPopupElement.webidl
rename : layout/xul/PopupBoxObject.cpp => dom/xul/XULPopupElement.cpp
rename : layout/xul/PopupBoxObject.h => dom/xul/XULPopupElement.h
1 - the old showPopup redirects to showMenu when no argument is specified. Support this in openPopup as bookmarks drag code that pops open menus as you drag over them relies on this
2 - reposition the popup after popup is resized, needed to update the arrow position in the arrow panel
Returning the same type and UpdateStyleSheet.
This hopefully helps seeing how the data flows between the methods, instead of
the messy bits we had before.
MozReview-Commit-ID: C6THNRi8bbg
Some assertions are also removed because they are no longer necessary.
The script generating the flags guarantees those assertions hold.
MozReview-Commit-ID: BgXMBoRBJaJ
An ancient comment from 1998 assures us that GetRect is wrong if there are captions.
The painting code instead uses mVisibleRect which appears to be correct.
MozReview-Commit-ID: 6Lax4sjInJu
--HG--
extra : rebase_source : 79dd527173443fba8d0718c581852d7bfcc47a3c
The label of the button comes from the UI; it's direction should be independent
of the web content directionality. As there is no access to :-moz-locale-dir()
selectors in HTML, we'll have to rely on auto-direction here.
The alternative (or, addition to the fix here) would be adding the value of
the dir attribute to HtmlForm.properties, allowing the localizers to set
the directionality explicitly. I however don't know if that's necessary.
MozReview-Commit-ID: 5NXeLtxLXVH
--HG--
extra : rebase_source : 724eb60ccd841d2355fc17ba31af3cf4792962ef
extra : source : 91d8903ab19812f36aa1732d35d0dc203b0f6281
When a transform thinks it's animated we should abandon screen rasterization
and instead favour local rasterization. This produces a more visually
pleasant rendering, as pixel-snapping "wobbles" the text between
frames.
The float scale of GlyphRasterSpace::Local is currently unused, but this
PR tries its best to set it to a reasonable value, based on discussion
with glennw about the intended semantics. We agreed it should specify
the scale *relative* to the parent stacking context, which means it's
just whatever scaling the stacking context's transform applies. It's
possible we'll need to clamp this value or make it properly 2-dimensional
later on.
Some book-keeping is added to StackingContextHelper to ensure that
GlyphRasterSpace::Screen is never requested by a descendent
of a stacking context using GlyphRasterSpace::Local.
nsDisplayMask is changed to use a StackingContextHelper to ensure
rasterSpace is properly propagated.
In addition, this is the first commit making use of cbindgen's new support
for bridging Rust enums natively into C++! This bumps our minimum cbindgen
to 6.0.0 (just released).
MozReview-Commit-ID: 9AlsB6nUheB
--HG--
extra : rebase_source : 978e51dbedeb1542e0829752b7f828ffeb2872e9
This is the actual fix. The compat mode changed (well, it didn't), but we were
not scheduling a style flush.
Then someone called getComputedStyle on an element in this document, and the
styles were thought clean, thus we didn't flush style, and we assert when style
resolution happened.
MozReview-Commit-ID: KkM6NwzD640
--HG--
extra : rebase_source : 6047872fe6b2fb30b538de874909d428080ed8b5
This patch changes the direction context the dir=bottomend/bottomstart value
from the CSS direction property value to locale dir, with the help
from :-moz-locale-dir(rtl) selector.
The change is justified because:
- In the web content, we have since rely on the nsScrollFrame to set the
direction explicity.
- XUL window should always render in the application locale; it should be
fine to disregard direction property set in the local document DOM teee,
as it is unlikely to be differ than the locale dir.
This remove the one last bit of JavaScript from the resizer binding.
MozReview-Commit-ID: AweJ5GARNUE
--HG--
extra : rebase_source : 17772435a1f9cfdbc7289eb41d69e5922ffdb302
extra : source : edfba1676e4bb74e32cc987d851f7a6b12abef3b
Given that we have access to the RTL/writing modes information via
ScrollFrameHelper::IsPhysicalLTR(), set the dir to bottomleft/bottomright
instead of context-aware value bottomend.
MozReview-Commit-ID: Lfe053WOsY2
--HG--
extra : rebase_source : 3bcab336bbb6ee45adecc95f5c113b76f7ea00c1
extra : source : 60cbc29f51d3605fefa35bcba42ef5f39ed32cdf
This change would bring the tests closer to the real world scenario
MozReview-Commit-ID: 9fslEo8w8Zi
--HG--
extra : rebase_source : 9abe57b41929e0f5184f5c5ee724e27abc157cf9
extra : source : a38a84f76fb90a6b66288cb9bb59d6b869fe81cd