Previously, when these properties changed, we'd only send change hints to
recompute overflow areas & trigger DLBI. If the outline was always outside of
the element's border box, this old strategy was generally OK, because the
outline tweak would cause a change to the overflow areas' size, and that would
invalidate the changed area via DLBI & trigger a repaint.
However, for outlines that are *inside* of the element (via negative
'outline-offset'), these change hints were not sufficient, because tweaks to
the outline width & offset will NOT affect the size of the element's overflow
areas and will not trigger any DLBI invalidation.
So in order to correctly handle these changes, we really need to request a
repaint of the affected element, since some piece of the element may need to be
repainted even if it's not changing in size.
MozReview-Commit-ID: J4KGUHrJ09U
--HG--
extra : rebase_source : 677950d5aebdf7e90120b8fe7bb937344da42d7d
We will actually hit the assertion in the destructor of
StyleImageRequestCleanupTask after the change above:
MOZ_ASSERT(mImageValue->mRequests.Count() == 0 || NS_IsMainThread()
"If mImageValue has any mRequests, we need to run on main "
"thread to release ImageValues!");
From Part 6 to Part 9, we do put a request immediately after the creation of an
ImageValue, so even if a nsStyleImageReqeust is not resolved, we still need to
destruct mImageValue on the main thread.
MozReview-Commit-ID: F812iySXbh6
--HG--
extra : source : 74377e39719599633806c5ecd728e4015c7603d0
This patch implement several things:
1. Implement a new constructor for nsStyleImageRequest to receive an existing
ImageValue from the caller.
2. Implement Gecko_ImageValue_Create to allow stylo to create a gecko::ImageValue
object.
3. Implement Gecko_SetXXXXImageValue to allow stylo to pass a created ImageValue
back to gecko.
MozReview-Commit-ID: 1SbW5w8FSV2
--HG--
extra : source : 63777ecf4c7138a0ce5847753a41efcbfc8e2b20
extra : intermediate-source : dced488c119da7e3ae27c903c0dcc76593d8a06d
Image loading status can be accessed in main thread only, so we can not use
nsStyleImage::IsLoaded in nsStyleBorder::CalcDifference, which might be executed
on a background thread.
The drawback of this change is we may paint a border-image, once, even before it
was actually loaded, which is a waste, because we have nothing to draw yet.
PS:
We did not check nsStyleImage::IsLoaded in both background-image and mask-image's
CalcDifference.
MozReview-Commit-ID: 5knH6dZziL8
--HG--
extra : rebase_source : 8e854960bfec130fe06e57b5e898651814e7f36e
We need an FFI, Gecko_StyleTransition_SetUnsupportedProperty, to set the
mProperty and mUnknownProperty of StyleTransition. In Servo, we put
non-animatable, custom, and unrecognized property together, so this FFI
should look up the nsCSSPropertyID of the input string, and then store the
value and the unknown property string (if any) back to StyleTransition.
MozReview-Commit-ID: 4iZNKXNSrzj
--HG--
extra : rebase_source : 088daa620133418afdc6b1c97b6e90ceb7cf3b75
This patch doesn't change our behavior -- we won't actually act on the new flag
until the next patch in this series.
MozReview-Commit-ID: EONsLM54eG1
--HG--
extra : rebase_source : cabd4a140d575794a8a656c47692bb9d3a02de88
nsStyleImage::ComputeActualCropRect may return false under 4 conditions
1. mType is not eStyleImageType_Image.
This function is design to be used when mType is eStyleImageType_Image.
Replace this 'if' check by MOZ_ASSERT.
2. nsStyleImage::GetImageData() returns nullptr
This function will return true if this image refers to a local-ref resource.
3. GetImage returns failure or does not return a valid imgIContainer.
It's possible. Please refers to the comment in imgReqestProxy::GetImage
at [1].
4. imageSize is empty
It's possible too. By giving a malformed image to a style image, we will hit
this condition. And this is right what we met in this bug.
Since ComputeActualCropRect may actaully return false, we should remove the
NS_ASSERTION that assume it will always return true.
[1]
https://hg.mozilla.org/mozilla-central/file/7f1f1559cd8d/image/imgRequestProxy.cpp#l513
MozReview-Commit-ID: KHTFQJjiLtT
--HG--
extra : rebase_source : c4e119dd250094115ab23c323ca49f9ebc296698
1. add binding functions for -moz-border-*-colors support.
In Gecko, we use double pointers to nsBorderColors to store -moz-border-*-colors.
The computed values of -moz-border-*-colors are set by couple member functions.
To pass the computed value from Servo to Gecko, we need support for these member
functions as well. So, I'm adding some binding functions in this patch. The
actual use of these bindings to pass/store the computed values is separated
in the following patch, which should be a pure Servo change. See servo PR:
https://github.com/servo/servo/pull/16586.
2. update test expectations for -moz-border-*-colors support.
Note that with the support of -moz-border-*-colors, 165 mochitests and 17 reftests
could be fixed.
MozReview-Commit-ID: KDbp8C6Aoqd
--HG--
extra : rebase_source : 7d9675d9ece091ea6957dcae7d28c39066e69035
This switches over from using nsStringBuffer to nsString for URLValueData's
|mString| member. This avoids various tedious conversions and can provide
potential performance improvements by avoiding length calculations.
MozReview-Commit-ID: 5eRifUZrAso
Now, remove Layer::mSourceURI, there are several benefit of doing this:
1. Reduce the size of nsStyleImage::Layer.
2. By storing style image and url information in nsStyleImage, we can remove
many verbose comments. That is becasue there is no need to explain why we use
mSourceURI here, or why we use nsStyleImage there anymore.
3. Since all inforamtion is stored in on place, nsStyleImage, we can setup image
request or URLs by one single Gecko_SetUrlImageValue call.
MozReview-Commit-ID: 7aTQobddTB1
--HG--
extra : rebase_source : 247e3b66c727a9116c58d3d6ff3ae0f7a58f2338
This patch implements two things:
1. Add one extra type, nsStyleImageType::eStyleImageType_Url, and puts data of
this type in nsStyleImage::mUrlData.
2. Export SetURLValueData and GetURLValueData from nsStyleImage
With these chnages, we can simply use nsStyleImage::mUrlData to replace
Layer::mSourceURI in the next patch.
MozReview-Commit-ID: E20MEzXv8cg
--HG--
extra : rebase_source : 5461edacb28676e9d3a12068f330b5db7b9fe32c
This patch does the following in addition to a simple move:
* change the type of the pointers from RefPtr to nsCOMPtr
* move it from mozilla::css namespace to mozilla
MozReview-Commit-ID: 72MYq6kWm4s
--HG--
extra : rebase_source : 400fe0d7cc422f22592c302cfd4e457830b77e3e
We want to use a similar model as Chrome on Android does for scaling our display of web content, that is use font inflation for desktop pages and plain text zooming for everything else.
Since we don't want to simply clobber any text zoom that might have been set by the user/front-end code, we allow setting and storing the system font scale separately on the PresContext. We then calculate the effective text zoom value as the product of the system font scale and the current text zoom value.
Any function that is using the PresContext's TextZoom value for layouting/rendering is switched over to this new EffectiveTextZoom value, whereas functions that are interested in the text zoom as actually set by the user/front-end (e.g. the nsDocumentViewer, or the code responsible for copying text and full zoom settings into the new PresContext on page navigation) continue using the plain TextZoom value.
As long as font inflation is enabled in principle (e.g. font.size.inflation.minTwips != 0), every page starts out as eligible for font inflation until the relevant meta viewport tags marking the page as "mobile friendly" have been detected. Since the PresShell caches the font inflation state and only recalculates it when necessary, we make use of that and set the PresContext's system font scale as necessary whenever the font inflation state has been refreshed.
MozReview-Commit-ID: 2InyE04wKAW
--HG--
extra : rebase_source : 3f6d7128f37c1dc18f67a6655f86d9a3003fe90b
extra : source : 6100458b97289f9aea5ac8fda57ded045e6860b7
Look into the test case on bugzilla attachment:
o1.animate([{"mask": "linear-gradient(red,blue)", "transform": "none"}], 100);
If I replace mask by a filter effect, we won't hit that assertion. Then I looked
into nsStyleStruct, compared nsStyleSVGReset::CalcDifference with
nsStyleEffects::CalcDifference, and noticed that we miss a hint in nsStyleSVGReset:
nsStyleEffects::CalcDifference(const nsStyleEffects& aNewData) const
{
//....
if (HasFilters() != aNewData.HasFilters()) {
// A change from/to being a containing block for position:fixed.
hint |= nsChangeHint_UpdateContainingBlock;
}
}
MozReview-Commit-ID: KeViMShnMAK
--HG--
extra : rebase_source : 35a0c4468f966d67905fa945e1ef4b16eaac6e6f
extra : source : d238abed68d3e70df3f33dbed3b58aa1754b3f67
Implement this unil function to improve readability
MozReview-Commit-ID: FLKOGyq180W
--HG--
extra : rebase_source : db8dbc67dbc63c19df806e79ea36016d3d5fc8b6
extra : source : 47fa0a1f03acd6007e2d40e4ec5bc0ddba221361
Per bug 1322570 comment 46, it's not easy to replace ComputedJustifyItems()
and UsedJustifySelf()'s internal nsStyleContext::GetParent() without
correctness penalty, so we use GetParentAllowServo() for now.
Also, fix the reftest.list added in bug 1334403 which incorrectly wrote test
page as reference page.
MozReview-Commit-ID: 6kAAWSFojd5
--HG--
extra : rebase_source : 2d03302115dd40281cec27bc18750b6933682855
If nsStyleImageRequest::Resolve() has been called, we cache the DocGroup and
use it for dispatching events for the clean up task. Otherwise, it's safe to
do clean up task on non-main thread.
MozReview-Commit-ID: BXalEkc6dBm
--HG--
extra : rebase_source : ccc7c43a385f3149b53763030419561fc64efbfa
This change is to use gecko_enum_prefix in helpers.mako.rs, so that we do not
need to manually write code for nsStyleDisplay::mTransformBox.
MozReview-Commit-ID: 7UAL0iUcSIO
--HG--
extra : rebase_source : e99b7c163991df7ef3e7c0404fcef1832718a150
