In while-loop [1],
1. The first SetMatrix call that I remvoed in this patch is totally useless,
we can just pass initialMatrix to contextPaint, instead of set initialMatrix
to aContenxt and read back from aContext and then pass it to contextPaint.
2. This function, SVGTextFrame::PaintSVG, is the only caller of
SetupStrokeGeometry, and it does not need SetupStrokeGeometry to setup matrix at
all, since it will be overwritten the transform matrix of aContext at several
lines below[2].
[1]
https://hg.mozilla.org/mozilla-central/file/5115e2dea29a/layout/svg/SVGTextFrame.cpp#l3658
[2]
https://hg.mozilla.org/mozilla-central/file/5115e2dea29a/layout/svg/SVGTextFrame.cpp#l3685
MozReview-Commit-ID: AlKQh4abbpa
--HG--
extra : rebase_source : e0dfd66ff25be0d7cffadecf9e3333bba10cff9b
(This patch is not relative to performance)
Rename this function since it has not relation with cario at all.
MozReview-Commit-ID: DHvrsVZAJ7B
--HG--
extra : rebase_source : 4994c9058bd93c7d6671e57ce7f204185e679a1a
Unless we need to draw stroke of glyphs, which will change the state of the
target context, we only need to save & restore transform matrix of the target
context.
MozReview-Commit-ID: LLKnxrKrDaT
--HG--
extra : rebase_source : 1226c48d283a04cb0ea6959f12fd6938fece49d2
nsDisplaySVGText::Paint calls SVGTextFrame::PaintSVG, and we already save/restore
context state in SVGTextFrame::PaintSVG.
I also filed Bug 1385929 to find a solution to prevent duplicated
gfxContext::Save/Restore.
MozReview-Commit-ID: 4WxdFZzvmvF
--HG--
extra : rebase_source : 752d5d027776538edc1ab043ad2e90e1de22a079
We have to set mHaveNonAnimationRestyles if we have attributes changed
(note: we increase the animation generation only if mHaveNonAnimationRestyles
is set). Attributes changed may create a new transition, and we use the
animation generation as the order of the transition, so
Element::GetAnimations() can return transitions with correct order.
Besides, I think ContentStateChanged() will not trigger a new
transition, so we don't need to make mHaveNonAnimationRestyles there.
MozReview-Commit-ID: J5XgW8nqeLH
--HG--
extra : rebase_source : 24c4b4364935fc5a4b8437f119cbf93035262684
The patch provides FFI access to Gecko's SeenPtrs type from Rust, in order to
record what has already been measured when measuring Arcs. (The SeenPtrs must
be initialized on the Gecko side because the same table is reused for measuring
all Elements within a window, because Elements can share ComputedValues.) I
have confirmed with DMD that this is working correctly.
The patch also introduces MallocSizeOfRepeats, which is like MallocSizeOf but
takes a SizeOfState, which holds a SeenPtrs table.
MozReview-Commit-ID: DHS8zvCsEdQ
--HG--
extra : rebase_source : acf4d7909abf6ceb1719331ccf2e33137eb6dc91
When display style is changed from 'none' to other in animation-only restyle
we need to resolve descendant elements' style that were in the display:none
subtree.
Three possible ways to resolve the descendant elements' style;
1) Traversing unstyled elements in animation-only restyle
We can't simply traverse unstyled elements in the animation-only restyle
since when we decided to traverse the unstyled elements we don't know yet
the elements will be initially styled or are in display:none subtree. It
will result that the new elements are styled in animation-only restyle,
it's undesirable.
2) Creating a SequentialTask and resolve the descendants' style with
ServoStyleSet::StyleNewSubtree()
We can't resolve the descendants' styles with ServoStyleSet::StyleNewSubtree()
in SequentialTask since at the moment we are still in servo traversal (i.e.
sInServoTraversal is true). That means AutoSetInServoTraversal fails
in PrepareAndTraverseSubtree().
3) Creating a SequentialTask and set restyle subtree hint and defer descendants'
restyle in a subsequent normal traversal
Note that, when we process throttled animations flush, we don't process
normal traversal so the descendants will not be traversed until normal
restyle happens but it will not be a big problem since it's really rare
that user clicks display animation element just at the right moment when
display property changes from none to other. Also, if it will be really
a problem, we should process *only* transform animations on the compositor,
it's ideally right thing to do. Display property never runs on the
compositor.
This patch takes the third approach.
MozReview-Commit-ID: Krxa3kkdIq4
--HG--
extra : rebase_source : 33e9db953f21168c76716329568191625bd15896
When a container layer's transform has an animated scale, we clamp it
to a near power of two so that descendent layers' resolutions do not
keep changing and we minimize repainting. The current behaviour only
clamps the scale when it has not changed with respect to the previous
transaction. In animations where the scale usually changes, but
happens to remain constant between two consecutive transactions, this
is bad.
Rather than only checking against the previous scale value, use
ActiveLayerTracker::IsScaleSubjectToAnimation() to determine whether
to clamp, as it takes into account a longer period.
--HG--
extra : rebase_source : 6bc773e387c5750746722d4a0cc5864ebf7757e2
This used to be necessary when larger/smaller did a table lookup.
However as of bug 1361550 these are simple ratios and should be treated
the same as em units.
MozReview-Commit-ID: 2zM7O0awynG
CSSparserImpl::ParserShadowItem stores shadow items in a different order that
does not match the order we use when serializing computed shadow items.
The items order of storing by parser:
<length> <length> <length> <length> <color> <inset>
The items order of serializing:
<color> <length> <length> <length> <length> <inset>
Spec of this serialized order is as follow:
5c46d78107
This patch will shuffle the order of this items in the shadow array when
serializing it.
MozReview-Commit-ID: CIawpYKKIRy
--HG--
extra : rebase_source : 9b4f5d20543980baa45c07c950fa0baa59d9cc93
For an import loop sheet, set the URIs and principal, and mark it complete, so
that it can still be properly accessed via CSSOM without errors.
MozReview-Commit-ID: 1oO1LoaPk8V
--HG--
extra : rebase_source : 2de1e8e03a2e8934710c2f2631f771bc067923d3
Instead of the WebRenderLayerScrollData code knowing about all the
different display item types, it makes more sense to move this logic
into the display items.
In addition to avoiding dis-encapsulating the data from nsDisplayItem subclasses,
this makes it easier to handle two specific scenarios:
(1) the case where an nsDisplayItem A subclasses another nsDisplayItem B, but A
and B have different types returned by GetType(). Previously A and B would have
to be handled explicitly in the WebRenderLayerScrollData switch statements,
which doesn't scale well if new types are added. With the new approach the
virtual function is shared down from A to B and so takes care of it. This is
particularly relevant for types like nsDisplayOwnLayer which have a number of
subclasses.
(2) the case where a display item *might* have APZ-relevant information.
In this case the type of the item alone is not sufficient to determine
if we need to create a new WebRenderLayerScrollData for it. Instead, we
need to access specific state inside the display item. This is now
handled by the UpdateScrollData function returning true when passed
nullptr arguments, and replaces the switch statement in
WebRenderLayerManager that updated forceNewLayerData.
MozReview-Commit-ID: FlfHlgSccSn
--HG--
extra : rebase_source : d1fe841724cc6020433aea31ffb5214d8a44d0a9
This is similar like the previous patch, but for the 8-bit string variants.
Also, it changes assignment to Adopt() in GetCString() and GetDefaultCString()
to avoid an extra copy.
--HG--
extra : rebase_source : eba805c3a7b809d5ccd6e853b1c9010db9477667
nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
Add ServoFontFeatureValuesRule for CSSOM representation of
@font-feature-values rule and wire up with bindings.
MozReview-Commit-ID: B4Lpj43bvKX
--HG--
extra : rebase_source : 6508027f88ff76784ed7d0e5420d6e174f116b38
Because we want to remove nsAdoptingString. We have other variants that don't
use nsAdoptingString, which can be used instead. There are three basic
patterns.
1. The easiest case is when we don't check for success.
> nsAdoptingString s = Preferences::GetString("foo");
> foo(s);
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> foo(s);
2. The next case is when we check if the result is empty.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s.IsEmpty()) { ... }
becomes:
> nsAutoString s;
> Preferences::GetString("foo", s);
> if (s.IsEmpty()) { ... }
3. The final case is when we null check the result.
> nsAdoptingString s = Preferences::GetString("foo");
> if (s) { ... }
becomes:
> nsAutoString s;
> nsresult rv = Preferences::GetString("foo", s);
> if (NS_SUCCEEDED(rv)) { ... }
The patch also avoids some UTF8/UTF16 conversions in a few places.
--HG--
extra : rebase_source : f339b1a3dda4dc93979d38c30c001fbe77485b55
Extract CSSFontFeatureValuesRule from nsCSSFontFeatureValuesRule
class. This is necessary because we will create a FontFeatureValues
rule for Servo side.
MozReview-Commit-ID: GKy5wa6JLv9
--HG--
extra : rebase_source : 015f13da9a776c4ece8aa13655395afbb347b870
This bug report became semi-obsolete after we restructured the way flex items
are reordered for the CSS 'order' property. I'm adding its testcase as a
crashtest for good measure & for regression-testing.
MozReview-Commit-ID: 9ytJymbxZx
I believe crashtest 876074-1.html stopped asserting (about flex item frame-list
sortedness) once we stopped reordering the flex item child-list, in bug 812687.
So we don't need this asserts() annotation anymore.
MozReview-Commit-ID: BlMoFnkLQeU
nsMenuPopupFrame will constrain the size of its widget to its min and max size.
It will also request its nsView to resize to its frame rect. If its frame rect
is larger or smaller than the min or max size, nsView will be unable to change
the size of the widget, and each ViewManagerFlush will attempt a resize and
force a composite. When there are a lot of ViewManagerFlushes, this can
overload the compositor.
--HG--
extra : rebase_source : e32c3bb5445365ef76ea2a0700abb6911974afcc
extra : source : cadcf04ef23cee5ddbbbf216573c05d3fc0e53f2
This bug report became semi-obsolete after the assertion it triggered was
removed (as part of CSSUnprefixingService being replaced with native code).
I'm adding its testcase as a crashtest for good measure & for
regression-testing.
MozReview-Commit-ID: GhsoI8UHqI8
This patch replaces four functions of the name AssignWithConversion which
are essentially wrappers around CopyASCIItoUTF16 and LossyCopyUTF16toASCII
with direct calls to the latter two functions. The replaced functions are:
void nsCString::AssignWithConversion( const nsAString& aData )
void nsString::AssignWithConversion( const nsACString& aData )
void nsTString_CharT::AssignWithConversion(
const incompatible_char_type* aData,
int32_t aLength = -1);
The last of the three exists inside the double-included nsTString* world and
so describes two functions, giving four in total.
This has two advantages:
* it removes code
* at the call points, it makes clear (from the replacement name) which
conversion is being carried out. The generic name "AssignWithConversion"
doesn't make that obvious -- one had to infer it from the types.
The patch also removes two commented out lines from
editor/composer/nsComposerCommands.cpp, that appear to be related. They are
at top level, where they would never have compiled. They look like
leftovers from some previous change.
--HG--
extra : rebase_source : fb47bf450771c3c9ee3341dd14520f5da69ec4f5
With this patch, we now have an automated test to verify if a transition
is run properly on a visited link. Note that the test aims to verify
the behavior in Stylo should match that in Gecko. Due to Bug 868975, we
haven't supported transitioning on visited styles yet, so the test should
be put in our own repo for now. This test can be tweaked and put into
web-platform repo once we resolve Bug 868975.
MozReview-Commit-ID: Ci1cERXkIUK
--HG--
extra : rebase_source : 7feb1229bc2dc430bc2a1e40be40047049469fbd
I've been having problems with interdiffs on mozreview lately, so for
ease of review, this patch is being submitted as a seperate patch for
review. Once it is r+'d, it will be folded into the first patch in
this set before landing.
MozReview-Commit-ID: CS9MngaXlBd
--HG--
extra : rebase_source : 6a86fd4f7a66e73497a756976a2562d183002a2a
Removes applet tag interfaces, and changes HTML5 parser to output
HTMLUnknownElement when tag is found. Removes tag process from various
places in the browser.
MozReview-Commit-ID: 2zHhK2U2esX
--HG--
extra : rebase_source : d06ecaffd1cb656301e29b900bafde4c68a4606e
This doesn't actually implement style context reparenting in the style set yet; that part is next.
There is one behavior difference being introduced here compared to Gecko: we
don't reparent the first block piece of an {ib} (block-inside-inline) split
whose first inline piece is being reparented. This is actually a correctness
fix. In this testcase:
<style>
#target { color: green; }
#target::first-line { color: red; }
</style>
<div id="target">
<span>
<div>This should be green</div>
</span>
</div>
Gecko makes the text red, while every other browser makes it green.
We're preserving Gecko's behavior for out-of-flows in first-line so far, but
arguably it's wrong per spec and doesn't match other browsers either. We can
look into changing it later.
MozReview-Commit-ID: 5eC6G449Mlh
--HG--
extra : rebase_source : 8c333a0afe96c68a4e3b6aeca1b742ef8d5edd3b
The style contexts are already correct here; the frame constructor ensures that.
MozReview-Commit-ID: CWO225MB6Pe
--HG--
extra : rebase_source : ebc74ab507aaad6ac4c301cbbcdcab30ad3034d0
We don't need to reparent when moving things in/out of anonymous boxes and using the stylo backend.
MozReview-Commit-ID: 8C6ScqTuR9z
--HG--
extra : rebase_source : 0f180647a39a051e2a5aabe642031134852bf95b
We need this new API in the following patch.
MozReview-Commit-ID: JSoCgzKWrfs
--HG--
extra : rebase_source : e7da0a990b991b1c417015a9cb4f9e2b1e98faae
extra : source : 8f02c1ea8448315f9284939823d66e67cdc5ad87
Since we make "font-variant-alternates" animatable,
should remove test fail annotation from reftest.list.
MozReview-Commit-ID: ChdeSvUbTBh
--HG--
extra : rebase_source : fac9fb01a60c684d7169866964621f431b3508e3
The details element, which is a sibling of an animating element, is checked
whether the element needs to be processed in a post traversal for throttled
animation flush because the parent element has animation-only dirty bit (i.e.
the parent element is a common ancestor of the animating element and the
details element). Also at the moment of the check the details element has
reconstruct frame damage because 'open' attribute is changed. Thus in the check
the details element was not restyled but had reconstruct frame damage.
MozReview-Commit-ID: FvsyZlUjhFi
--HG--
extra : rebase_source : 80ee22e7a3092ee208ce74304c242da782f6a0f4
This allows us to turn on layers-free mode in the firefox UI process,
and have it work better in that the content process' content actually
shows up.
MozReview-Commit-ID: qBnfueYmuf
According to the crash reports, nsPrintEngine::AfterNetworkPrint() may be called after nsPrintEngine::Destroy() is called. In this case, the method should do nothing because it's already been destroyed.
MozReview-Commit-ID: IwY9fR1OUwU
--HG--
extra : rebase_source : 6fb2e23a1e30da59c4c8823e72b8a4460c8adb28
The test case in this patch freezes without this fix.
MozReview-Commit-ID: 6Rb9XmtAmpM
--HG--
extra : rebase_source : 9a68482c77d5e77ed5733f757ed3ec021834ba2f
Before bug 929484, border-radius on row groups, rows, column groups,
or columns don't apply to the background of each cell, yet the
border-radius on the cell itself does. After bug 929484, the behaviors
changed. In this patch, I tried to revert the behaviors of border-radius
on table row groups, rows, column groups, or columns back to
what happened before bug 929484.
MozReview-Commit-ID: 1Xg1qHde3lk
--HG--
extra : rebase_source : ff08f8390ff910fe8c141a75275134f77a1cec3e
This is Gecko-only code, so no need to allow Servo.
MozReview-Commit-ID: H4xZx0jMREI
--HG--
extra : rebase_source : b1b255b12ed4f052f7ba3aa9f5943fb3d24f9e52
This reftest fails without the first patch on stylo.
MozReview-Commit-ID: E5pBzBw9x8B
--HG--
extra : rebase_source : 4fe2a99bfed76d1b5fb320ef6a4f2b39ee5f5f2c
Also if |aCoeff1| is zero, we can just ignore the first list altogether.
MozReview-Commit-ID: LVZmAx0K574
--HG--
extra : rebase_source : f4419131590befde2a616d2e47785024f90f0719
We should do SchedulePaint in nsImageFrame for layers-free mode and set
invalid flag to make sure the image will be repainted.
MozReview-Commit-ID: 2lXElZ151Qa
--HG--
extra : rebase_source : 56045f66f3b36afe8a6327b841d80073f1d038cb
nscoord_MAX is (1<<30) so that we can check for overflow *after* adding
two nscoords. However, (nscoord_MAX + nscoord_MAX) will still overflow.
Subtracting one makes this no longer possible.
MozReview-Commit-ID: BtbQRMp5kWm
This removes the two calls to `FlushPendingLinkUpdates` in nsCSSFrameConstructor
and GeckoRestyleManager, which appear to have no effect.
Looking through what the pending link code is attempting to do:
* When a new anchor is bound in `BindToTree` we do:
1. Link::ResetLinkState(false, Link::ElementHasHref());
* Set link's mLinkState to default (either unvisited or not link)
* Set element's link mState bits to default (either unvisited or not link)
2. doc->RegisterPendingLinkUpdate(this);
* Schedules idle dispatch to run `FlushPendingLinkUpdates` within 1 sec
* In `FlushPendingLinkUpdates`:
* For each pending link, call element->UpdateLinkState(link->LinkState());
1. Register link for async history update to get potential future visited
state
2. mLinkState is still unvisited / not link until we hear from history, so
element state is unchanged
Thus, there seems to be no need to call `FlushPendingLinkUpdates` outside of
`BindToTree`, since visited state is always applied async anyway (so it doesn't
work as an optimization to avoid restyling if visited, since that will trigger
later).
MozReview-Commit-ID: KbFuKve1KUi
--HG--
extra : rebase_source : fdc098397d2fe9963ff82566f7a6b7c8c4656d63
Otherwise we risk losing track of the frame if we hit the cache.
MozReview-Commit-ID: ByHGhcBwIfX
--HG--
extra : rebase_source : 4534efa9ef02f4d7f59a33b55c50d9d372ad08a8
The unit of nsCSSValue is always number/pixel/percent or eCSSUnit_Calc,
so we don't need the style context for Servo backend.
Besides, ReadTransform is a public API used in many places, so we keep
its argument type as nsStyleContext.
MozReview-Commit-ID: KLdrJ5BJXg8
--HG--
extra : rebase_source : 778ca38b06e2a13d3db0465b9e74bd0c33c62a88
This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
The pending transforms must have been computed using the older scroll offset
values, which means that updating the scroll offsets without recomputing the
transforms will make them wrong. If we do an empty transaction for the scroll
offset updates, the transforms will not get computed. This patch catches this
scenario and schedules a full paint instead of the empty transaction instead.
The case where the scroll offset is modified *before* the transform is already
handled by code in nsIFrame::TryUpdateTransformOnly.
MozReview-Commit-ID: I5s5J7BS1ru
--HG--
extra : rebase_source : 63fec656440c8bee322f069a4466a311ebcd0f7d
Jonathan Kew
cku
Xidorn Quan
Boris Chiou
Nicholas Nethercote
Wes Kocher
Brad Werth
Hiroyuki Ikezoe
Jamie Nicol
Sebastian Hengst
Kartikaya Gupta
Manish Goregaokar
Mantaroh Yoshinaga
Christoph Kerschbaumer
Matt Woodrow
Mason Chang
J. Ryan Stinnett
Carsten "Tomcat" Book
Brian Birtles
Cameron McCormack
Bobby Holley
Nazım Can Altınova
Daniel Holbert
Ryan Hunt
Julian Seward
Emilio Cobos Álvarez
Jeremy Chen
Kevin Hsieh
Kyle Machulis
Timothy Nikkel
Boris Zbarsky
Tobias Schneider
Ehsan Akhgari
Josh Matthews
Fernando Jimenez Moreno
Ryan VanderMeulen
Daisuke Akatsuka
Geoff Brown
Ethan Lin
Dão Gottwald
Masayuki Nakano
KuoE0
Ya-Chieh Wu
Morris Tseng
Yoshi Huang
Samael Wang
Joel Maher
Botond Ballo
Bill McCloskey
Sylvestre Ledru
Simon Sapin
James Willcox
Bevis Tseng
Dan Mosedale ext:(%3E)