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.
