This was never even meant to apply to the out-of-flow, just to the placeholder
itself. So it's been effectively dead since placeholders stopped inheriting
from another style context.
GetIndexFromSelectionType() in nsFrameSelection.cpp or
nsFrameSelection::GetSelection() appears in profile of attachment 8848015. So,
it should not use switch statement due to really hot path.
With the previous patch, we can make it use array to retrieve the index from
SelectionType with static_cast<int8_t>.
MozReview-Commit-ID: 8jvIF5buTyT
--HG--
extra : rebase_source : ccb9c855caa6688e45097f67de3160860339d281
nsISelectionController::SELECTION_* are declared as bit-mask. However, no
methods of nsISelectionController treat them as bit-mask and these
values need a switch statement in nsFrameSelection to convert SelectionType to
array index of nsFrameSelection::mDOMSelections because it's too big to create
an array to do it. Additionally, this conversion appears profile of
attachment 8848015.
So, now, we should declare these values as sequential integer values.
However, only nsTextFrame uses these values as bit-mask. Therefore, this patch
adds new type, SelectionTypeMask and creates new inline method,
ToSelectionTypeMask(SelectionType), to retrieve mask value for a SelectionType.
MozReview-Commit-ID: 5Za8mA6iu4
--HG--
extra : rebase_source : 86617c1f5fa23166458f4353cb834f9e7c5b131b
The failure mode in the attached crashtest is an inconsistency in the flattened
tree. Specifically, we null out mVideoControls in an nsVideoFrame, but defer
the UnbindFromTree call on that NAC element, which measn that its mParent still
points to the nsVideoFrame's mContent. Because all this stuff runs off of script
runners, and the anonymous content destroyer is not guaranteed to run before
other potential script runners, we end up running arbitrary script while the
tree mismatch exists. This script calls back into ProcessPendingRestyles, which
causes trouble.
We could build a separate deferral mechanism, but it's not clear that we actually
need to defer the unbind anymore. The deferred unbind was added in bug 489008,
which predated a lot of simplifications in layout/dom interaction.
MozReview-Commit-ID: 1JYAhiXKVJC
Another plumbing-only change, which is a precursor for the next patch.
ComputedValues are a Servo-only thing, so in order to use nsStyleSizes for both
Gecko and Servo, the ComputedValues sizes must be moved out.
MozReview-Commit-ID: BOnQSzzV0vC
--HG--
extra : rebase_source : 025c6161e509401a36525349083dd98bfda35621
This is a purely non-functional plumbing change. Instead of passing a
SizeOfState and an nsStyleSizes a bunch of places, we pass an nsWindowSizes,
which contains both of them.
This is a necessary precursor for the next patch.
MozReview-Commit-ID: Ek03wDM50rB
--HG--
extra : rebase_source : 7b05708bd21dc4e3812ea041647fa74bb413d0b9
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
For the Obama wikipedia page, this covers about 85% of the unmeasured
ComputedValues structs. The about:memory output looks like this:
> +---2,443,648 B (02.41%) -- computed-values
> | +--1,088,272 B (01.07%) -- dom
> | +----945,744 B (00.93%) -- non-dom
> | +----409,632 B (00.40%) -- visited
I'm not sure why some CVs are still being missed.
MozReview-Commit-ID: 1bYWwSi4ihn
--HG--
extra : rebase_source : 14e4bd36a54bbbd8fd265f559704bec5a5e3b154
This ensures that if the scroll event triggers style changes, they are
reflected on the same paint.
This is accomplished by having the refresh driver fire scroll events as
an explicit step after FlushType::Style observers and rAF callbacks, and
before the actual style flush.
MozReview-Commit-ID: 4kgauD5SgVo
--HG--
extra : rebase_source : 5f2c869c0749c1e1473797f2e202c075907a45fd
This change ensures that HTML frames with SVG filters applied are given the
correct overflow regions so that they will display and invalidate correctly.
The bug that this commit fixes does not manifest in many cases since
often elements happen to be reflowed more than once when a document loads.
When that happened the bug would be masked because the filtered frame would be
given a size during the first reflow, and that would then make the overflow
calculations in subsequent reflows work. It was only in cases where the
filtered frame was only reflowed once (such as when dynamically inserting a
filtered element into the DOM using script) that the lack of a valid frame
size during the overflow calculations would result in bad overflow regions
being calculated.
MozReview-Commit-ID: 79lR27KRSym
--HG--
extra : rebase_source : 9df6ff87002f0af4abf0b97e2a084902d81f468c
This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget
hack. The old design had several limitations:
* It couldn't handle shadows
* It couldn't handle selections
* It couldn't handle font/color changes in a single text-run
* It couldn't handle decorations (underline, overline, line-through)
Mostly this was a consequence of the fact that it only modified the start and end
of the rendering algorithm, and therefore couldn't distinguish draw calls for different
parts of the text.
This new design is based on a similar principle as DrawTargetCapture, but also passes
down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can
notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us
directly pass data to TextDrawTarget when possible (as is done for shadows and selections).
In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle
changes in font/color mid-text-run (which can happen because of font fallback).
The end result is:
* We handle all shadows natively
* We handle all selections natively
* We handle all decorations natively
* We handle font/color changes in a single text-run
* Although we still hackily intercept draw calls
* But we don't need to buffer commands, reducing total memcopies
In addition, this change integrates webrender's PushTextShadow and PushLine APIs,
which were designed for this use case. This is only done in the layerless path;
WebrenderTextLayer continues to be semantically limited, as we aren't actively
maintaining non-layers-free webrender anymore.
This also doesn't modify TextLayers, to minimize churn. In theory they can be
augmented to support the richer semantics that TextDrawTarget has, but there's
little motivation since the API is largely unused with this change.
MozReview-Commit-ID: 4IjTsSW335h
--HG--
extra : rebase_source : d69f69648ade5c7a8e6bb756f4b8ab9e2543e576
This change ensures that HTML frames with SVG filters applied are given the
correct overflow regions so that they will display and invalidate correctly.
The bug that this commit fixes does not manifest in many cases since
often elements happen to be reflowed more than once when a document loads.
When that happened the bug would be masked because the filtered frame would be
given a size during the first reflow, and that would then make the overflow
calculations in subsequent reflows work. It was only in cases where the
filtered frame was only reflowed once (such as when dynamically inserting a
filtered element into the DOM using script) that the lack of a valid frame
size during the overflow calculations would result in bad overflow regions
being calculated.
MozReview-Commit-ID: 79lR27KRSym
--HG--
extra : rebase_source : 9b232f68db1b21abae13758d4f345baa709641fd
nsLayoutUtils::GetDisplayRootFrame() can be quite expensive to call.
By calling this function one level higher (in callers and passing the return
value to callees), we can avoid calling it twice per call to SchedulePaint().
nsContentUtils::GetHTMLEditor() currently returns nsIEditor* since editor of doc shell may be any type of editors such as TextEditor or editor object which is implemented by JS. However, nsIEditor is now a builtin class. So, it can return HTMLEditor.
MozReview-Commit-ID: 3YoFOplZa7W
--HG--
extra : rebase_source : 46f42d23babd64bf0a5003e66e8fe3b9e0bd7166
This patch moves measurement of ComputedValues objects from Rust to C++.
Measurement now happens (a) via DOM elements and (b) remaining elements via
the frame tree. Likewise for the style structs hanging off ComputedValues
objects.
Here is an example of the output.
> ├──27,600,448 B (26.49%) -- active/window(https://en.wikipedia.org/wiki/Barack_Obama)
> │ ├──12,772,544 B (12.26%) -- layout
> │ │ ├───4,483,744 B (04.30%) -- frames
> │ │ │ ├──1,653,552 B (01.59%) ── nsInlineFrame
> │ │ │ ├──1,415,760 B (01.36%) ── nsTextFrame
> │ │ │ ├────431,376 B (00.41%) ── nsBlockFrame
> │ │ │ ├────340,560 B (00.33%) ── nsHTMLScrollFrame
> │ │ │ ├────302,544 B (00.29%) ── nsContinuingTextFrame
> │ │ │ ├────156,408 B (00.15%) ── nsBulletFrame
> │ │ │ ├─────73,024 B (00.07%) ── nsPlaceholderFrame
> │ │ │ ├─────27,656 B (00.03%) ── sundries
> │ │ │ ├─────23,520 B (00.02%) ── nsTableCellFrame
> │ │ │ ├─────16,704 B (00.02%) ── nsImageFrame
> │ │ │ ├─────15,488 B (00.01%) ── nsTableRowFrame
> │ │ │ ├─────13,776 B (00.01%) ── nsTableColFrame
> │ │ │ └─────13,376 B (00.01%) ── nsTableFrame
> │ │ ├───3,412,192 B (03.28%) -- servo-style-structs
> │ │ │ ├──1,288,224 B (01.24%) ── Display
> │ │ │ ├────742,400 B (00.71%) ── Position
> │ │ │ ├────308,736 B (00.30%) ── Font
> │ │ │ ├────226,512 B (00.22%) ── Background
> │ │ │ ├────218,304 B (00.21%) ── TextReset
> │ │ │ ├────214,896 B (00.21%) ── Text
> │ │ │ ├────130,560 B (00.13%) ── Border
> │ │ │ ├─────81,408 B (00.08%) ── UIReset
> │ │ │ ├─────61,440 B (00.06%) ── Padding
> │ │ │ ├─────38,176 B (00.04%) ── UserInterface
> │ │ │ ├─────29,232 B (00.03%) ── Margin
> │ │ │ ├─────21,824 B (00.02%) ── sundries
> │ │ │ ├─────20,080 B (00.02%) ── Color
> │ │ │ ├─────20,080 B (00.02%) ── Column
> │ │ │ └─────10,320 B (00.01%) ── Effects
> │ │ ├───2,227,680 B (02.14%) -- computed-values
> │ │ │ ├──1,182,928 B (01.14%) ── non-dom
> │ │ │ └──1,044,752 B (01.00%) ── dom
> │ │ ├───1,500,016 B (01.44%) ── text-runs
> │ │ ├─────492,640 B (00.47%) ── line-boxes
> │ │ ├─────326,688 B (00.31%) ── frame-properties
> │ │ ├─────301,760 B (00.29%) ── pres-shell
> │ │ ├──────27,648 B (00.03%) ── pres-contexts
> │ │ └─────────176 B (00.00%) ── style-sets
The 'servo-style-structs' and 'computed-values' sub-trees are new. (Prior to
this patch, ComputedValues under DOM elements were tallied under the the
'dom/element-nodes' sub-tree, and ComputedValues not under DOM element were
ignored.) 'servo-style-structs/sundries' aggregates all the style structs that
are smaller than 8 KiB.
Other notable things done by the patch are as follows.
- It significantly changes the signatures of the methods measuring nsINode and
its subclasses, in order to handle the tallying of style structs separately
from element-nodes. Likewise for nsIFrame.
- It renames the 'layout/style-structs' sub-tree as
'layout/gecko-style-structs', to clearly distinguish it from the new
'layout/servo-style-structs' sub-tree.
- It adds some FFI functions to access various Rust-side data structures from
C++ code.
- There is a nasty hack used twice to measure Arcs, by stepping backwards from
an interior pointer to a base pointer. It works, but I want to replace it
with something better eventually. The "XXX WARNING" comments have details.
- It makes DMD print a line to the console if it sees a pointer it doesn't
recognise. This is useful for detecting when we are measuring an interior
pointer instead of a base pointer, which is bad but easy to do when Arcs are
involved.
- It removes the Rust code for measuring CVs, because it's now all done on the
C++ side.
MozReview-Commit-ID: BKebACLKtCi
--HG--
extra : rebase_source : 4d9a8c6b198a0ff025b811759a6bfa9f33a260ba
Use |GetUsedBorder| instead of |GetComputedBorder|
when we calculate the position for position:absolute child.
MozReview-Commit-ID: 75gq5SFOVqT
--HG--
extra : rebase_source : 3b22920300f1054d3d2738e42c0347032bd9cecb
nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
--HG--
extra : rebase_source : 5fff9f2c6844559198f601853f8db08564add7d5
This removes about 2/3 of the occurrences of nsXPIDLString in the tree. The
places where nsXPIDLStrings are null-checked are replaced with |rv| checks.
The patch also removes a couple of unused declarations from
nsIStringBundle.idl.
Note that nsStringBundle::GetStringFromNameHelper() was merged into
GetStringFromName(), because they both would have had the same signature.
--HG--
extra : rebase_source : ac40bc31c2a4997f2db0bd5069cc008757a2df6d
This mechanically replaces nsILocalFile with nsIFile in
*.js, *.jsm, *.sjs, *.html, *.xul, *.xml, and *.py.
MozReview-Commit-ID: 4ecl3RZhOwC
--HG--
extra : rebase_source : 412880ea27766118c38498d021331a3df6bccc70
This patch move common canvas interfaces out of layer. So I create a
base class CanvasRenderer which move interfaces from CanvasLayer.
CopyableCanvasRenderer from CopyableCanvasLayer, ClientCanvasRenderer
from ClientCanvasLayer and WebRenderCanvasRenderer from
WebRenderCanvasLayer. And finally, WebRenderCanvasRendererSync for the
non layers free mode and WebRenderCanvasRendererAsync for the layers
free mode.
Summary all changes in this patch.
* Move class CanvasLayer::Data to CanvasRenderer.h and rename it to
CanvasInitializeData. Because this class not only use by layer but also
* Move BasicCanvasLayer::UpdateSurface to
CopyableCanvasRenderer::ReadbackSurface.
* CanvasClient::Update now accepts ShareableCanvasRenderer as parameter.
not CanvasLayer.
use by layers-free mode. Move it out of layer's class makes more sense.
* Add InitializeCanvasRenderer in the canvas related classes to
initialize CanvasRenderer without involved layer.
* All canvas layer has function "CreateCanvasRendererInternal" that
initialize corresponding CanvasRenderer.
* Description of all CanvasRenderer classes:
** CanvasRenderer: Based classes.
** CopyableCanvasRenderer: Can readback canvas content to a
SourceSurface. Use by BasicCanvasLayer.
** ShareableCanvasRenderer: Provide IPC capabilities that allow sending
canvas content over IPC. This is pure virtual class because the IPC handling is
different in different LayerManager.
** ClientCanvasRenderer: Implement IPC handling for ClientLayerManager.
Use by ClientCanvasLayer.
** WebRenderCanvasRenderer: Implement IPC handling for
WebRenderLayerManager.
** WebRenderCanvasRendererSync: Use by WebRenderCanvasLayer.
** WebRenderCanvasRendererAsync: Use by layers-free mode in WebRender.
class diagram shows below:
+--------------+
|CanvasRenderer|
+-------+------+
^
|
+----------------------+
|CopyableCanvasRenderer|
+----------------------+
^
|
+-----------+-----------+
|ShareableCanvasRenderer|
+-----+-----------------+
^ ^
+-------------+ +-------+
| |
+--------------------+ +---------+-------------+
|ClientCanvasRenderer| |WebRenderCanvasRenderer|
+--------------------+ +--------+--+-----------+
^ ^
+-----------------------+ +----+
| |
+-------------+-------------+ +-------------+--------------+
|WebRenderCanvasRendererSync| |WebRenderCanvasRendererAsync|
+---------------------------+ +----------------------------+
MozReview-Commit-ID: 5hqQ19W169r
Some benchmarks & use-cases cause nsTextFrame::CharacterDataChanged to be
called multiple times for the same text between reflows. Each call triggers a
slightly-expensive call to shell->FrameNeedsReflow(), for each affected
nsTextFrame in the continuation chain. (OK, it's not quite that bad -- we
skip the FrameNeedsReflow calls for siblings, since the ancestor
notifications/tweaks would all be the same.)
This patch makes us set a flag on the nsTextFrame to indicate that a reflow has
*already* been requested by this chunk of code, and we'll now use that to skip
the FrameNeedsReflow() call (and the dirty-bit-setting for siblings) on the
next invocation. And we clear this new flag when the pending reflow actually
happens.
This shouldn't change behavior in a web-observable way, but it should speed
things up by removing redundant work.
MozReview-Commit-ID: 5nmbZHEFFDi
--HG--
extra : rebase_source : 1f40abbc9eb90713095d2aff63f5a54a634e5aea
This patch doesn't affect behavior at all -- it just adjusts the logic
slightly. Specifically, this patch:
(a) Changes some code that currently tracks a frame, to now instead track that
frame's parent, since we only ever call GetParent() on it anyway.
(b) Drops a null-check that becomes unnecessary as a result of that
change. (It was only there to protect us from calling GetParent() on a
null pointer during the first loop iteration, and now that's not a risk
since we're tracking the parent itself, and a null value will fail the
equality comparison and do the right thing.)
(c) Captures the "are ancestors already aware of a reflow request for my
subtree" if-condition in a named boolean helper-variable.
(d) Adds/improves documentation.
MozReview-Commit-ID: 7dEflfiERYB
--HG--
extra : rebase_source : 0981952a6fa08f6c995ea6e21dd0cef4f6934bdc
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
The style contexts are already correct here; the frame constructor ensures that.
MozReview-Commit-ID: CWO225MB6Pe
--HG--
extra : rebase_source : ebc74ab507aaad6ac4c301cbbcdcab30ad3034d0
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 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
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
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
I was about to assert that other non-primary frames don't have additional style
contexts everywhere, but that wouldn't make much sense, given they don't
correspond to an element we could selector-match against.
MozReview-Commit-ID: EtAQbSg6nP6
--HG--
extra : rebase_source : e9e10c53b7a69506750bd3c7c985946f7027dc30
DOM Standard defines that offset of Range is unsigned long. However, nsRange uses int32_t to them.
This patch makes nsRange use uint32_t instead. However, this patch does NOT allow to set over INT32_MAX as offset values since a lot of users of nsRange cannot treat the values as over INT32_MAX because a lot of internal APIs take int32_t as offsets.
For easier to search such points, this patch adds static_cast<int32_t> to uint32_t variables when they are used for int32_t arguments.
And note that nsContentUtils::ComparePoints() behaves odd. It accepts negative offset and compares such value with valid offset simply. This patch still uses int32_t offset variables in nsRange::CompareNodeToRange() even though it may be negative value if nsINode::IndexOf() returns -1 because the caller of it depends on this behavior.
MozReview-Commit-ID: 8RbOgA86JuT
--HG--
extra : rebase_source : 46d526c6d50dfa2f104439b19b8691477b17a4af
Call gfxPrefs::LayersAllowTextLayers before aBuilder->GetWidgetLayerManager,
which is costly. Since LayersAllowTextLayers returns false by default, we are
free of using aBuilder->GetWidgetLayerManager.
MozReview-Commit-ID: Jv1voPYjOad
--HG--
extra : rebase_source : b4892a8800d71eeac5f30b8425954505cade31e6
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
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
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
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
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
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
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
This fixes an incremental layout bug, where the number of times we
reflow the frame affects its layout. This is because we make the
decisions about the vertical scrollbar before the horizontal scrollbar
(and, when making the decision, adjust mHelper.mScrollPort for the size
of the scrollbar). Thus, in order to avoid a situation where reflowing
the scrollframe once leads us to have no vertical scrollbar, but
reflowing it a second time leads us to add that scrollbar, we need to
retest for the need for a vertical scrollbar after we add the horizontal
one.
(It's possible there are some other missing cases here, but this is the
one that (a) already existed in the code and (b) is needed to fix the
reftest failure on Windows that I got on bug 1308876, in
layout/reftests/text-overflow/xulscroll.html .
The reftest here shows the bug even without bug 1308876 (though I
confirmed that only by loading the test and reference in a nightly
build, not in the reftest harness). I did test that, in combination
with bug 1308876, the test fails without the patch and passes with the
patch.
MozReview-Commit-ID: LhMi7LbmB6J
ScrollFrameHelper::DecideScrollableLayer doesn't get the actual value of usingDisplayPort/wasUsingDisplayPort if we are not painting to the window. It then sets mWillBuildScrollableLayer to usingDisplayPort. mWillBuildScrollableLayer is the value that determines if we are active and hence an ASR, we don't want to change that between paint display lists for an event handling display list.
We then want to condition uses of mWillBuildScrollableLayer and the return value of DecideScrollableLayer on if we want painting to the window so we get the same behaviour as before when not painting to the window.
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
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
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
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
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
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
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
Boris Zbarsky
Wes Kocher
Alexis Beingessner
Ehsan Akhgari
Masayuki Nakano
Bobby Holley
Matt Woodrow
Nicholas Nethercote
Sebastian Hengst
Bas Schouten
Eric Rahm
Emilio Cobos Álvarez
Kevin Chen
Ethan Lin
Bevis Tseng
Botond Ballo
cku
Michael Kaply
Milan Sreckovic
Xidorn Quan
Carsten "Tomcat" Book
Ya-Chieh Wu
J. Ryan Stinnett
Jonathan Kew
Masatoshi Kimura
Morris Tseng
Jonathan Watt
Timothy Nikkel
Daniel Holbert
Nicolas Silva
James Willcox
Kyle Machulis
Manish Goregaokar
Mason Chang
Tobias Schneider
Yoshi Huang
Sylvestre Ledru
Kartikaya Gupta
Kris Maglione
Ryan VanderMeulen
Cameron McCormack
Andrew Osmond
Ryan Hunt
Christoph Kerschbaumer
L. David Baron
Mats Palmgren
Jeff Muizelaar
Hiroyuki Ikezoe