D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
ScrollToShowRect calls nsIScrollableFrame::ScrollTo with an nsRange which
will be used to constrain the final scroll position so that if snapping needs
to happen we need to ignore the given range not to constrain the final
destination position in the range.
Differential Revision: https://phabricator.services.mozilla.com/D31948
--HG--
extra : moz-landing-system : lando
I think these should hold, everything that runs under them should just schedule
other stuff to some later date:
* Synth mouse events -> scheduled as refresh driver observers.
* Scroll events -> Scheduled as well.
* Caret state change events -> Also scheduled after last patch.
* IME and accessibility stuff -> I don't think they can reenter layout.
We can always revert this if it causes troubles, plus it shouldn't crash on
release so should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D31090
--HG--
extra : moz-landing-system : lando
Instead, post the event for the next turn of the event loop.
In this case, what killed the frame is ActionBarHandler.jsm via
Selection.toString().
Depends on D31088
Differential Revision: https://phabricator.services.mozilla.com/D31089
--HG--
extra : moz-landing-system : lando
ScrollToShowRect calls nsIScrollableFrame::ScrollTo with an nsRange which
will be used to constrain the final scroll position so that if snapping needs
to happen we need to ignore the given range not to constrain the final
destination position in the range.
Differential Revision: https://phabricator.services.mozilla.com/D31948
--HG--
extra : moz-landing-system : lando
The relevant definition in the spec;
https://drafts.csswg.org/css-device-adapt/#min-scale-max-scale
Before this change, if both of initial-scale and maximum-scale are negative,
both values are clamped to 0.25. Whereas with this change, negative scale
values are treated as if it's not specified so that initial-scale value is
automatically calculated based on the layout viewport size.
negative-initial-and-maximum-scale.html is a test case for the case.
Also with this change, initial-scale values are going to be clamped to the
range [0.25, 10] during parsing it so that initial-scale-0.html and
initial-scale-100.html need to be modified, now the former is scaled by 0.25x,
the latter is scaled by 10x.
(Before this change, initial-scale=0 and initial-scale=100 were treated as
invalid scale values in nsViewportInfo::ConstrainViewportValues[1])
[1] https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/dom/base/nsViewportInfo.cpp#15,19
Differential Revision: https://phabricator.services.mozilla.com/D32098
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This patch contains two isolated changes related to upcoming picture
caching improvements. Specifically:
* Determine the blit reason for stacking contexts with clips
earlier, during scene building. This simplifies the code and
allows better detection of redundant stacking contexts.
* Centralize the code for pushing batch instances into a small
number of places. This will simplify the switch to adding
a single primitive to multiple batch lists, in the case of
dirty regions with different batchers.
Differential Revision: https://phabricator.services.mozilla.com/D31898
--HG--
extra : moz-landing-system : lando
ScrollToShowRect already considers that possibility, so not doing it on the
caller is a bug.
Ideally scroll observers shouldn't be able to run script, more to that in a
second.
Differential Revision: https://phabricator.services.mozilla.com/D31088
--HG--
extra : moz-landing-system : lando
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
--HG--
extra : moz-landing-system : lando
This is primarily to fix sizing of 'box-decoration-break:clone' inlines,
but also some 'slice' edge cases by recognizing more break opportunities,
and to improve sizing when BIDI-continuations are involved.
Differential Revision: https://phabricator.services.mozilla.com/D32915
--HG--
extra : rebase_source : 45a76e55e3eb5ac41fd60b11eb2acce24c6a1dd1
extra : amend_source : d8980854573522ddf761f0cf036aaa4ee0d96cac
It was introduced in bug 1352096 to reduce complexity with Stylo (apparently).
Right now it doesn't look like it reduces any complexity, and it's a bit
annoying with some of the patches that I'm writing at the moment.
So unless there's any objection I think it should go away.
Differential Revision: https://phabricator.services.mozilla.com/D31708
--HG--
extra : moz-landing-system : lando
This will save us some time from figuring out what's the best thing to do in
bug 1552587, so that other patches I have in flight (mainly bug 1552708) can
land, since we cannot add a single byte to nsStyleDisplay right now otherwise.
The code removed here is well isolated and not that complicated, so it seems to
me that should be easy to bring back should we have an emergency (and I commit
to doing that while preserving the nsStyleDisplay size limit if we need to :)).
Differential Revision: https://phabricator.services.mozilla.com/D32026
--HG--
extra : moz-landing-system : lando
We need to notify the whole parent chain (using NOTIFY) rather than just
mStyleSets, since mStyleSets is empty for @import-ed sheets.
Differential Revision: https://phabricator.services.mozilla.com/D31787
--HG--
extra : moz-landing-system : lando
This code contains an undesirable dependency between the layout code and
the implementation of toolbarbutton. Since it isn't actually used anywhere
by the firefox UI, remove it here.
Differential Revision: https://phabricator.services.mozilla.com/D31939
--HG--
extra : moz-landing-system : lando
I did this instead of just (ab)using the fact that every list item has at least
one counter-increment node because:
* I don't have the bullet frame around by the time we initially compute the
counter increment, which means that I'd need to grow nsBlockFrame / add a
frame property for the list item ordinal, which I think would be unfortunate.
* It feels more consistent with the way regular CSS counters work and with the
way we want ::marker to eventually work.
Differential Revision: https://phabricator.services.mozilla.com/D31990
--HG--
extra : moz-landing-system : lando
When you have a ::after::marker, and you compare one against the other we ended
up with the wrong result because of the pseudotype stuff.
I think this is cleaner now that DoCompareTreePosition handles pseudos properly
(which is really the thing this was working around).
Differential Revision: https://phabricator.services.mozilla.com/D31989
--HG--
extra : moz-landing-system : lando
I'm going to need it to fix the counters code in presence of nested
pseudo-elements.
Differential Revision: https://phabricator.services.mozilla.com/D31988
--HG--
extra : moz-landing-system : lando
I thought I was going to need it but turns out I don't. Still this is worth it I
think.
Differential Revision: https://phabricator.services.mozilla.com/D31987
--HG--
extra : moz-landing-system : lando
We don't store post-transform overflow areas for frames within preserve-3d, but we do store pre-transform overflow areas.
Rather than just recomputing the changed overflow for the root, we should recompute overflows for all ancestors up to the 3d root.
Differential Revision: https://phabricator.services.mozilla.com/D31213
--HG--
extra : moz-landing-system : lando
Should also update layout code for foreignObject to use CSS geometry property.
Differential Revision: https://phabricator.services.mozilla.com/D30806
--HG--
extra : moz-landing-system : lando
When animating geometry attribute, we need to notify style system about the change of SMIL override style.
Differential Revision: https://phabricator.services.mozilla.com/D30361
--HG--
extra : moz-landing-system : lando
We cached the path of an element. Previously we only need to invalidate
the cached path if an geometry attribute is changed. Now we also need
to invalidate if the corresponding CSS is changed.
Differential Revision: https://phabricator.services.mozilla.com/D30472
--HG--
extra : moz-landing-system : lando
This patch adds SVG geometry properties to CSS, it doesn't deal with
how SVG handles them.
Differential Revision: https://phabricator.services.mozilla.com/D29937
--HG--
extra : moz-landing-system : lando
According to the procedure to update animations and send events[1] the UA should
update all timelines first and _then_ run a microtask checkpoint.
As a result, when we run callbacks for the finished promise on an Animation they
should see the fully up-to-date state of all animations, regardless of which
timeline they are attached to.
However, that is currently not the case since we run a microtask checkpoint
after updating each individual timeline.
This difference will become more significant later in this patch series when we
introduce another step--removing replaced animations--that _also_ should happen
before we run the microtask checkpoint (so that the promise callbacks always see
a fully-up-to-date state).
This patch makes our handling a little more in line with the spec. It's not
quite the same because it's possible there may be other refresh driver observers
that trigger a microtask checkpoint in between ticking the different timelines
but that case is expected to be rare and fixing it would require maintaining
a separate queue for timeline observers that we run after all other observers--
so it is probably not necessary to fix that case at this stage.
The test added in this patch fails without the code changes in this patch.
[1] https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events
Differential Revision: https://phabricator.services.mozilla.com/D30319
--HG--
extra : moz-landing-system : lando
Unpack StyleMotion and move its members into nsStyleDisplay, use
cbindgen to generate StyleOffsetPath.
Differential Revision: https://phabricator.services.mozilla.com/D31164
--HG--
extra : moz-landing-system : lando
In order to use cbindgen for offset-path and add offset-distance in the
following patches, we need to repack nsStyleDisplay to make sure
nsStyleDisplay doesn't exceeds 512 bytes. (Actually, we still use 504
bytes after applying the following patch series.)
Note:
1. Use cbindgen for offset-path (i.e. StyleOffsetPath): the size becomes
16 bytes. (The original size of UniquePtr<...> is 8 bytes.)
2. Add offset-distance: the size of LengthPercentage is 12 bytes.
Differential Revision: https://phabricator.services.mozilla.com/D31869
--HG--
extra : moz-landing-system : lando
This is the main performance improvement, and means that we no longer have to iterate all the cells for each column.
It has a couple of behaviour changes:
The first is that we no longer apply stacking context effects (like opacity) to column and column group backgrounds.
I believe this is correct as per both CSS2.1 Appendix E, and css-tables-3 (quoted in nsTableColFrame::BuildDisplayList).
This matches the behaviour of blink and WebKit.
We also previously created items in column,row ordering, whereas now they will be in row,column. In cases where two cells
overlap (using rowspan and colspan to extend multiple neighbours in to the same place) this can render backgrounds in a
different order, but the new behaviour matches blink and WebKit.
Differential Revision: https://phabricator.services.mozilla.com/D29280
--HG--
extra : moz-landing-system : lando
This helps for the next patch, since some of the table backgrounds items want to compute this without position:relative taken into account.
Differential Revision: https://phabricator.services.mozilla.com/D29279
--HG--
extra : moz-landing-system : lando
This also changes behaviour a bit, previously we interleaved column and column group backgrounds. where we now put all the column group backgrounds behind all columns.
I believe this is the correct ordering as per CSS2.2 Appendix E.
Column backgrounds can overlap when using 'span', and we now render this in a different order, but this matches what other browsers do.
Differential Revision: https://phabricator.services.mozilla.com/D29278
--HG--
extra : moz-landing-system : lando
This is a behaviour change, but I believe it matches the quoted spec text, and neither blink nor WebKit render these.
Differential Revision: https://phabricator.services.mozilla.com/D29276
--HG--
extra : moz-landing-system : lando
Most of the code in DisplayGenericTablePart was all within a per-class if statement, so it doesn't add much value, and makes the control flow harder to understand.
Differential Revision: https://phabricator.services.mozilla.com/D29273
--HG--
extra : moz-landing-system : lando
Note that the "loose | normal | strict" values are not yet parsed/implemented.
Differential Revision: https://phabricator.services.mozilla.com/D29817
--HG--
extra : moz-landing-system : lando
This stops nsPrintJob::PrintPreview from duplicating work done in
nsDocumentViewer::PrintPreview.
Differential Revision: https://phabricator.services.mozilla.com/D31811
--HG--
extra : rebase_source : 062cbac323a2a1a0bcc85039b3671c650c408efa
extra : amend_source : 39d5b8c316f518aa72d560ae4eeec171561ab8fd
Filters blur(), invert(), etc. can omit argument.
Computed/specified style serialization is a little tricky w.r.t the shortest
serialization principle. Ideally we should serialize `invert(1)` to `invert()`,
but that will be a breaking change, so we always serialize them with an
argument.
Note, Blink/WetKit treat specified (but not computed) style serialization
differently when the specified one is originally without argument. Our
current behavior is the same as pre-Chromium Edge.
Differential Revision: https://phabricator.services.mozilla.com/D31720
--HG--
extra : moz-landing-system : lando
Most of it is not used at this point, this leaves the parts that are used by
MathML, which are minimal.
Differential Revision: https://phabricator.services.mozilla.com/D31706
--HG--
extra : moz-landing-system : lando
In RTL scroll containers, the right most x-axis scroll position is 0 and
leftward scroll positions are negative values. And also
nsLayoutUtils::TransformFrameRectToAncestor, which is used to tell whether the
snap target element is inside the destination snapport or not [1], returns
negative x-axis positions for elements in RTL scroll containers if the element
is positioned at places where the elements are outside of the initial scroll
position (0, 0). So we don't need to tweak snapport postion even in the case
of RTL scroll containers.
Instead, what we needed in the first place is that we choose a proper x-axis
scroll position that the targe element appears inside the snapport.
[1] https://searchfox.org/mozilla-central/rev/11cfa0462a6b5d8c5e2111b8cfddcf78098f0141/layout/generic/nsGfxScrollFrame.cpp#6604-6605,6616-6617
Depends on D31409
Differential Revision: https://phabricator.services.mozilla.com/D31410
--HG--
extra : moz-landing-system : lando
In bug 1527182 we made it so that APZ can directly drag-scroll scrollframes
that are inside SVG effects, because that's possible with WR on the compositor.
However the code changed in that bug was meant to be kept in sync with
a second piece of code. The second piece of code controls the generation
of ScrollInfo items for scrollframes inside SVG effects - since we can
APZ-scroll them with WR, we don't need the scrollinfo item anymore.
Producing the scrollinfo item was changing the structure of the APZ tree
in terms of where the transform ended up, and was causing badness with
untransforming the drag mouse events.
This patch adds a test that covers the scenario and also corrects the defect
by bringing the two bits of code back in sync.
Differential Revision: https://phabricator.services.mozilla.com/D31647
--HG--
extra : moz-landing-system : lando
Even if we do nothing, we need to know if the value actually changed to see if
we need to propagate it to descendants that explicitly inherit it.
Differential Revision: https://phabricator.services.mozilla.com//D31569
Depends on D31568
It was missing the cases where you changed values, but not count, and the image
was not visible, like:
mask-image: none;
mask-mode: match-source, match-source;
Then change mask-mode to `match-source, alpha`, for example.
Differential Revision: https://phabricator.services.mozilla.com//D31568
Because it states more clearly what the functions and the constant are
about.
Differential Revision: https://phabricator.services.mozilla.com/D31615
--HG--
extra : moz-landing-system : lando
This happens in one test on try server that has some iframes that navigate.
I audited everywhere else that we change the view tree, this seems like the only place it can happen.
Differential Revision: https://phabricator.services.mozilla.com/D31399
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
--HG--
extra : moz-landing-system : lando
We could use ArcSlice if wanted I guess, your call. Though will change is not
supposed to be used very frequently.
Differential Revision: https://phabricator.services.mozilla.com/D30548
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
Please advise if there is a better alternative. After ensuring that
extension popups are wired up to create an nsDisplayRenderRoot, the
bottom bit of the popup's content is cut off. This fixes that issue,
but I'm not certain if it is the most robust option.
Differential Revision: https://phabricator.services.mozilla.com/D31007
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
This happens in one test on try server that has some iframes that navigate.
I audited everywhere else that we change the view tree, this seems like the only place it can happen.
Differential Revision: https://phabricator.services.mozilla.com/D31399
--HG--
extra : moz-landing-system : lando
Should also update layout code for foreignObject to use CSS geometry property.
Differential Revision: https://phabricator.services.mozilla.com/D30806
--HG--
extra : moz-landing-system : lando
When animating geometry attribute, we need to notify style system about the change of SMIL override style.
Differential Revision: https://phabricator.services.mozilla.com/D30361
--HG--
extra : moz-landing-system : lando
We cached the path of an element. Previously we only need to invalidate
the cached path if an geometry attribute is changed. Now we also need
to invalidate if the corresponding CSS is changed.
Differential Revision: https://phabricator.services.mozilla.com/D30472
--HG--
extra : moz-landing-system : lando
This patch adds SVG geometry properties to CSS, it doesn't deal with
how SVG handles them.
Differential Revision: https://phabricator.services.mozilla.com/D29937
--HG--
extra : moz-landing-system : lando
Logcat is available as a separate artifact anyway. This makes the test log
for successful runs much smaller: easier to read, cheaper to store.
Differential Revision: https://phabricator.services.mozilla.com/D31357
--HG--
extra : moz-landing-system : lando
We destroy them manually, so it's the right thing to do.
This allows us to not run destructors of any members of nsStyle*, which in turn allows us to:
* Remove the hack that replaced all nsStrings for nsStringReprs.
* Remove ns{,C}StringRepr (followup)
* Add members with destructors to the style structs (you see where I'm going :)).
Differential Revision: https://phabricator.services.mozilla.com/D30450
--HG--
extra : moz-landing-system : lando
We destroy them manually, so it's the right thing to do.
This allows us to not run destructors of any members of nsStyle*, which in turn allows us to:
* Remove the hack that replaced all nsStrings for nsStringReprs.
* Remove ns{,C}StringRepr (followup)
* Add members with destructors to the style structs (you see where I'm going :)).
Differential Revision: https://phabricator.services.mozilla.com/D30450
--HG--
extra : moz-landing-system : lando
However, we continue to only respect a <meta name="viewport"> tag if
dom.meta-viewport.enabled is set.
Differential Revision: https://phabricator.services.mozilla.com/D30988
--HG--
extra : moz-landing-system : lando
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
This affects a number of our existing reftests, so we'll need to update those
to not expect auto-hyphenation of a sentence-initial (capitalized) word.
(Hyphenation behavior is not sufficiently well-specified for this to be tested
at the WPT level, so we just use Gecko-specific reftests.)
Differential Revision: https://phabricator.services.mozilla.com/D30912
--HG--
extra : moz-landing-system : lando
That being said, this code is clearly not getting hit, are we 100% sure that
this is interoperable with what WebKit / Blink do?
Differential Revision: https://phabricator.services.mozilla.com/D30830
--HG--
extra : moz-landing-system : lando
The spec says that when there's no box or the property doesn't apply, the
computed value should be returned.
That's not what we're doing right now, we're clamping by min-/max- values, which
is wrong.
This patch makes us match other engines and the spec, and it's an attempt to get
interop on resolved values in:
https://github.com/w3c/csswg-drafts/issues/3678
WebKit fails the WPT test, but due to a different reason:
https://bugs.webkit.org/show_bug.cgi?id=197814
Differential Revision: https://phabricator.services.mozilla.com/D30780
--HG--
extra : moz-landing-system : lando
CSS containment is enabled on early beta or earlier. Using
"default-preferences" to flip column-span pref overrides CSS
containment's pref at the first line in the reftest.list, which make the
two test fail on late beta.
Differential Revision: https://phabricator.services.mozilla.com/D30674
--HG--
extra : moz-landing-system : lando
GetAvailableSpace was renamed to GetFloatAvailableSpace in bug 25888.
DONTBUILD because this is a comment-only change.
Differential Revision: https://phabricator.services.mozilla.com/D30581
--HG--
extra : moz-landing-system : lando
There are three test cases;
1) Two iframes are swapped
2) Changing the visibility of the parent document doesn't clobber a child
document's visibility in the case where the child document has been hidden
by another element in the parent document
3) an iframe is initially inside a visibility:hidden element in the parent
document
Depends on D26253
Differential Revision: https://phabricator.services.mozilla.com/D27842
--HG--
extra : moz-landing-system : lando
multicol-span-000.xht passes because the id in
<div id="column-span">123456</div>
was incorrect replaced by "-moz-column-span". Strip the "-moz" prefix
fixed it.
Except failures.list, other files were modified mechanically by running
import-tests.py against https://github.com/web-platform-tests/wpt commit
15f199c91a72b0d51bf0a12b3b77827ecb5051ff (the same commit in
received/import.log).
Differential Revision: https://phabricator.services.mozilla.com/D30406
--HG--
extra : moz-landing-system : lando
Also, build gPrefixRegexp and replace lines only if gPrefixedProperties
is non-empty. Otherwise, the import tests are messed up due to bogus
gPrefixRegexp.
Differential Revision: https://phabricator.services.mozilla.com/D30405
--HG--
extra : moz-landing-system : lando
As I said over bug 1549593, the eventual goal is to use ArcSlice in all
inherited properties. But this seemed like a good first candidate that doesn't
require me to move around a lot more code, since we were already using cbindgen
for the path commands.
Differential Revision: https://phabricator.services.mozilla.com/D30134
--HG--
extra : moz-landing-system : lando
This enables destructors for tagged unions in cbindgen, implemented in:
* https://github.com/eqrion/cbindgen/pull/333
Which allow us to properly generate a destructor for the cbindgen-generated
StyleBasicShape (which now contains an OwnedSlice).
For now, we still use the glue code to go from Box<BasicShape> to
UniquePtr<BasicShape>. But that will change in the future when we generate even
more stuff and remove all the glue.
I could add support for copy-constructor generation to cbindgen for tagged
enums, but I'm not sure if it'll end up being needed, and copy-constructing
unions in C++ is always very tricky.
Differential Revision: https://phabricator.services.mozilla.com/D29769
--HG--
extra : moz-landing-system : lando
It's not worth dying on this hill. Both Blink and WebKit pass the tests.
(Well, WebKit actually fails one of the latest ones I wrote, cssRules and rules
are not the same JS object, WebKit returns a new rule list. I'll file)
Spec PR in https://github.com/w3c/csswg-drafts/pull/3900.
Differential Revision: https://phabricator.services.mozilla.com/D30348
--HG--
extra : moz-landing-system : lando
This is in preparation to disable (but not remove) support for these customizations
by default. We want to avoid scanning for these files on start-up, but also don't want
to make our users jump through a pref-flipping hoop to get their customizations back.
So we'll detect those files and flip the pref for this release. For the next release,
we'll not load those files unless the pref is flipped.
Differential Revision: https://phabricator.services.mozilla.com/D30414
--HG--
extra : moz-landing-system : lando
Before this change, only elements inside the shadow root tree were scanned for the
draggable=true attribute. We now check the flattened tree instead so an element
inside a shadow root can start a drag for an element containing the shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D30365
--HG--
extra : moz-landing-system : lando
The patch in bug 1507744 was not sufficient by itself, as the line-breaker could still accumulate a single "current word" across a text-run boundary, and then a single word-break value would be applied to it. We need to flush the line-breaker when word-break changes, so that each part of the word will have break opportunities set according to the appropriate value.
Differential Revision: https://phabricator.services.mozilla.com/D30260
--HG--
extra : moz-landing-system : lando
Move ApplyOpacity(), CanApplyOpacity(), Paint() and PaintWithClip() methods to nsPaintedDisplayItem
Differential Revision: https://phabricator.services.mozilla.com/D30225
--HG--
extra : moz-landing-system : lando
Add multicol-width-004.html and multicol-width-005.html to test "width:
min-content" and "width: max-content" with column-span:all children.
There's no size containment in these tests.
Note it may be worth to reuse nsBlockFrame's mCachedMinISize and
mCachedPrefISize to cache intrinsic size for ColumnSetWrapperFrame, but
this can be done separately.
Differential Revision: https://phabricator.services.mozilla.com/D29616
--HG--
extra : moz-landing-system : lando
If column-span is enabled, nsColumnSetFrame becomes an inner frame under
ColumnSetWrapperFrame, and that outer frame is then where we should be
handling size containment.
This patch doesn't change the logic but make the logic easier to
simplify once we start eliminating column-span pref.
Differential Revision: https://phabricator.services.mozilla.com/D29615
--HG--
extra : moz-landing-system : lando
The functions move to ColumnUtils will be used by ColumnSetWrapperFrame
to implement GetPrefISize() and GetMinISize().
Also, I verify locally that non-unified build is still working by
s/UNIFIED_SOURCES/SOURCES/ in layout/generic/moz.build.
Differential Revision: https://phabricator.services.mozilla.com/D29614
--HG--
extra : moz-landing-system : lando
ColumnSetFrame always tries to reflow column content regardless of it's
dirtiness. Making ColumnSetWrapperFrame's children dirty can have the
same effect.
Differential Revision: https://phabricator.services.mozilla.com/D29435
--HG--
extra : moz-landing-system : lando
Per bug 1487927, margin-bottom value is not always rendered as expected
with our column balancing algorithm. I'd like to remove it from
column-balancing-nested-001.html, and add <br> to separate each cases.
Differential Revision: https://phabricator.services.mozilla.com/D30287
--HG--
extra : moz-landing-system : lando
We use `columnCount == aConfig.mBalanceColCount - 1` in other places to
determine if we are at the last column. Advancing the column count at
the end of the loop make the condition consistent.
Differential Revision: https://phabricator.services.mozilla.com/D29433
--HG--
extra : moz-landing-system : lando