This avoids asserting when the writing mode doesn't correspond to the
one stored (DEBUG-only) in aPercentBasis.
MozReview-Commit-ID: KKqms9X17SS
--HG--
extra : transplant_source : %0Eh%09F%17%15%0D%D1%D3%DA%9B%85%21z%ED%3Dx%EA%F9%E8
Update the various animation restyle tests to check the new animation only data
inside the restyle marker.
MozReview-Commit-ID: HEe8x45IhHj
--HG--
extra : rebase_source : fdaa5855e94d68ce2a70d00fde11582c9a538f45
Add restyle markers to `PrepareAndTraverseSubtree` to cover both initial styling
and part of the work of restyling. Also add restyle markers around the post
traversal work in `DoProcessPendingRestyles`.
A new marker is also added around the change hint processing after the post
traversal.
MozReview-Commit-ID: 43PSyCJLikR
--HG--
extra : rebase_source : 923dd3d5526a7d68ab08f86e6dc233c9c61fa97f
Stylo doesn't have a good equivalent for restyle hints to expose in markers and
the ones exposed for Gecko aren't very accurate either, so we don't want to
expose the restyle hint anymore.
At the same time, several animation restyle tests currently use the hint inside
the marker to check when animation-only restyles have happened. We can preserve
this by changing the data inside the marker to be a flag for whether the restyle
is animation only, which we know for both Gecko and Stylo.
MozReview-Commit-ID: 8L8KU8Ush7P
--HG--
extra : rebase_source : 4eef80653c1ef79ee1539d27fe6a70fbfaf441ad
One thing to note here is that the Scale function on gfxRect has a
different implementation than that in gfx::Rect which is replacing it.
The former just scales the width/height directly whereas the latter
scales the XMost/YMost and recomputes the width/height.
MozReview-Commit-ID: 5FImdIaNfC3
--HG--
extra : rebase_source : 98662d2a52ff9652ec60b066641a07c6d5ee8e08
Most of this patch is updating a few places that use gfxMatrix to use
the equivalent-but-differently-named functions on MatrixDouble:
- Translate/Rotate/Scale get turned into PreTranslate/PreRotate/PreScale
- Transform(Point) gets turned into TransformPoint(Point)
- gfxMatrix::TransformBounds(gfxRect) gets turned into
gfxRect::TransformBoundsBy(gfxMatrix).
- gfxMatrix::Transform(gfxRect) gets turned into
gfxRect::TransformBy(gfxMatrix).
The last two functions are added in this patch as convenience wrappers
to gfxRect instead of Matrix.h because we don't want Matrix.h to "know"
about gfxRect (to avoid adding gecko dependencies on Moz2D). Once we
turn gfxRect into a typedef for RectDouble these will be eliminated
anyway.
MozReview-Commit-ID: BnOjHzmOSKn
--HG--
extra : rebase_source : cf1692d1f0d44a4b05d684a66678739181a426d5
This extracts a BaseMatrix template of which Matrix is now a particular
specialization. The BaseMatrix allows us to reuse the same code for
floats and doubles, much like the other "base" classes (BasePoint,
BaseRect, etc.).
MozReview-Commit-ID: HO7bA83S9E0
--HG--
extra : rebase_source : dcd84d9a978cdea00bb54eb11eefcca9c6635901
In this patch, implements following properties:
* background-image
* border-image-source
* mask-image
MozReview-Commit-ID: 30RdO0fMNr8
--HG--
extra : rebase_source : d4490b4d64e22a3bc1f022c37edc20363f7c0269
In this patch, implements following properties:
* -moz-border-bottom-colors
* -moz-border-left-colors
* -moz-border-right-colors
* -moz-border-top-colors
To realize, we introduced a binding method Gecko_GetMozBorderColors.
MozReview-Commit-ID: JeseSyl8rMG
--HG--
extra : rebase_source : 118b6659a7be58f7b84e6024bfeea0a13dad66c0
Layers are retained between transaction and we store some data in the layers.
Thus, if we no longer use layers, we need find another storage to place
those data. I use frame's property to retain WebRenderUserData between
transaction.
MozReview-Commit-ID: Ku5VGBXa3w6
--HG--
extra : rebase_source : 636653f78d1d6c310726a1a2c944141dc691decc
Using SVG SMIL it is possible to animate the class attribute of an element using
markup such as the following:
<style>
.red {
fill: red;
}
</style>
<svg>
<circle cx="50" cy="50" r="30" fill="blue">
<set attributeName="class" to="red" begin="1s"/>
</circle>
</svg>
In Gecko, Element::GetClasses handles this case by looking for an animated class
string when the element in question is an SVG element.
This patch causes our Servo bindings to use GetClasses when querying attribute
values for selector matching.
Note that animating the class attribute is *not* expected to affect attribute
selectors such as `circle[class="red"]`. It does in Chrome, but that is due to
a Blink bug where animating attributes using SMIL affects the result of
getAttribute:
https://bugs.chromium.org/p/chromium/issues/detail?id=735820
This patch adjusts the behavior for both the GeckoElement case and the
ServoElementSnapshot case.
MozReview-Commit-ID: DAFWHSH1aYB
--HG--
extra : rebase_source : 292c4e2fb419818ea851aca12790ff7e70f2e1d4
We should consider step and step base when deciding whether to show second and
millisecond field, since step and step base can affect the valid time intervals,
and the valid intervals may have second/millisecond part.
MozReview-Commit-ID: H4mJvLTvBOM
Currently these two test cases don't fail either on gecko or stylo even if the
patches in this patch series are not applied, but will fail once the patch for
bug 1374175 (i.e. not returning reconstruction damage from
compute_style_difference in some cases) landed without this patch series on
stylo. That means that, on stylo, reconstruction of details element on removing
child summary triggered by RecreateFramesForContent in
MaybeRecreateContainerForFrameRemoval has not worked well.
MozReview-Commit-ID: El6p0UwWaJb
--HG--
extra : rebase_source : 4f06423f8a23a3d430b7a0d22ff07c316f3e633d
In case of removing summary element, we need to check details *frame* children
instead of details *element* children since the summary element has been
already removed from details element children list.
MozReview-Commit-ID: GEzDId9CYf9
--HG--
extra : rebase_source : 50834606413b916a3c0d6074a7a52e8bdbe845a0
Considering the case where the summary element has position:absolute, we need
to use inFlowFrame and its parent instead of aFrame itself.
MozReview-Commit-ID: Ds8xxyBuyO5
--HG--
extra : rebase_source : 6254dae16e0371c55ae469390a5aaafa300b740c
This commit also schedules empty transactions on input events that trigger a
focus sequence number update.
MozReview-Commit-ID: 1FWXfStLsGv
--HG--
extra : rebase_source : 02c6f07287b6909493f6f88345a3cca93ab3e45b
ContentEventHandler::ExpandToClusterBoundary() doesn't check the return value of nsTextFrame::PeekOffsetCharacter(). Therefore, it may set its result to reversed offset. (e.g., when aForward is true and offset is 6, the result may be 5. When aForward is false and offset is 5, the result may be 6.)
For avoiding that, ContentEventHandler::ExpandToClusterBoundary() should check the result and only when it returns nsIFrame::FOUND, it should compute the proper offset.
On the other hand, it's too bad for ContentEventHandler that nsTextFrame::PeekOffsetCharacter() to return nsIFrame::CONTINUE_UNSELECTABLE when the user-select style is "all" because IME doesn't expect such cases.
Therefore, this patch adds additional argument to nsIFrame::PeekOffsetCharacter(), aOptions which is a struct containing bool members. The reason why it's not a bit mask enum is, such struct doesn't cause simple mistake at checking the value and the code is shorter. When mIgnoreUserStyleAll of it is true, this patch makes nsTextFrame not return nsIFrame::CONTINUE_UNSELECTABLE.
MozReview-Commit-ID: ACNNBTP92YZ
--HG--
extra : rebase_source : bd85da902e7fb59135d15514cb20a5599a4a640b
When going back/forward through a tab's session history, the saved resolution from the LayoutHistoryState is set on the PresShell before first paint. On Fennec, this means that it is subsequently going to be overwritten by the MobileViewportManager's default zoom calculation.
To fix this, we make use of the MVM's feature to set a "restored" resolution that will then be taken into account on first paint.
MozReview-Commit-ID: 43o97M6fiaZ
--HG--
extra : rebase_source : 45d29057de137cb306617481311622c6ca620fa3
We need to call nsBindingManager's method from ServoStyleSet in a later
patch.
Also, we call nsStyleSet::SetBindingManager() immediately after we call
nsStyleSet::Init(). Therefore, we could pass binding manager to Init()
directly, and delete SetBindingManager().
MozReview-Commit-ID: 43WTpW3mSKX
--HG--
extra : rebase_source : f24f6085c51dfae1a969aee1e073720097d240d5
Most of the names passed to nsIStringBundle::{Get,Format}StringFromUTF8Name
have one of the two following forms:
- a 16-bit C string literal, which is then converted to an 8-bit string in
order for the lookup to occur;
- an 8-bit C string literal converted to a 16-bit string, which is then
converted back to an 8-bit string in order for the lookup to occur.
This patch introduces and uses alternative methods that can take an 8-bit C
string literal, which requires changing some signatures in other methods and
functions. It replaces all C++ uses of the old methods.
The patch also changes the existing {Get,Format}StringFromName() methods so
they take an AUTF8String argument for the name instead of a wstring, because
that's nicer for JS code.
Even though there is a method for C++ code and a different one for JS code,
|binaryname| is used so that the existing method names can be used for the
common case in both languages.
The change reduces the number of NS_ConvertUTF8toUTF16 and
NS_ConvertUTF16toUTF8 conversions while running Speedometer v2 from ~270,000 to
~160,000. (Most of these conversions involved the string
"deprecatedReferrerDirective" in nsCSPParser.cpp.)
--HG--
extra : rebase_source : 3bee57a501035f76a81230d95186f8c3f460ff8e
This reftest can also catch bug 1372876 because it has pseudo element rules
like ::-moz-range-progress in the XBL stylesheet.
MozReview-Commit-ID: LUicjTRzMKt
--HG--
extra : rebase_source : a7f94fce06168eb33742438157651f087bdf324f
This also moves the WithinEpsilonOf function from gfxPoint into
PointTyped, and changes call sites that are using
gfxPoint::Transform(Matrix4x4) to use Matrix4x4::TransformPoint(Point)
instead, which should be equivalent.
MozReview-Commit-ID: 3Z0bsU41rQt
--HG--
extra : rebase_source : 390e8de546d641d324e7125a06d0b8b51a48b946
Most of the changes in this patch are just using the explicit
constructor from gfx::IntSize to gfx::Size, since gfxSize did
that implicitly but gfx::Size doesn't.
MozReview-Commit-ID: CzikGjHEXje
--HG--
extra : rebase_source : 9d19977f2a774d9a2a653db923553a6c2e06f82a
Both Servo and Gecko store the specified value of the image-orientation
property as a single-precision float, but Gecko does the conversion to radians
and the computation to identify which quarter-turn the angle is closest to
using doubles.
We add Angle::radians64 to perform the conversion to radians using doubles,
just as Gecko does, and then update image_orientation to perform the
computation the same exact way Gecko does in
nsStyleImageOrientation::CreateAsAngleAndFlip. This lets the previously failing
reftests pass.
We also update Gecko_SetImageOrientation to take an orientation directly
instead of an angle (otherwise we'd be doing the which-quarter-turn-is-closest
computation twice).
Finally this lets us re-enable the reftests for image-orientation previously
marked as fails-if(styloVsGecko||stylo).
MozReview-Commit-ID: 2zMMzQlsYEC
--HG--
extra : rebase_source : c6ead4358a2b4fb052f6144959cea0ba79b985e2
Previously we just took the input angle mod 2π, which will leave negative input
angles as negative. By checking if the input mod 2π is negative and if so
adding 2π and then taking that mod 2π again we can ensure that we end up with a
an angle in the range [0, 2π].
We only do this if the result of the initial mod is negative because this adds
rounding error that is enough to mess up whether 135 is determined to be closer
to 90 or 180, for example.
We add a test for this as well.
MozReview-Commit-ID: Faf0f7wIEg3
--HG--
extra : rebase_source : 6a83824bdc8104f0d58d6e2b11cf6bfd6bfef7f0
This does NOT change variable names like |endNode| because it's not odd and somebody use it for nsINode and endContent for nsIContent. So, changing them needs more work.
MozReview-Commit-ID: 22imUltlu5R
--HG--
extra : rebase_source : 6c93069d0586b37c5084eaa71861085c01da7a7d
This does NOT change variable names like |startNode| because it's not odd and somebody use it for nsINode and startContent for nsIContent. So, changing them needs more work.
MozReview-Commit-ID: H19pTDprRuT
--HG--
extra : rebase_source : 7a7454ac14da48a597ff19a50c863d04dcaddd6e
Web standards use "Container" instead of "Parent". So, nsRange shouldn't use "Parent" for its members and methods.
MozReview-Commit-ID: Ho6N0diuWtE
--HG--
extra : rebase_source : ee4eb7068a68b118c7fe98e9e9e7fa9c9e7f13e2
In particular, this fixes:
* Restyling of <area> elements that reuse the primary frame mapping for the
image map.
* Restyling of children of display: contents elements when the display:
contents element generates a hint.
* Restyling of out-of-flows (if my analysis in the bug is right).
* Restyling of the ::backdrop pseudo-element.
* Restyling of the Viewport frame.
I only managed to do a reftest for the second one, but the rest of them are
covered by the assertions added.
MozReview-Commit-ID: E7QtiQ1vPqu
--HG--
extra : rebase_source : 89085d96103ca743ba95ba61feeac68d24e8d307
For resizing context menus when accessed through touch, it is useful
for frontend code to know the inputSource of the action that triggered
a menu during the popupshowing event.
MozReview-Commit-ID: DvPDHvPgoUN
--HG--
extra : rebase_source : e175a71377bb7d243aeb79325b649f57bc31e830
No functional changes intended in this patch. It merely simplifies the
additional patch that we'll need to update gecko past WR cset 0bf6655,
and saves some potential manual rebasing work.
MozReview-Commit-ID: Km8dBotP3NQ
--HG--
extra : rebase_source : 77c34ec1cbbc1c0fe4d1971feb131d30c97f0d66
This adds commands to start a reftest session, run a test, and end the
session. It as assumed that after you start a reftest session you will
just run reftests until you end the session. When starting a session
the user provides a string indicating when screenshots should be
taken, and an object mapping urls to a count of the number of times
that url is expected to be used in the session, to help with
caching. Running the tests takes a url to a test, an expected status,
a timeout, and a nested list of possible references, in which each
entry at a specific level is combined by OR and nested references are
combined by AND.
The implementation is heavilly inspired by the existing reftest
harness, starting a minimal window with no tabs, and loading the urls
directly in there. In order to get a screenshot in the e10s case we
have to pass the DRAW_VIEW and USE_WIDGET_LAYERS flags when taking the
screenshot.
For performance we heavily cache canvases; for references that will be
repeated we cache the full canvas with image, and we also cache a
single canvas to use for all other screenshots to avoid the overhead
of repeatedly creating a new canvas element.
MozReview-Commit-ID: JOFvtmH7tg
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
All the instances are converted as follows.
- nsASingleFragmentString --> nsAString
- nsASingleFragmentCString --> nsACString
--HG--
extra : rebase_source : e6a1ddc8938fecd9a735b15e872c054edf4c7910
And fix animation_utils.js test code to handle the case when the pref is not defined.
MozReview-Commit-ID: 7wsPwtcvKqV
--HG--
extra : rebase_source : 58cbc660d6f493e54b6678d7da76866dd5c627a8
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
In the existing code, the parent having NS_FRAME_IS_DIRTY is not
propagated to column groups because nsTableFrame::ReflowColGroups checks
the child dirty bit before constructing the reflow state for the child.
This preserves that behavior in the presence of the primary patch in bug
1308876.
I noticed this while debugging the assertion count failure of
layout/base/crashtests/470851-1.xhtml . It doesn't help that failure,
but it still seems like the safe thing to do.
MozReview-Commit-ID: EhfIQQkeaJx
--HG--
extra : transplant_source : %1E%3Ej/K%00ai%073%B2%88%EF%D7%93%87%CD%F6%EB%C2
This is the primary patch in this bug, and makes the performance
improvement that fixes this bug.
The assertion count increase for layout/generic/crashtests/1015844.html
is accompanied by a layout change in the testcase as well. However, I'm
not planning to fix it in this sequence; fundamentally columnsets with
specified heights inside a paginated context (like another columnset) do
not work in any reasonable way, and changing the number of times we
reflow them can change the layout. At least, assuming I didn't lose
something in the process of simplifying the testcase.
ISSUES:
- may make block inside XUL worse in performance by marking dirty more (see subdoc in Firefox UI, or text control innards?)
MozReview-Commit-ID: GdOvPynqcFP
--HG--
extra : transplant_source : %9F%01%88%EC%0F%DC%D5%BB%BE%85G%E7%E5%B0%E0%CEl%A0o%1A
Previously, in paginated mode, all reflows were dirty reflows, since
tables do not split outside of printing, and prior to the primary patch
in bug 1308876, all reflows during printing are dirty reflows. (The
isPaginated test here is actually for real pages, not fragmentation in
general. However, the use here is appropriate for the meaning of
whether it's possible for the table to fragment.)
The fact that all reflows were dirty reflows meant that the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always cleared immediately
before reflow in ReflowInput::InitResizeFlags (which might also have set
the flag on *ancestors*). This meant that, prior to the primary patch
in bug 1308876, the initial value of needToInitiateSpecialReflow that
was initialized from the presence of the
NS_FRAME_CONTAINS_RELATIVE_BSIZE flag was always false. This patch
preserves that initialization in the presence of the change in the
primary patch in bug 1308876.
This caused a failure in a single test in our test suite, and in a
rather complicated way. The test was
layout/base/crashtests/470851-1.xhtml, in which there was both a
difference in assertion count (due to the bogus assertion "data loss -
incomplete row needed more height than available, on top of page" in
nsTableRowGroupFrame::SplitRowGroup, whose companion assertion "data
loss - complete row needed more height than available, on top of page"
is already just an NS_WARNING) that caused a test failure, and a
difference in layout (the test split across 3 pages rather than 2) that
did not cause a test failure.
This patch fixes the difference in layout. The immediate cause of the
layout difference was that a cell (the second outermost) on the second
page had a height, computed in CalcUnpaginatedBSize, that was large
enough to cause it to need to continue onto the third page. This height
came (via nsTableRowFrame::GetUnpaginatedBSize) from the
UnpaginatedHeightProperty stored on the first-in-flow of its row, on the
first page, stored by CacheRowBSizesForPrinting called in
nsTableRowGroupFrame::ReflowChildren during the reflow of its row group
on the first page, in a special height reflow initiated during the
second-pass constrained-height reflow of the table (still,
second-outermost) on the first page, due to the change being fixed in
this patch.
MozReview-Commit-ID: 3E84VwdXuPs
--HG--
extra : transplant_source : m%DF%D2L%7B%E7%DD%98.zzI%07%14w%8A%15J%F5%16
I noticed this while debugging the assertion count failure of
layout/base/crashtests/470851-1.xhtml . It doesn't help that failure,
but it still seems like the safe thing to do.
MozReview-Commit-ID: 6xHxUJCjUHh
--HG--
extra : transplant_source : %9C%03%5D%1E%24%BCs%EB%BF%1A%82n%D3%F3rc%C3%F6l%C4
This fixes the regression in
layout/reftests/columns/column-balancing-nested-001.html from the
primary patch in this bug, for which a simplified testcase is
https://bugzilla.mozilla.org/attachment.cgi?id=8848293 . I believe it's
simply a pre-existing bug that wasn't previously exposed. I suspect
it may be possible to write a test that shows the bug prior to the
patch. However, it's difficult, since it requires triggering height
changes in a multicol with an 'auto' height (since a non-'auto' height
would cause the multicol to have NS_FRAME_CONTAINS_RELATIVE_BSIZE set by
nsColumnSetFrame::Reflow, which would make skipIncremental false because
ShouldReflowAllKids returns true). I suspect any working testcase would
likely be rather brittle, so I haven't pursued it further (particularly
given the complexity of the minimal testcase).
MozReview-Commit-ID: Gve3XKEPSxL
--HG--
extra : transplant_source : %3FU%81Ti%B5%29RfAI%03%89%16%E2%BA%D4%BC%B9%2B
This fixes (confirmed by testing locally) a regression in
layout/reftests/w3c-css/received/css-multicol-1/multicol-nested-margin-004.xht
resulting from the primary patch in this bug, which tends to make frames
dirty less often. The problem with that test is that (at least in a
simplified form), in the final reflow of the inner ColumnSet in the
first column of the outer ColumnSet, the inner ColumnSet chooses not to
reflow its first column, thus leaving that first column having a height
that is too large for the inner ColumnSet to fit in the first column of
the outer ColumnSet, causing the entire inner ColumnSet (rather than
just part of it) to be pushed to the next column.
I believe this existing incremental reflow code just doesn't make sense.
The code I'm modifying dates back primarily to:
c237520c89 (October 2004, initial columns implementation)
ee070ec95f (March 2005)
31e3540d1e (November 2006)
The first thing that doesn't make sense is the condition modified at the
end of this patch:
(!reflowNext && (skipIncremental || skipResizeBSizeShrink))
There's simply no reason that that || isn't required to be an &&, as far
as I can tell. Even if we don't need to reflow due to any of the
standard incremental reflow conditions, we can need to reflow because
the block size is shrinking and the column no longer fits.
Note that things were already OK when we required reflow due to
NS_SUBTREE_DIRTY(this), because of the way shrinkingBSizeOnly was
initialized using !NS_SUBTREE_DIRTY(this), thus excluding such cases
from the optimization.
The rest of the patch falls out of turning the || into an && in an
efficient way (i.e., without the extra !NS_SUBTREE_DIRTY(this) test, and
avoiding doing extra tests that we know we're not going to need by
coalescing all the incremental reflow tests into a single variable).
I tested that this patch passes try on its own (on 64-bit Linux debug):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a279023fb7e8f3349d5ecbfb95807d6b097cdbcb
MozReview-Commit-ID: BD3ofmWN5Wl
--HG--
extra : transplant_source : %0F%A3%18%24%CF3%9A%5E%B9%7E%EBB%A12%84%3B%12L%A7c
This fires, for example, in layout/base/crashtests/265973-1.html (and a
number of other tests, I believe) with the primary patch in this bug.
This is because the primary patch causes frames to be dirty less often,
which sends us into the PrepareResizeReflow codepath, which only happens
when frames are not dirty.
I don't think NS_CoordSaturatingAdd is needed here, since newAvailISize
is used only when deciding whether or not lines need reflow; wraparound
should only cause us to do a little extra work.
Note: This patch passes try on its own, on Linux64 debug.
MozReview-Commit-ID: K6Z5MvG7awp
--HG--
extra : transplant_source : %A5%A6%BD%1A%08%8D%12%D5%21%BA%A0L%DB%C9%7C%22n0%22%B0
The primary patch in this bug causes fewer dirty reflows, which leads to lines
being out-of-date for the reason described in the comment. This causes
incorrect layout of some references sections on wikipedia, for which a
simplified testcase is included.
This bug was not caught by anything in our test suite, but I noticed it
while browsing wikipedia (since I use a build that has my patches in it
for my regular browsing).
MozReview-Commit-ID: 4hTQpGS2pZH
--HG--
extra : transplant_source : %DC%84%0A%19%AEDJ%9EN%13%E9t%FE%13%E2%F8%CD%DE%CBn
Both of the changes are needed to fix
layout/reftests/w3c-css/submitted/css21/pagination/moz-css21-float-page-break-inside-avoid-4.html
with the primary patch in bug 1308876.
That patch changes the transfer of NS_FRAME_IS_DIRTY from parent to
child so that it happens at the start of the parent's reflow rather than
later at the start of the child's reflow, which means that frames that
are pulled into a dirty frame during reflow are not marked dirty (and
thus forced to reflow all of their lines). This means that the primary
patch in bug 1308876 introduces the possibility of non-dirty reflows
during printing, which means we exercise non-dirty relayout code in a
number of tests where we did not do so previously.
Note: This patch passes try on its own, on Linux64 debug.
Writing a simple test for this that fails without the primary patch in
bug 1308876 seems difficult. ColumnSetFrame responds to
nsReflowStatus::NextInFlowNeedsReflow by marking the next-in-flow
*dirty* (which page frames don't), which makes it hard to test in
columns, at least without nesting. (Colums probably shouldn't do that,
though, but that's a performance fix for another time.)
MozReview-Commit-ID: JZ3qWTSO2lX
--HG--
extra : transplant_source : %83%1B%D6%B2%D4%01%DBk%AB%D6%14%C1w%EC%7C%BF%10%80d%9A
This also makes us stop reframing on lack of frame for pseudo-elements for which
such a lack is expected in various situations and means the pseudo-element's
styles do not matter.
MozReview-Commit-ID: K1qzeow2Z6H
::first-letter and ::first-line both want to change the styles of kids, and we
don't want the normal post-traversal for kids to clobber those changes.
MozReview-Commit-ID: 1tIsXz1n0uZ
Lee Salzman
L. David Baron
Sebastian Hengst
Christoph Kerschbaumer
Wes Kocher
Josh Matthews
J. Ryan Stinnett
Carsten "Tomcat" Book
Thomas Nguyen
Xidorn Quan
Brian Birtles
Nazım Can Altınova
Cameron McCormack
Kartikaya Gupta
James Graham
Emilio Cobos Álvarez
Daisuke Akatsuka
Phil Ringnalda
Bobby Holley
Ehsan Akhgari
Morris Tseng
Mats Palmgren
Brad Werth
Ethan Lin
sotaro
Jessica Jong
Mason Chang
Jonathan Kew
KuoE0
Hiroyuki Ikezoe
Mantaroh Yoshinaga
Ryan Hunt
Ryan VanderMeulen
Olli Pettay
Fernando Jimenez Moreno
Boris Zbarsky
Masayuki Nakano
Jan Henning
Alex Gaynor
Matt Brubeck
Ting-Yu Lin
Nicholas Nethercote
Boris Chiou
Jonathan Chan
Jared Wein
Bill McCloskey
Masatoshi Kimura
Johann Hofmann
David Anderson
Jeff Muizelaar
Chris Peterson
Thinker K.F. Li
Michael Layzell