Layout has been using imgIContainer::IsOpaque to determine if the image will draw opaquely to all pixels it covers, and doing culling based on this.
However imgIContainer::IsOpaque doesn't guarantee anything. It only describes if the image, when in a decoded state, has all opaque pixels. So if the image doesn't have fully decoded frames around (because they got discarded) it may not draw opaquely to all of its pixels.
So we create a new function that first checks if there is a fully decoded frame.
Previously we weren't sending scroll position updates with origin nsGkAtoms::restore
over to the APZ at all, on the assumption that they should never clobber an APZ
scroll offset. However, there are scenarios where that is not true.
In particular, during a frame reconstruction, a layers update may be sent to the
compositor between the time a scrollframe has RestoreState() called on it, and
the time the scrollframe has ScrollToRestoredPosition() called on it. The layers
update that happens during this interval (correctly) sends a scroll position of
(0,0), and forces the APZ to scroll to that position. This is necessary to
prevent APZ from remaining at an invalid scroll offset while the frame is still
being rebuilt.
However, once ScrollToRestoredPosition() is called and the old scroll offset is
restored, that restored scroll position needs to get sent to the APZ in order to
have it properly restore to the original scroll position. In order to do this,
the main thread must flag the metrics with a scroll offset update. Since the user
may have scrolled concurrently in the compositor from the (0,0) position, we also
need to check for that case in the APZ code and avoid restoring the scroll
position. This is equivalent to the corresponding main-thread code in
ScrollToRestoredPosition().
MozReview-Commit-ID: LxRapVSrsJ3
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Layout has been using imgIContainer::IsOpaque to determine if the image will draw opaquely to all pixels it covers, and doing culling based on this.
However imgIContainer::IsOpaque doesn't guarantee anything. It only describes if the image, when in a decoded state, has all opaque pixels. So if the image doesn't have fully decoded frames around (because they got discarded) it may not draw opaquely to all of its pixels.
So we create a new function that first checks if there is a fully decoded frame.
I'm not convinced that we can actually get regular content
<_moz_generated_content_before> elements in here, since it's only if
CompareTreePosition returned 0 that we look at the element name,
but might be best to make this test stronger in any case.
MozReview-Commit-ID: 8CgxcU9AbDA
--HG--
extra : rebase_source : 4a47ed62895d83f720ec7ccfde253e2c1945b34f
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
Structs in our style system use an arena-style allocation system,
managed by the presshell to which they belong. All of the relevant
overloads that forward allocation requests to the presshell declare
themselves as CPP_THROW_NEW, which indicates that they do not throw
exceptions. The C++ specification states that operator new overloads
that declare themselves to not throw exceptions require a null check on
their return value. However, the relevant presshell allocation method,
AllocateByObjectID, is infallible and will never return a null pointer.
The callers of all of these methods are therefore doing useless
(compiler-generated) null checks. Let's get rid of those useless checks
by removing the CPP_THROW_NEW annotations. This change declares these
methods will return non-null pointers and throw exceptions in case of
errors--but as we don't use exceptions, and AllocateByObjectID will
abort on OOM, everything works out OK.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
The merge from inbound to central conflicted with the merge from
autoland to central, it appears. Per tree rules, the commit from the
autoland repo wins and the inbound commit gets backed out.
CLOSED TREE
--HG--
extra : amend_source : 927e1cdfa8e55ccbd873d404d905caf6871c8c4f
extra : histedit_source : 07095868c3f767258e1d7d2645193bf4811b13bb%2Ca49ae5a28bf6e67298b6208ee9254c25a2539712
Structs in our style system use an arena-style allocation system,
managed by the presshell to which they belong. All of the relevant
overloads that forward allocation requests to the presshell declare
themselves as CPP_THROW_NEW, which indicates that they do not throw
exceptions. The C++ specification states that operator new overloads
that declare themselves to not throw exceptions require a null check on
their return value. However, the relevant presshell allocation method,
AllocateByObjectID, is infallible and will never return a null pointer.
The callers of all of these methods are therefore doing useless
(compiler-generated) null checks. Let's get rid of those useless checks
by removing the CPP_THROW_NEW annotations. This change declares these
methods will return non-null pointers and throw exceptions in case of
errors--but as we don't use exceptions, and AllocateByObjectID will
abort on OOM, everything works out OK.
This patch is generated by the following commands (note: if you're running
using OS X's sed, which accepts slightly different flags, you'll have to
specify an actual backup suffix in -i, or use gsed from Homebrew):
hg stat -c \
| cut -c 3- \
| tr '\n' '\0' \
| xargs -0 -P 8 gsed --follow-symlinks 's/\bnsCSSProperty\b/nsCSSPropertyID/g' -i''
Then:
hg mv layout/style/nsCSSProperty.h layout/style/nsCSSPropertyID.h
... and finally, manually renaming nsCSSProperty in the include guard in
nsCSSProperty.h.
MozReview-Commit-ID: ZV6jyvmLfA
--HG--
rename : layout/style/nsCSSProperty.h => layout/style/nsCSSPropertyID.h
This misspelling was introduced in bug 1125767, changeset b9951cca6d1f.
MozReview-Commit-ID: KQNlLelY2Kn
--HG--
extra : rebase_source : 7b2b8379da23b06737b462dd4c316b5758d807a9
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
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 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
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
Otherwise, when a glyph changes, we might end up doing too much work, destroying
the text-run and the observer that dirtied the frame, causing an assertion when
trying to delete it from the observer set.
MozReview-Commit-ID: LMQVr6pYFVM
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This is a prerequisite for the mass rename variables whose name
containing ReflowState in the next patch. Otherwise
nsRubyBaseContainerFrame::ReflowInput will conflict with
mozilla::ReflowInput.
MozReview-Commit-ID: KUU51Rjn6z
--HG--
extra : rebase_source : fcb3aefaea40f57e59cc81349b9fcc0f3a88394a
The modification to nsAbsoluteContainingBlock.h and nsBlockFrame.cpp are
needed to fix the build error due to the file order changed in the unified
build.
The #includes are fixed by the following script:
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename "nsHTMLReflowMetrics\.h" "mozilla\/ReflowOutput\.h"
MozReview-Commit-ID: KWvcG3UtKNn
--HG--
rename : layout/generic/nsHTMLReflowMetrics.cpp => layout/generic/ReflowOutput.cpp
rename : layout/generic/nsHTMLReflowMetrics.h => layout/generic/ReflowOutput.h
extra : rebase_source : dc62fb3ad4d95e732e5985c7ab9f757a0e23abcb
This is to avoid changing the access modifiers.
MozReview-Commit-ID: 9kkWeAKelGL
--HG--
extra : rebase_source : 67a3995872fff4a5028ce86ea070078635ba17e9
In nsIFrame::BuildDisplayListForChild for certain types of frames we create wrap list items to wrap the constructed display list to make those items inseperable.
We were using the current scroll clip by default when creating these items, but that scroll clip may not contain all the content in the display list if we traversed into an out of flow frame whose containing block is an ancestor of the current frame. The CurrentAncestorScrollClipForStackingContextContents keeps track of exactly this. (Its name might be a little misleading as we may not be dealing with a true stacking context here. Nevertheless it does contain the correct clip.)
We also need to initialize the value of mStackingContextAncestorSC when we create an AutoSaveRestore because we are now using that value sometimes without calling Enter/ExitStackingContext (which initializes mStackingContextAncestorSC).
I also adjust some of the old flag name to their logical name, and
rewrite some of the content where I see fit.
MozReview-Commit-ID: 7wAsDUOiN0a
--HG--
extra : rebase_source : 18e28e5ed1c593fb272042508b36244f132da4f5
In nsIFrame::BuildDisplayListForChild for certain types of frames we create wrap list items to wrap the constructed display list to make those items inseperable.
We were using the current scroll clip by default when creating these items, but that scroll clip may not contain all the content in the display list if we traversed into an out of flow frame whose containing block is an ancestor of the current frame. The CurrentAncestorScrollClipForStackingContextContents keeps track of exactly this. (Its name might be a little misleading as we may not be dealing with a true stacking context here. Nevertheless it does contain the correct clip.)
We also need to initialize the value of mStackingContextAncestorSC when we create an AutoSaveRestore because we are now using that value sometimes without calling Enter/ExitStackingContext (which initializes mStackingContextAncestorSC).
Just giving them an empty visible rect isn't enough because the initial visible rect can be ignored when we compute visibility.
When we enter an out of flow without saved clip data we set a flag on the builder indicating all items created should be invisible. When we enter a visible out of flow (ie one with saved clip data) inside the first out of flow we clear the flag so items created inside the second out of flow can be visible.
We should create a stacking context for any transform or opacity animations
that are either "in effect" (what we currently do) OR "current", i.e.
scheduled to run or running. *BUT* for now, we don't create any stacking
context in before phase without fill:backwards or fill:both because the
property never wins in cascade until the animation gets "in effect". This
restriction will be removed in a subsequent patch in this bug after landing
bug 1279403.
MozReview-Commit-ID: 8RyLJNPtoKI
--HG--
rename : layout/reftests/css-animations/stacking-context-transform-animation-ref.html => layout/reftests/css-animations/stacking-context-animation-ref.html
extra : rebase_source : 0d9c8d9e03ca0d400e9b376b9416fbabffd10034
We already have a wrapper named nsIFrame::BackfaceIsHidden().
MozReview-Commit-ID: 5L49W6wtXs1
--HG--
extra : rebase_source : d3be8d028453e63fb2d3d96b5956262d352385ef
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 : histedit_source : 5390eeebfe9a2791d9ac8e91ec1dfec4ec7b4118
The content clip is still valid, as we are only descending into content descendants.
The clip for content descendants that the root scroll frame creates so content doesn't overflow (visually or for event handling) the main scrollbar can get cleared otherwise.
This patch mainly consists of two parts, one for resolving and the other
for reordering.
In the resolving part, the added code stores the lowest embedding level
of all bidi formatting characters precede a frame to the bidi data of
that frame when necessary.
In the reordering part, virtual frame is restored from the information
stored above before asking the bidi engine to reorder frames
Collapsing a run of continuous virtual formatting characters into one
virtual character with the lowest embedding level among them should work
because a character with a higher embedding level than either of its
neighbors should not affect the reordering result of any other part of
the sequence. (No formal proof of this theorem, though)
MozReview-Commit-ID: LQjRu0mWsZP
--HG--
extra : source : 5d0cf1cbd270e9963d848a23b37528ed503ed6a0
This patch is mainly based on smontagu's wip patch. Some non-trivial differences:
* BidiParagraphData.mIsolateCount and related code are not added in this patch.
I investigated uses of this field in the wip patch, and it seems to me none of
them makes sense:
1. in the fast path of nsBidiPresUtils::ResolveParagraph, if there would be
any isolate character in the surrounding text, there must exist more than
one runs, which indicates the isolate count condition is redundant.
2. in handle of br frame in nsBidiPresUtils::TraverseFrames, based on my
understanding of "CSS Writing Modes Level 3" section "2.4.4. Paragraph
Breaks Within Embeddings and Isolates", the resolving should happen
unconditionally.
* {control,override}Char in nsBidiPresUtils::TraverseFrames are assigned
unconditionally when in a bidi inline container, so that we can properly
handle it when there are continuations. I suspect this was the reason of
regressions in dynamic reftests from the wip patch mentioned in comment 1.
MozReview-Commit-ID: LUdBAapA48e
--HG--
extra : source : 28fa56b841de689691375e8e2d5e56014921b48e
This matches the behaviour required by the latest editor's draft spec and matches what blink is planning on shipping soon.
It may not be an entirely web compatible change, but we expect only a small number of websites to be affected. See
the bug for more details.
Before this change, SetupJustificationSpacing calls ComputeJustification
to compute how justification gaps are assigned to characters, and store
them in the PropertyProvider instance. When GetSpacing is called, those
information would be used to compute actual spacings from justification
before/after each character.
The bug is that, GetSpacing did not take gaps before the given range
into account when computing the spacing, which leads to unstable results
when range varies because of ignorance of accumulated error.
This patch changes it to eagerly computing the actual spacings inside
SetupJustificationSpacing, so that GetSpacing just queries the result
from mJustificationSpacings.
MozReview-Commit-ID: HoWqeOhD85w
--HG--
extra : source : 3838277a3883b6958293cb043bd14d8462bf4e8e
Masayuki suggests GetCharcterRectsInRange instead of first idea's API by part 2 implementation.
IME wants to need the width per character. Now nsTextFrame/nsIFrmae has only API to get point of string. So I want to add this method to calculate simply by comment #3.
If no text frame, I would like to return error due to no character. (Caller shouldn't call this API on non-text frame.)
MozReview-Commit-ID: LQHUTzhnGn
--HG--
extra : rebase_source : bc495493c7be73afb05489ad2169e8dcdd6e6da4
extra : histedit_source : e54a7c3bfb100765317a0c8a83b432d5f706ffe1