Assuming we call MarkIntrinsicISizesDirty in the appropriate scenarios, this
patch shouldn't change behavior - it just caches these values so we don't
needlessly recalculate them.
MozReview-Commit-ID: 8QY4AZJXshy
--HG--
extra : rebase_source : a7c87b03ac8240ba71efd2198ce1976d96c91f64
This patch does not change behavior; it just merges the implementations of
these two functions into a single common function.
MozReview-Commit-ID: BqsRt3p2NQT
--HG--
extra : rebase_source : e8792f2bed3fd0708ffb38b91cf15a78cb6fbd59
Note that we also drop the dead optional aReusableSheets argument from
the async parsing path, since it was always null.
MozReview-Commit-ID: KddpGFdaqEe
This improves the DisplayList Mutate Talos test by about 5% on windows, as well as numerous smaller improvements on DisplayList heavy tasks.
MozReview-Commit-ID: tlEtPjqWI4
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
With this change, we first generate a data file ServoCSSPropList.py from
Servo data, and then use this data to generate ServoCSSPropList.h.
This change itself serves as a checkpoint with a runtime check that all
information generated from Servo side matches what we have in the Gecko
side. Following patches will start replacing uses of nsCSSPropList.h
with either the data file or the header file.
The reason that it generates data file rather than header directly is
that, many users of PythonCSSProps.h invokes C++ preprocessor manually
to extract data from nsCSSPropList.h without passing in search paths,
so it is non-trivial to replace the use of nsCSSPropList.h there with
a generated header. Generating a Python data file would hopefully
simplify those users rather than adding more complexity to them.
I also thought about generating JSON rather than plain Python file, but
JSON doesn't allow trailing comma in array, which makes it less pretty
to generate via mako template.
MozReview-Commit-ID: CwK2oL88r6F
--HG--
extra : rebase_source : 926cca8548d42ecb0dd364ea5c52a46a4973e819
Move the assertion to the earliest point where it can happen instead, and do it
automatically on exit if it's generated content instead of relying on manual
calls.
MozReview-Commit-ID: 5oPwXg2o22V
This also adopts the resolution of [1] while at it, and switches XUL to not
support display: contents until a use case appears.
This makes our behavior consistent both with the spec and also in terms of
handling dynamic changes to stuff that would otherwise get suppressed.
Also makes us consistent with both Blink and WebKit in terms of computed style.
We were the only ones respecting "behaves as display: none" without actually
computing to display: none. Will file a spec issue to get that changed.
It also makes us match Blink and WebKit in terms of respecting display: contents
before other suppressions, see the reftest which I didn't write as a WPT
(because there's no spec supporting neither that or the opposite of what we do),
where a <g> element respects display: contents even though if it had any other
kind of display value we'd suppress the frame for it and all the descendants
since it's an SVG element in a non-SVG subtree.
Also, this removes the page-break bit from the display: contents loop, which I
think is harmless.
As long as the tests under style are based in namespace id / node name /
traversal parent, this should not make style sharing go wrong in any way, since
that's the first style sharing check we do at [2].
The general idea under this change is making all nodes with computed style of
display: contents actually honor it. Otherwise there's no way of making the
setup sound except re-introducing something similar to all the state tracking
removed in bug 1303605.
[1]: https://github.com/w3c/csswg-drafts/issues/2167
[2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700
MozReview-Commit-ID: JoCKnGYEleD
And fix a comment mentioning nsCSSSelectorList that I came across.
MozReview-Commit-ID: 1BOcDqV5dUr
--HG--
extra : rebase_source : 5fbdae6da74cf4fac145fbdd721723e81839e4b3
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly.
However, some web apps actually broken with the standardized behavior. For
protecting testers from known broken web apps, this patch introduces a
blacklist to take the traditional behavior under specific domain (and path in
it, optionally). Currently, docs.google.com and mail.google.com are set by
default.
MozReview-Commit-ID: HSrYX8LUB0p
--HG--
extra : rebase_source : a2677d07410af289534db051767543a25c9a957a
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
This brings us into alignment with the spec and makes us pass some web-platform
tests, along with the reftests that I've included for this bug.
MozReview-Commit-ID: KoKPi18svGE
--HG--
extra : rebase_source : f00dd814238afd4b09bdcb75b22ea249162252b8
This patch doesn't change behavior.
It simply makes us share code/data for two different cases that both ended up
producing mainAxisCoord->GetUnit() == eStyleUnit_Auto. Now, they'll *both* use
the same static nsStyleCoord to represent this "auto" value.
Originally, in one of these cases ("flex-basis:auto;[main-size-property]:auto),
we left the mainAxisCoord untouched. Now we'll point it at this dummy 'auto'
value. Either way we end up with mainAxisCoord->GetUnit() == eStyleUnit_Auto,
so the behavior doesn't change.
The next patch in this series will make further changes to one of these spots,
as noted in the "XXXdholbert" code-comment included here.
MozReview-Commit-ID: 5ClfbNHuKhO
--HG--
extra : rebase_source : 17efe1e9f721324d6182db654e601727c791800b
This patch's reftests already pass, regardless of whether we have this bug's
fix, because the max-content size in the block axis is the same as the "auto" size
(which is what we were already using in this scenario). I'm just adding these reftests
for symmetry & completeness.
MozReview-Commit-ID: EOlrpnCxoby
--HG--
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-003-ref.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-004-ref.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-003a.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-004a.html
rename : layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-003b.html => layout/reftests/w3c-css/submitted/flexbox/flexbox-flex-basis-content-004b.html
extra : rebase_source : 93942d169018276040ef60450c8f8b17c75e0d12
Note: These tests fail in current mozilla-central (and hence are marked as
failing), but they start passing as of a patch later on in this series.
MozReview-Commit-ID: ElWJCl1ki0H
--HG--
extra : rebase_source : a5bdb9afae0a3bb902834d07c4c22783c8904104
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
With this commit, all the auto-dir scrolling functionalities are completed in
APZ.
MozReview-Commit-ID: L7qa3xOD8t9
--HG--
extra : rebase_source : bad2770219a0e6219f91899ab6c78e68f37195ac
This was only recently made possible by webrender#2600, which introduced special stacking-context
clips
MozReview-Commit-ID: HQAU7IsfDaz
--HG--
extra : rebase_source : 0ac7f0f3f73abdf5b60ca02b37cfaa7abeecb6a3
This makes the optimization rarer, but is significantly simpler, since we should now be guaranteed that all placeholder frames have their out of flow frames in the same stacking context.
MozReview-Commit-ID: 1Nf8Sx1dca7
--HG--
extra : rebase_source : 74856420fdf6108fe749c94418a20bc9faa6fc5e
We already rebuild all display items for out-of-flow descendants of a modified frame, but we don't currently mark them modified.
In this case, a scrollframe becomes active, and causes position:fixed descendants to use nsDisplayFixedPosition instead of nsDisplayWrapList.
Not invalidating means that we end up with both versions, instead of removing the old one.
MozReview-Commit-ID: LXjjsQhzxiB
--HG--
extra : rebase_source : e286bad815f2d799ec641e5b2ef6507eb57d22cd
The test invalidates the z-index element, so that we do a partial build with just that and the DAG no longer knows the relative ordering between it and the other blue elements.
We then expand the size of the 'first' elements stacking context, and ensure that we provide enough intersecting items to know that we're on top of the z-index element.
MozReview-Commit-ID: 13aRGm1eucp
--HG--
extra : amend_source : 11d530fbec816b3dbcfa7228625e0ba0e73064d0
We already do this for the maybe-hit regions because on some pages we can get
oodles and oodles of regions and unioning them all takes a long time.
Simplifying the regions speeds this up massively. It should be functionally
correct since the dispatch-to-content region is allowed to overestimate the
actual dispatch-to-content region.
MozReview-Commit-ID: 6Wl5nuVXB7w
--HG--
extra : rebase_source : 6067ae048435421918c6ab1de225140e77ae9484
After bug 1303605 we can assert this, since we make sure all children have the
same flattened tree parent, and thus insertion point.
MozReview-Commit-ID: 7AHuGGw2uJI
Animation::FlushStyle() gets called only for CSS animations/transitions'
playState changes in JS or ready Promise for CSS animations. In either case
throttled animation state, which is, to be precise, transformed position or
opacity value on the compositor, doesn't affect those results.
The first test case for CSS animations and the first test case for CSS
transitions in this patch fail without this fix.
MozReview-Commit-ID: EVym4qputL4
--HG--
extra : rebase_source : 12524c7db1d59da69687bb123fc65ad4301f5527
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
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
For the promise as returned by "OS.File.read()" the catch handler
is missing, and as such the tests will never be started when
the call to "read()" triggers an exception. It also results in
a hang of the reftest harness.
To prevent this, the failure has to be handled and appropriately
reported.
MozReview-Commit-ID: IX9thgjjahS
--HG--
extra : rebase_source : 963cd0aeb593b7627603566d1ad08d5e0863142f
Switching from {get|set}CharPref to {get|set}StringPref allows
the reftest extension to also support preferences with Unicode
strings.
MozReview-Commit-ID: FUBjhmr0VIS
--HG--
extra : rebase_source : 53e1a020f8e2875c35ce1dfc06aff41ea18ce127
Removes the following deprecated WebDriver commands from marionette
client: Element.size, Element.location, set_script_timeout,
set_search_timeout, and set_page_load_timeout.
It doesn't touch get_window_position, set_window_position,
window_size, and set_window_size because those are covered
by bug 1348145.
MozReview-Commit-ID: 9b74toO1Rzm
--HG--
extra : rebase_source : a9a73cf8cc36ed3d428ce1c7c54b83b9f0f4a63c
This is needed only for CSS Grid since in other cases we're
only using IntrinsicISizeOffsets in the inline-axis and
the percentage basis is always indefinite for *intrinsic
sizing*. When calculating the intrinsic size of grid items
in the grid container's block axis however, we do have
a definite size for the grid area in the inline-axis and it
should be used per:
https://drafts.csswg.org/css-grid/#algo-overview
"2. Next, the track sizing algorithm resolves the sizes of
the grid rows, using the grid column sizes calculated in
the previous step."
(Percentage padding/margin for grid items is always resolved
against the grid area's inline-size nowadays.)
And make nsIFrame its only caller, modulo a safety assertion.
The safety assertion will be removed at the same time as the pres context
member, since the only purpose of it is to ensure we don't keep a pres context
reference for too long.
MozReview-Commit-ID: CD5zOHVO9ub
And make nsIFrame its only caller, modulo a safety assertion.
The safety assertion will be removed at the same time as the pres context
member, since the only purpose of it is to ensure we don't keep a pres context
reference for too long.
MozReview-Commit-ID: CD5zOHVO9ub
Mostly removing some unneeded tags (<meta name=flags> is no longer needed, and
tagging it "dom" didn't seem appropriate to me). Also adding some tags that
match the WPT test template (charset / titles mostly). Also using consistent
indentation.
Finally, adding the needed
<link rel="match">
tags so that the exported tests work correctly upstream.
MozReview-Commit-ID: Lt83JmJE4pO
Much in the spirit of bug 1442207.
They're not only unneeded, and cheap to get, but also we call them
inconsistently with the light DOM and flattened tree parent (like ContentRemoved
for display: contents), so they're really confusing, and kind of a footgun.
MozReview-Commit-ID: 9u3Kp8Kpp5i
The code was trying to assert that we had frames constructed for all the nodes
in the parent chain, but we don't bail out in the
!GetContentInsertionFrameFor(aContainer) in the case that it's a children
element, because they actually have no insertion frame, though their children
do.
Move the LazyFC check after the insertion point check. That makes the previous
check work on the insertion point of the child, which makes it sound.
This also fixes bug 1410020, and with it a Shadow DOM test-case that was failing
because we had two sibling assigned to two different <slot>s, and the second one
wasn't getting properly flagged, and thus the second sibling never got a frame.
The other two test failures in this test are an event dispatch failure, where
the position of the target is not what the test expects (we don't account for
margin and padding). Filed that as bug 1450027.
Also, added a test for which we have wrong layout without these patches, and
that crashes with "Called Servo_Element_IsDisplayNone" with the first patch of
this bug applied but not this one, due to the bogus check mentioned above.
MozReview-Commit-ID: 6OeaVrZhTDv
This is mostly code removal, changing GetDisplayContentsStyle(..) checks by an
FFI call to Servo.
The tricky parts are:
* MaybeCreateLazily, which I fixed to avoid setting bits under display: none
stuff. This was a pre-existing problem, which was wallpapered by the
sc->IsInDisplayNoneSubtree() check, which effectively made the whole
assertion useless (see bug 1381017 for the only crashtest that hit this
though).
* ContentRemoved, where we can no longer know for sure whether the element is
actually display: contents if we're removing it as a response to a style
change. See the comment there. That kinda sucks, but that case is relatively
weird, and it's better than adding tons of complexity to handle that.
* GetParentComputedStyle, which also has a comment there. Also, this function
has only one caller now, so we should maybe try to remove it.
The different assertions after DestroyFramesForAndRestyle are changed for a
single assertion in the function itself, and the node bit used as an
optimization to avoid hashtable lookups is taken back.
MozReview-Commit-ID: AZm822QnhF9
Tag is unused.
This changes how some mixes of MathML and html get wrapped in anonymous table
boxes (in particular, it changes whether it uses a MathML or an HTML table
frame). The main thing this affects is whether the frame responds to certain
attributes. Responding to mathml attributes on its mContent when that mContent
is not a MathML element is weird. So arguably this is also more correct.
However, that seems acceptable to me, and you can already get that mixing
manually. On a few (arguably simple) manual test-cases mixing MathML and HTML
tables I couldn't manage to get the patched build to render differently.
Plus, neither our reftests nor the WPT MathML test-suite upstreamed by Fred Wang
for WebKit rely on this.
MozReview-Commit-ID: 8IV3iF5xIs0
This covers all the reftests that have lower fuzz (or zero fuzz) and
were producing an UNEXPECTED-PASS result with webrender on windows. In
many cases I just adjusted the lower bound of the existing webrender
fuzz. In other cases existing fails-if conditions had to be tweaked to
exclude webrender.
MozReview-Commit-ID: 49LvS0vuYWR
--HG--
extra : rebase_source : d194e24affb87fe4560a127ff4016f9c38f414fd
Many of these could probably be fuzzed but in the interests of getting
the reftest suite turned on sooner I'm doing a blanket fails-if. This
covers all the reftests where there is more fuzz with webrender on
windows than any of existing annotations account for. In some cases the
fuzz is only a few pixels more than the equivalent Linux fuzz already
annotated, but I'll clean that up in a future bug.
MozReview-Commit-ID: IaKarbnL46d
--HG--
extra : rebase_source : 71889340305b0b12fa8eace722e42bb3faf14419
This test started failing after a reftest rebucketing. It's likely a
particularly-bad special case of known win7 intermittent bug 1392106. For now,
let's mark it as random on Win7 and continue investigating the general issue in
bug 1392106.
MozReview-Commit-ID: KX707Y9ycIC
Cosmin Sabou
Kartikaya Gupta
Jason Kratzer
Brad Werth
Narcis Beleuzu
Andreea Pavel
Daniel Holbert
Bobby Holley
Bas Schouten
Xidorn Quan
Jonathan Kew
Emilio Cobos Álvarez
Kevin Brosnan
Brindusan Cristian
Jeff Muizelaar
shindli
Joel Maher
Ryan VanderMeulen
Boris Zbarsky
Narcis Beleuzu
Csoregi Natalia
Kris Maglione
Jeff Walden
Cameron McCormack
Masayuki Nakano
Andrew McCreight
Jonathan Watt
arthur.iakab
Sebastian Hengst
Dão Gottwald
Jamie Nicol
Miko Mynttinen
Nicholas Nethercote
Geoff Brown
Zhang Junzhi
Alexis Beingessner
Matt Woodrow
Kerem Kat
Coroiu Cristina
Daniel Zielas
Hiroyuki Ikezoe
Noemi Erli
Ciure Andrei
Bob Clary
Tristan Bourvon
Nika Layzell
Henrik Skupin
Mats Palmgren
Prathiksha
L. David Baron
Adrian Wielgosik
Andrew Halberstadt
Ben Kelly
Lee Salzman