Otherwise, the parent style context doesn't have some inherited structs in the
cache, so it avoids comparing them entirely.
For example, the following example:
<p>Hey</p>
p { color: blue }
p:hover { color: red }
Wouldn't work as intended, because when calculating the change hint the
nsStyleColor struct in the element hasn't been accessed by layout (only the
child text frame's has), so it will report a change hint of 0 when hovering over
the paragraph, and we would ignore the nsChangeHint_ReconstructFrame generated
by the text node.
MozReview-Commit-ID: FW7Thhuh7LG
This patch makes the following changes on many in-class methods.
- NS_METHOD F() override; --> NS_IMETHOD F() override;
- NS_METHOD F() override {...} --> NS_IMETHOD F() override {...}
- NS_METHOD F() final; --> NS_IMETHOD F() final;
- NS_METHOD F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 3010fade82a170eab7f13d81bf61b02cd693f3cf
This patch makes the following changes on many in-class methods.
- NS_IMETHODIMP F() override; --> NS_IMETHOD F() override;
- NS_IMETHODIMP F() override {...} --> NS_IMETHOD F() override {...}
- NS_IMETHODIMP F() final; --> NS_IMETHOD F() final;
- NS_IMETHODIMP F() final {...} --> NS_IMETHOD F() final {...}
Using NS_IMETHOD is the preferred way of marking in-class virtual methods.
Although these transformations add an explicit |virtual|, they are safe --
there's an implicit |virtual| anyway because |override| and |final| only work
with virtual methods.
--HG--
extra : rebase_source : 386ee4e4ea2ecd8d5001efabc3ac87b4d6c0659f
Ensure that the first line of the log for failing tests is identical to
one that would be produced by the tbplformatter from mozlog. This means
that treeherder will be able to sucessfully cross-match error lines.
Also make the data structures used for storing screenshots identical
between reftests and web-platform-tests so that we can start to move
toward removing the reftest-specific codepath here.
MozReview-Commit-ID: FZQXLjj9Ejv
--HG--
extra : rebase_source : 3e9bf70ff7915817b8c02032c8da0d0a659e4661
nsTextFrame::GetCharacterRectsInRange() handles a character at the end offset of its content as in it. However, it causes odd result when the caller wants first text rect in the next nsTextFrame. E.g., if end of query range is at the next nsTextFrame's first character, currently, it returns the last character as in same line.
So, it should stop handling next frame's first character as in it.
MozReview-Commit-ID: 7WteerisrZp
--HG--
extra : rebase_source : 97653f1ed04a6a03373cd53613d92aba45fbe38b
New eQueryTextRectArray causes a lot of assertions in various automated tests. The cause is that nsTextFrame::GetCharacterRectsInRange() calls gfxSkipCharsIterator::AdvanceOriginal(1) at the end of the |for| loop *without* checking if the iterator has already reached to the end.
MozReview-Commit-ID: 3KFxA11uOUc
--HG--
extra : rebase_source : 407c47897cad8c2e4929ed1226073302faaecee2
This implements the spec change in 21de090dac
The spec change refers to a binary 'animation direction' flag. Instead of that,
however, we just pass the playback rate along and use it inside
GetComputedTimingAt since this seems simpler.
Also, this patch moves the implementation of
KeyframeEffectReadOnly::GetComputedTiming from the header file into the .cpp
file. This is because with this change, GetComputedTiming needs to call
mAnimation->PlaybackRate() and so mozilla::dom::Animation needs to be a complete
type. However, simply including Animation.h doesn't work because of a cyclic
dependency between KeyframeEffect.h and Animation.h. We might be able to fix
this later but since yet-to-land bug 1049975 moves this code around a lot, I'd
rather not touch it too much just now.
MozReview-Commit-ID: 1h6XRh4xmfI
This makes it so check-for-references.sh won't complain about the tests.
It's equivalent since this is a set of three tests that need to be
compared for equality, and this just tests A==B and B==C instead of A==B
and A==C.
MozReview-Commit-ID: 37VzOKVfR9W
--HG--
extra : transplant_source : %3A%DA/%999k%E0%DEFP9t%C9%5DD%AF%82Y%A3%84
Casting the scale components to integers before multiplying meant that
nsDisplayTransform::ShouldPrerenderTransformedContent was incorrectly
calculating the scaled frame size. This was especially bad when scale <
(1.0, 1.0), as it would calculate a size of (0, 0), leading us to
prerender the frame even if it was too large.
Calculate the frame's size using floating point scale components so as
to avoid this problem.
MozReview-Commit-ID: KhbP8tJ8qYx
--HG--
extra : transplant_source : %E6%BD%80l%D9O%CE%B0%12%D8%94R%AB%C0%13%A0%E7%B9%01E
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
The current setup here tries to "save" an entry in the list by checking
for the "None" namespace everywhere and special-casing it. We can simplify
this a lot by just adding the empty atom to the beginning of the array,
which is the value that servo uses to represent "namespace none" anyway.
We want the maximum scroll position to be aligned with layer pixels. That way
we don't have to re-rasterize the scrolled contents once scrolling hits the
edge of the scrollable area.
Here's how we determine the maximum scroll position: We get the scroll port
rect, snapped to layer pixels. Then we get the scrolled rect and also snap
that to layer pixels. The maximum scroll position is set to the difference
between right/bottom edges of these rectangles.
Now the scrollable area is computed by adding this maximum scroll position
to the unsnapped scroll port size.
The underlying idea here is: Pretend we have overflow:visible so that the
scrolled contents start at (0, 0) relative to the scroll port and spill over
the scroll port edges. When these contents are rendered, their rendering is
snapped to layer pixels. We want those exact pixels to be accessible by
scrolling.
This way of computing the snapped scrollable area ensures that, if you scroll
to the maximum scroll position, the right/bottom edges of the rendered
scrolled contents line up exactly with the right/bottom edges of the scroll
port. The scrolled contents are neither cut off nor are they moved too far.
(This is something that no other browser engine gets completely right, see the
testcase in bug 1012752.)
There are also a few disadvantages to this solution. We snap to layer pixels,
and the size of a layer pixel can depend on the zoom level, the document
resolution, the current screen's scale factor, and CSS transforms. The snap
origin is the position of the reference frame. So a change to any of these
things can influence the scrollable area and the maximum scroll position.
This patch does not make us adjust the current scroll position in the event
that the maximum scroll position changes such that the current scroll position
would be out of range, unless there's a reflow of the scrolled contents. This
means that we can sometimes render a slightly inconsistent state where the
current scroll position exceeds the maximum scroll position. We can fix this
once it turns out to be a problem; I doubt that it will be a problem because
none of the other browsers seems to prevent this problem either.
The size of the scrollable area is exposed through the DOM properties
scrollWidth and scrollHeight. At the moment, these are integer properties, so
their value is rounded to the nearest CSS pixel. Before this patch, the
returned value would always be within 0.5 CSS pixels of the value that layout
computed for the content's scrollable overflow based on the CSS styles of the
contents.
Now that scrollWidth and scrollHeight also depend on pixel snapping, their
values can deviate by up to one layer pixel from what the page might expect
based on the styles of the contents. This change requires a few changes to
existing tests.
The fact that scrollWidth and scrollHeight can change based on the position of
the scrollable element and the zoom level / resolution may surprise some web
pages. However, this also seems to happen in Edge. Edge seems to always round
scrollWidth and scrollHeight upwards, possibly to their equivalent of layout
device pixels.
MozReview-Commit-ID: 3LFV7Lio4tG
--HG--
extra : rebase_source : 3e4e0b60493397e61283aa1d7fd93d7c197dec29
extra : source : d43c2d5e87f31ff47d7f3ada66c3f5f27cef84a9
I have to move the definition of StyleBasicShape and StyleShapeSource prior to
where nsStyleDisplay::mShapeOutside is defined since the template struct need to
be fully defined before using as a member variable.
Use SetIdent() in CreatePrimitiveValueForBasicShapeOrURL() in
nsComputedDOMStyle.cpp per bug 1288626 comment 6.
MozReview-Commit-ID: 1KZS299CFul
--HG--
extra : rebase_source : d96276a1d514e1e42e1daf6f23e6bbfcb92d3bec
Change to geometry box to match the name in the spec.
https://drafts.fxtf.org/css-masking-1/#the-clip-path
MozReview-Commit-ID: 8jDTynCkJ4A
--HG--
extra : rebase_source : c2e165e320c1341012b32b48bfb03b3c9b4f56c5
The only difference between clip-path and shape-outside is the reference box
enum, so I generalize StyleClipPath to be a template struct StyleShapeSource to
accommodate both. I'll have to move all the method definition to the header to
make the linker happy.
The only logic change is calling operator==() instead of EqualURIs to compare
urls in StyleShapeSource::operator==().
MozReview-Commit-ID: LOBGVVpnnB
--HG--
extra : rebase_source : eca561500f8f8529cf6e7b5c04372a51c1b62862
StyleClipPathType will be generalized to StyleShapeSourceType to match this
change.
MozReview-Commit-ID: Igaad2EoSSt
--HG--
extra : rebase_source : 517d7b968e90f8f83e1223d33bd9d59000e034fd
Rename StyleBasicShape to StyleBasicShapeType in nsStyleConsts.h, and
replace the old enum nsStyleBasicShape::Type by the enum class
StyleBasicShapeType.
Also, replace NS_ASSERTION() by MOZ_ASSERT().
MozReview-Commit-ID: EuS4ZtYKsk6
--HG--
extra : rebase_source : b6cb68f91c545cef283c97de222111d3acb64b02
This fixes a regression from bug 1288827. It happened because I moved the logic that finds
the application path a little later on in the test harness. But there was an instance where
it was being used in the android mach command before that point.
As it turned out, we don't really *need* that value there. This patch grabs the same value
from build_obj.substs which is already an argument to the function.
MozReview-Commit-ID: 3IsI4VzEIIF
--HG--
extra : rebase_source : ceb718b265c7886b831e0378436baebf2b4e7598
Given that script may change cursor image in a high frequency, and it
is usually small, it is probably better discarding it urgently.
MozReview-Commit-ID: J6tqIODXykg
This allows to copy the `content` property value from one nsStyleContent to
another, in order to implement content: inherit.
MozReview-Commit-ID: 75mQpGRKKba
Signed-off-by: Emilio Cobos Álvarez <ecoal95@gmail.com>
Eventually, we might want to use the same mechanism that Gecko uses directly,
and stop styling text nodes from Servo.
This would have the benefit of removing the "stash the change on the parent"
thing.
MozReview-Commit-ID: IOxNR05jkh
Signed-off-by: Emilio Cobos Álvarez <ecoal95@gmail.com>
This allows to copy the `content` property value from one nsStyleContent to
another, in order to implement content: inherit.
MozReview-Commit-ID: 75mQpGRKKba
Signed-off-by: Emilio Cobos Álvarez <ecoal95@gmail.com>
Eventually, we might want to use the same mechanism that Gecko uses directly,
and stop styling text nodes from Servo.
This would have the benefit of removing the "stash the change on the parent"
thing.
MozReview-Commit-ID: IOxNR05jkh
Signed-off-by: Emilio Cobos Álvarez <ecoal95@gmail.com>