The view is not guaranteed to have a frame (and won't during the early parts of the presshell's existence). It will have a view manager, and that will have a presshell during this time period.
Anytime a view has a frame it will also have a view manager and a pressshell so this is strictly better.
Having a non-null mInstanceOwner corresponds to when registration
normally happens (from nsPluginInstanceOwner::SetFrame), and it's
disconnecting the instance owner that leads to unregistration.
MozReview-Commit-ID: 3X15t9zoXIj
nsCaret::GetFrameAndOffset may return a text frame also when aParentNode
is the container of a text node and aOffset is just after it. In this
case we also want CARET_ASSOCIATE_AFTER if the text ends with
a significant newline. (follow-up from bug 1258308)
These new enum values are added with same behavior as their modern flexbox
equivalents -- they're hooked up to NS_NewFlexContainerFrame, and they're
listed alongside the modern flexbox enums in 'switch' & 'if' statements.
There's one exception, which I call out with a comment at the end of the patch:
we don't treat -webkit-box the same as flexbox in IsFlexOrGridDisplayType(),
because that method is used to determine whether we should blockify
inline-level children of a flex/grid container, and we don't want to blockify
any children of a -webkit-box. (Instead, we want to wrap them in an anonymous
flex item. That happens in the next patch.)
MozReview-Commit-ID: 9BB4Ib2KpvE
If the main summary element has 'display: none' style, it won't
generates a summary frame as the first child of the details.
However, if a details element have two summaries and the first summary
has 'display: none', the second summary still generates a SummaryFrame
event if it isn't the main summary. So instead of checking on the
SummaryFrame as before, I check the content tree for the main summary by
using the idea in bug 1245424 comment 8. Another reason might be the
potential removal of SummaryFrame in bug 1258657.
MozReview-Commit-ID: H0evZ17zj5k
--HG--
extra : rebase_source : 1aad3ad1d31dc277771013f92eace5cefa7d6112
nsFrameManager::CaptureFrameStateFor generates keys for stateful frames that
only take into account the document and element. This precluded saving pieces
of information coming from different frames responsible for the same element.
MozReview-Commit-ID: 29x3Gj66wAy
--HG--
extra : rebase_source : 9f6fc24ce88009b31dae9fc37bb2187cad8164f2
There were two problems in the existing code (which was exposed by tests
that dynamically insert/remove items). First, the situation when
we have some pushed items two or more fragments away and then pull up
those. This creates a "hole" in the child next-in-flow chain like so:
grid-container-frag-0
child1-frag-0
...
grid-container-frag-1
...
grid-container-frag-2
child1-frag-1
After we reflow grid-container-frag-0 and it's still incomplete we will
reflow its NIF, grid-container-frag-1, but it will "stall" since it
doesn't have a continuation for child1. We need to make sure to
always pull up a fragment for that child. That's what the first hunk
is about in the patch.
Second problem is the opposite problem of pushing a child into a NIF
container that already has an OC child continuation, like so:
grid-container-frag-0
OverflowList = { child1-frag-0 }
grid-container-frag-1
OverflowContinuationsList = { child1-frag-1 }
When we reflow grid-container-frag-1 we'll pull in child1-frag-0
like so:
grid-container-frag-0
...
grid-container-frag-1
PrincipalList = { child1-frag-0 }
OverflowContinuationsList = { child1-frag-1 }
This is bad since we'll consume BSize twice here. The fix is
to move it our ExcessOverflowContinuationsList instead, like so:
grid-container-frag-0
...
grid-container-frag-1
PrincipalList = { child1-frag-0 }
ExcessOverflowContinuationsList = { child1-frag-1 }
That's what the second hunk in this patch does.
Our "pre-reflow logical skip sides" assumes each fragment will be
the last and have a block-end border. We then skip the block-end
side at the end of Reflow if we're INCOMPLETE. This simplifies
the logic that checks how many rows fits in this fragment.
By moving GetAnimationCollection to AnimationCollection itself, we can remove
a bunch of virtual methods on the animation managers, simplify call sites,
and provide better type safety by ensuring a correspondence between element
property names and concrete animation types.
One change in behavior, however, is that in doing this we can no longer
add any newly-created AnimationCollection to the corresponding manager's linked
list of collections inside GetAnimationCollection. Instead we take a bool
outparam to indicate if a new collection was created and leave managing the
linked list to the manager. This is just a temporary measure, however, since
by the end of this patch series will will eliminate this linked list altogether
along with this flag.
MozReview-Commit-ID: 1jsc4QcmVDg
This patch templatizes the type of Animation stored in an AnimationCollection.
This allows us to remove a number AsCSSAnimation() calls in nsAnimationManager.
This patch also removes the AnimationPtrArray typedef. In its place we
introduce OwningCSSAnimationPtrArray and OwningCSSTransitionPtrArray but we
don't use these as widely. There was some comment previously that the typedefs
in animation code make it hard to read, particularly when these typedefs don't
make it clear if the data type is an owning reference or not.
In doing this we need to templatize CommonAnimationManager as well and move the
implementation of its (few) methods to the header file. We may be able to
remove the need for templatizing CommonAnimationManager later in this patch
series depending on how we ultimately decide to handle the lifetime of
AnimationCollection objects.
CommonAnimationManager::GetAnimationCollection is a bit messy but this will be
significantly tidied up in subsequent patches in this series.
MozReview-Commit-ID: 3ywatY53pRR
We're going to use it both for background-blend-mode and for mix-blend-mode.
MozReview-Commit-ID: 6zKCDSkLspc
--HG--
extra : rebase_source : 81b4691d2b74e56c634bdf08f85636ba2abbf486
This isn't really about regular clips, it's about scroll clips. If the inner
item has an unnecessary scroll clip (one that's already on the parent), this can
cause the inner item's bounds to be larger than necessary because, after the
first patch in bug 1238564, it will include the whole bounds of async-scrollable
scroll frames.
Also, if e.g. the inner item is an opacity item, and it has a scroll clip that's
not just the innermost ancestor scroll clip of all of its children, then
FrameLayerBuilder's mContainerBounds == mAccumulatedChildBounds assertion can
fail if the opacity item gets flattened away, because the child bounds won't
have been enlarged for the scroll clip.
There must be a better way to do the clip resetting in
nsFrame::BuildDisplayListForStackingContext - the code is not pretty at all.
But I'd rather get the tests passing first before we figure out how to clean it
up.
MozReview-Commit-ID: E1DdpN546va
--HG--
extra : rebase_source : ecf4774a47978fb0aa5ebde9346cf464ebc60ab6
extra : histedit_source : 9395ca5f74413d887df3b7fa54cad726742dca30
Always use an ancestor scroll clip of all direct children, or the original
scroll clip if the children don't share the same scroll clip tree.
Unfortunately this requires another pass over the stacking context display list.
Also, fix clips, scroll clips and creation order of blend items:
If a clipped mix-blend-mode item contains absolute / fixed positioned items,
those items should not be clipped, same for blend container items.
When a transform item contains blend modes, create the blend container inside
the transform.
Don't do tree comparisons on scroll clips from different scroll clip trees.
If the inner scroll clip is nullptr, because it was cleared, it will look like
it's the ancestor of the outer non-nullptr scroll clip.
These changes don't look very related, but it was very hard to get tests passing
with only some of the changes and not the others, and after having spent two
weeks on this patch I'm not thrilled about going back and checking exactly which
change was necessary to fix which test failure.
MozReview-Commit-ID: IKGciUBrdNa
--HG--
extra : rebase_source : e570f16ecedd80cba16051f0e1ac66764bc95815
extra : histedit_source : fcfbcbc254aaf93594d9d80c117d6ec945805993
This makes sure that for example the bounds of an opacity item are not empty if
the opacity item contains a scroll frame whose contents are currently scrolled
offscreen but still inside that scroll frame's display port.
On its own, this changeset causes test failures due to missed optimizations
because the bounds of many opacity items are now too large. That's because of
the way we're setting scroll clips on opacity items at the moment: Even if the
opacity is inside a scroll frame, we're currently only setting that scroll
frame's scroll clip on the opacity item's contents, not on the opacity item
itself, because the opacity item might also contain other items that are not
scrolled by this scroll frame.
The next patch in this bug will make us only do that when necessary.
MozReview-Commit-ID: 9TtcJ7eQE7U
--HG--
extra : rebase_source : 51cab60bd27e1a7e3c2d6b8d791b79fe3b3baa94
extra : histedit_source : ba421898e442d08f7f711d13f71a693c34d908bb
Although this makes some places more complicated, code should generally
be simpler and clearer. It could slightly improve performance on x64 for
functions with more than four parameters, since it makes more data be
passed via registers rather than the stack.
MozReview-Commit-ID: D0GM2Jyrr6W
--HG--
extra : source : bd88a2e478e23edf1845f724a32fef908c8cc007
Although this makes some places more complicated, code should generally
be simpler and clearer. It could slightly improve performance on x64 for
functions with more than four parameters, since it makes more data be
passed via registers rather than the stack.
MozReview-Commit-ID: D0GM2Jyrr6W
--HG--
extra : rebase_source : 29961e56b5fe14b244046b3dc52b1f922c206218
PGO builds on Visual Studio 2015 Update 1 did not take kindly to
MOZ_CONSTEXPR in this file, causing a startup crash (for reasons
I can't explain). Switching to literal "const" makes the crash
go away.
MozReview-Commit-ID: K1A43NIa6lG
--HG--
extra : rebase_source : 16c57ae79cb642b5d2945425144c726c119371b4
nsLayoutUtils::CalculateCompositionSizeForFrame() is not affected by the
document resolution when called for the root content document's root
scroll frame. When determining the root composition bounds in order to
calculate a displayport base, if the frame used is the RCD-RSF we must
be sure to scale the bounds ourselves by the document resolution.
MozReview-Commit-ID: ATctmEYvWIJ
--HG--
extra : rebase_source : ba96e7ecc2cefdbeacb08fbd3f5817819dd933c8
Bug 1241917 made it so that a subframe's displayport base is restricted
to the root composition bounds (in addition to its previous
restrictions). This involved an expensive coordinate transformation
causing a scrolling performance regression.
This avoids restricting the displayport base to the root composition
bounds unless the frame has a display port, avoiding the expensive
computation unless necessary.
MozReview-Commit-ID: FVacUscAfu2
--HG--
extra : transplant_source : %F9%E9%19%06/%9C%EA%8C%D1%D5%BD%ED%26C%97y%15%92%7E%CB
Pings are sent in the implementations of the nsISelectionController methods
ScrollLine, ScrollPage, ScrollCharacter, and CompleteScroll. It is assumed
that these methods are triggered by keyboard input.
A small number of false positives can occur if these methods are called
in response to something other than keyboard input; this is considered
acceptable.
--HG--
extra : commitid : JDXW8ptuXkF
extra : rebase_source : c45fe2b16484ad370edb852d8eafbc76ca7d0bac
extra : amend_source : b4af21228768221211a42c11a2ff306a6f2bb402
extra : histedit_source : 7cdc4b4df3579682fad194ddfc04c7a5d02c0d3e
Add helper function nsIFrame::In3DContextAndBackfaceIsHidden() which
checks both if a frame is backface-hidden and whether it is within a
3D-transform context.
In FrameLayerBuilder, check this function rather than BackfaceIsHidden()
to determine whether a frame needs a backface-hidden layer. This will
avoid creating unnecessary extra layers for non-3d-transformed items
which for some reason have backface-hidden set.
It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
- The VR specific render path in ContainerLayerComposite does not
handle nsBackdropFrame correctly, resulting in a alternate frame
strobing effect in the Oculus Headset. As VR content is composed
of a Canvas element that is scaled to the extents of the surface,
the backdrop would otherwise not have an effect for VR content,
which means we can simply suppress the backdrop.
MozReview-Commit-ID: 3bCTOApiH8E
--HG--
extra : rebase_source : 015e15dee2ac3235e1e571642d3988b66b97dfd1
CLOSED TREE
Backed out changeset dbadb8fe5803 (bug 1216001)
Backed out changeset a30593ebd58e (bug 1216001)
Backed out changeset c1646ffa71b4 (bug 1216001)
Previously displayport bases were computed as the intersection of the
scrollport with the dirtyrect. However the dirtyrect covers what is
rendered, and with displayports what we render can be much larger than
what is visible. With displayport bases intended to represent what was
visible, this was a problem. By restricting them to the root composition
size this makes them more closely match what is visible. To do this more
properly we'd want to intersect the dirtyrect with the scroll clip of
every ancestor scroll frame, not just the root composition bounds.
If a <details> lacks a direct <summary> child, we need to construct a
default one.
--HG--
extra : commitid : ApnP20Mrr33
extra : rebase_source : 4b059f4e7fa32bac665487aa8a266ba58597b184
What's happening here is that we enter an infinite loop by oscillating
between two states. The code assumes that (a) the available space will
never grow, only stay the same or shrink, and (b) that we should break
out of the loop if it stays the same. This also means we hit the
assertion about the available space growing every other time through the
loop.
This is in the inner loop in nsBlockFrame::ReflowBlockFrame that was
introduced in https://hg.mozilla.org/mozilla-central/rev/80ef9bb2c2e9 .
The problem is fundamentally a logic error in that code. The makes the
assumption that if you reduce the width available to a block formatting
context or replaced block-level element, its height does not shrink.
(The "replaced block" (really block formatting context) in this case, as
in the original testcase, is a scroll frame. I didn't debug the
original testcase enough to figure out what caused its sizing
characteristics, although a percentage-width image does seem like the
most likely candidate.)
Without the patch, the reftest test (but not reference) hangs, as does
the semi-simplified test in the bug (given a narrow window).
With the patch, neither the semi-simplified test in the bug nor the
reference hangs, and the reftest passes.
--HG--
extra : commitid : APy8PfXlvvz
nsImageFrame::OnSizeAvailable will update the intrinsic ratio and ask for a reflow. Then nsImageFrame::NotifyNewCurrentRequest will be called when the image is finished loading. It previously would do a predictive decode if the intrinsic size hadn't changed.
This was a mistake in http://hg.mozilla.org/mozilla-central/rev/146f1bea4147 (bug 1151359).
OnSizeAvailable has this structure:
if (intrinsicSizeChanged && gotInitialReflow) {
if (!sizeConstrained) {
requestReflow();
}
}
NotifyNewCurrentRequest has this structure:
if (gotInitialReflow) {
if (!sizeConstrained && intrinsicSizeChanged) {
requestReflow();
}
}
Bug 1151359 added a predictive decode in a new else branch to both inner if statements. The meaning of this is obviously quite different.
Since nsIFrame::GetChildList() is a const function, PrincipalChildList()
should be a const function as well.
--HG--
extra : commitid : Hjvhy6cUWTF
extra : rebase_source : 0a998e5420b81827e478b403744cd9e5a11eb584
By changing signature of those two functions, we make compiler complain about
all their existing uses, so we can find all of them and convert them.
Some of the callsites of Get() with those properties are also converted, but not
all of them. It is fine because if there is any incorrect conversion, compilers
is able to find out now. So they are completely typesafe.
--HG--
extra : source : 808415985d3d446f18941eb007a9be9d69d180ce
This patch makes methods of FramePropertyTable and FrameProperties to be
simple template wrapper functions. Then it converts all references to
FramePropertyDescriptor to use "void" parameter to simulate the current
unsafe behavior.
SmallValueHolder is used for storing small values like int32_t, float,
which can fit in the size of a pointer directly, and thus no lifetime
management is needed.
--HG--
extra : source : 88b2723cddf119d73d8a442d8238b50406e9d604
Note that nsMathMLContainerFrame and its subclasses are unchanged since
they are not target of fullscreen (and thus no backdrop frame), and they
have an assertion to ensure we really don't pass any unexpected list in.
--HG--
extra : source : a1f7ff18a69cc116120de33f14ae62f576a4b55a
Botond Ballo
Matt Woodrow
Timothy Nikkel
Jonathan Kew
Xidorn Quan
Kartikaya Gupta
Seth Fowler
Jeremy Chen
Daniel Holbert
L. David Baron
Masayuki Nakano
Ryan VanderMeulen
Nicholas Nethercote
Mats Palmgren
Markus Stange
Benoit Girard
Ting-Yu Lin
Jesse Ruderman
Kyle Machulis
Robert O'Callahan
Mike Hommey
Chris H-C
Carsten "Tomcat" Book
Tobias Schneider
Shih-Chiang Chien
Ehsan Akhgari
Brian Birtles
Nathan Froyd
Sebastian Hengst
Shing Lyu
Wes Kocher
Jonathan Watt
Jim Mathies
Gregory Szorc
Jamie Nicol
David Anderson
Alexander Surkov
Cameron McCormack
Boris Chiou
kearwood
Phil Ringnalda
Jet Villegas
Thinker K.F. Li
Karl Dubost
Geoff Brown
Oriol
Tobias Schneider
Birunthan Mohanathas
Kyle Huey
CJKu