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
