It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
Our implementation is totally not what the spec says, but totally what other
UAs do, see https://github.com/w3c/csswg-drafts/issues/2474.
So given this is causing webcompat pain, I think we should be pragmatic and just
unprefix this.
We could keep serialization and getComputedStyle with ::selection working with a
bit more effort, like we do for :-moz-placeholder, but I'd prefer not doing at
least the serialization bit, and just alias in nsCSSPseudoElements
:-moz-selection to selection too.
MozReview-Commit-ID: 6lxctozRDqv
We will remove animation.effect.timing in the next patch.
MozReview-Commit-ID: EyeFNM81NbN
--HG--
extra : rebase_source : 9fe5eb0e5d141ffffa017db255328c742a059611
MozReview-Commit-ID: CYeBKhDYD1F
The distance field does not calculate a true Euclidean distance, so it is
unreasonable to require that the intervals span all of the BStart() to BEnd()
float area. The final block pixel may not generate an interval at all due to
rounding errors. This change makes accomodation for the rounding errors and
adds asserts to ensure we aren't tolerating errors outside the area of the
last block pixel.
--HG--
extra : rebase_source : 114c1667861c90a055295f9bd40a3991cbb5dc88
Move from nsStyleColor::CalcComplexColor to StyleComplexColor::CalcColor.
MozReview-Commit-ID: FkYovvPZLc8
--HG--
extra : rebase_source : 54f1966e0ef9258f20e954cd6250774008eca04c
None of the C++ callers of RemoveSelectionListener care about whether the
listener was already-added, and the only JS caller is in a test and knows the
listener was added. So the behavior change to no-op instead of throwing when
trying to remove a nonexistent listener is OK. Furthermore, the removal is
null-safe, so there's no point to explicitly failing if null is passed (which
it never is).
Since content can't directly add selection listeners, we can just use an
infallible append instead of returning errors callers don't check for anyway.
Also, no one passes null to AddSelectionListener, so we don't have to worry
about that part.
This way we don't have to deal with QI to get a Selection out of a weakref.
mfbt weakrefs don't have a SizeOfOnlyThis. In any case, the memory used by the
weakref itself is pretty minor...
This reftest fails without the fix in this series.
MozReview-Commit-ID: 3C8TEuCoTS3
--HG--
extra : rebase_source : 13278ee2f8f8facd38d050711330164bf9a174dd
In case of table element, display item has the primary frame for the element,
whereas for animation stuff we basically use the style frame instead.
MozReview-Commit-ID: GT6yaXv3wM4
--HG--
extra : rebase_source : e6c68949d80a3deb51309c1bd1d8a3d2142f0e9f
And drop an unnecessary forward declaration for nsIFrame from AnimationCommon.h.
MozReview-Commit-ID: IYroCrg1rtq
--HG--
extra : rebase_source : f41fc19e2cff4ef0dba26192b2f19edfb57189d6
We no longer need them since in the previous commit we make sure subsequent
ticks happens for animations in delay phase.
MozReview-Commit-ID: F68wCCsCEiE
--HG--
extra : rebase_source : d6ebe9bfa90a767154cea04255dbf4a5403674fe
Having the native theme widget to flip its own direction turned out to be
something not needed anymore, and it interfere with the CSS rule we set to
flip non-native SVG background.
This patch turned that off and always flips the resizer with CSS transform.
MozReview-Commit-ID: EbjTfFpJpZ0
--HG--
rename : layout/reftests/forms/textarea/resize-ref.html => layout/reftests/forms/textarea/resize-rtl-ref.html
rename : layout/reftests/forms/textarea/resize.html => layout/reftests/forms/textarea/resize-rtl.html
extra : rebase_source : a319698cea6c8460aaed23948e20b0757cec686e
The test case has a fixed item A inside a scrollframe B which is inside
a reference frame C which is inside the root scrollframe D. The
ClipManager code currently uses D's scrollid as the scrolling ancestor
for A, because the gecko display list's ASR is set up that way. However,
we really want to set C as the scrolling ancestor, because otherwise the
item A gets hoisted out of C and the transform from C doesn't get
applied to it. This patch ensures that when we enter C, we install an
override so that anything that would have used D's scrollid ends up
using C's, which results in the correct behaviour.
MozReview-Commit-ID: 31tscfT4xWW
--HG--
extra : rebase_source : 03df2fa5519b2592a2c9f598af0f3f1500773718
This is one of the most important steps for bug 1459498. After this I can use
StyleSheetInfo to compute IsAlternate. Still all the preferred stylesheet stuff
is crazy...
MozReview-Commit-ID: 9ZHW9AYGoBe
I've kept the nsAutoStrings in the StyleSheetInfo class on the hopes that the
compiler does RVO, but if it doesn't I can remove I guess.
MozReview-Commit-ID: 2vN6BSEhYcw
The clip chain API in webrender allows us to build the clip state in WR
so that it matches the gecko display list more closely. This patch throws
away ScrollingLayersHelper.* and introduces ClipManager.* which pushes
the clip state to WR using the new method. A quick summary of the new
method is below.
Each display item in gecko has a DisplayItemClipChain which is a chain
of individual clips. The individual clips are defined in WR, and the
clip ids for those clips are put into a WR clip chain using the new
define_clip_chain API. Furthermore, each clip chain can also have a
parent chain, which is used to link a DisplayItemClipChain to the parent
display item's DisplayItemClipChain. This allows the WR clip state to
closely match the structure of the gecko display list clip state,
resulting in more correct behaviour.
There are a few other major changes that are lumped into this patch and
that were tricky to separate into their own patches:
- The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR
side all the clip ids are treated the same anyway. Trying to preserve
the arbitrary distinction on the gecko side was resulting in
increasingly convoluted code, with different kinds of Variant<..>
types in the method signatures. It was much simpler and resulted in a
bunch of code deletion to just collapse the types.
- Moving the "override" mechanism from WebRenderAPI to ClipManager. The
override mechanism (explained in ClipManager.h) was simplified by
moving it into ClipManager, because it removed the need for tracking
additional clip stack state in WebRenderAPI.
MozReview-Commit-ID: GGbdFyJGprK
--HG--
extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
Instead of downloading the build artifacts (rather hackily) in moztest.fixtures, this now happens
directly in the taskgraph module via the run-task script.
For now extraction and setup happens in the task's command key. It might be a good idea to figure
out a syntax to tell run-task to do this extraction, e.g something like:
run:
using-artifacts:
build:
target.tar.bz2:
extract: true
path: /home/worker/build
name: firefox
But for now I wanted to avoid this extra complexity, so maybe it could be done in a follow-up.
MozReview-Commit-ID: KOhFFpFdP7Y
--HG--
extra : rebase_source : dcea36661fa9c6442c76c850ccc67f8f6d924fda
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 : 247e5b197e998682cb4bb74f6f9319a9a4dd3264
The main thing to have into account is that the styleset to use is either
mLastStyleSheetSet, or mPreferredStyleSheetSet.
This last one gets set from Loader::IsAlternateSheet, which is quite nasty and
what I'm trying to remove.
MozReview-Commit-ID: BI4P1Chqtli
The patches in this bug makes layout get more accurate values. That apparently
is confusing WebRender, which renders one more pixel height in some of the
rectangles.
I have no idea why and I couldn't repro out of the reftest harness. I suspect
something something blob invalidation, but...
MozReview-Commit-ID: A2slTJLfJBx
The original code was added in bug 385263 for fixing bug 279032 that a
single font provides zero for max ascent / descent in its HHEA table
which caused Firefox to crash.
Unconditionally picking the maximum of max ascent / descent and their
em correspondents doesn't seem to be essential for working around that
case, so this patch changes it to just use the em ascent / descent when
both max ascent and descent are zero.
This fixes a webcompat problem related to Roboto font on Linux (and
presumably also Android given it uses FreeType backend as well).
MozReview-Commit-ID: EpKrfiOwnZt
--HG--
extra : rebase_source : 0619abf992fb1e1a1f3068ab172880913ebff1f1
If the canvas is cleared by setting the width or height attributes, its
opaqueness should not be affected.
This patch keeps support for moz-opaque, and also keeps the behavior that
changing the moz-opaque attribute clears the canvas, even if this does not
affect the actual opaqueness of the canvas.
MozReview-Commit-ID: LOlsJxiP9kc
--HG--
extra : rebase_source : 8bb95b1d5932c39a8085e007f9fd1b88b97afe55
This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 45f0f8f11698890fae0dcca71174f88dbdb412c8
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