The DoMouseClick helper is also removed because no other caller can now pass a null aEvent. Other MouseClicked implementations are also updated since aEvent cannot be null, which was already the case.
MozReview-Commit-ID: 3bTJ6cZW9ZA
--HG--
extra : rebase_source : ae1bafe7144f6f428e2ef4e7047d5c64e0a19e8c
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
It's write-only, and I'd love to use it for other purposes :)
MozReview-Commit-ID: KpXNp72TcDb
--HG--
extra : rebase_source : 0bc1b00e69eb58b5ae5fe4ea9ec0b3b0970beb6c
We only set lazilySetParentPointer on the first reflow, then only call
DrainSelfOverflowListInternal on non-first reflows.
MozReview-Commit-ID: 364IwDoPE3W
--HG--
extra : rebase_source : 6551f2a3bbe080582de525f4c095bc60868c1a49
This patch accomodates for the unfortunate fact that elements with
"table-layout:fixed" have a max-content size of nscoord_MAX (infinity,
effectively), which turns out to be an easy source of integer overflow during
flex layout.
Before this patch, a flex container with "table-layout:fixed" in several flex
items could end up triggering integer-overflow & making the wrong judgement on
its arithmetic to determine...
- whether a given flex item will fit on an existing flex line.
- whether we've got positive free space and need to grow our items, or have
negative free space and need to shrink our items.
This patch makes two changes to fix this issue.
(1) This patch makes us use CheckedInt when summing up flex item hypothetical
sizes, which prevents integer overflow from flipping the sign of our line's
total length.
(2) This patch makes us *directly* track the space reserved for flex item
margin/border/padding within a flex line. Previously, we tracked this
implicitly as the difference between two other quantities that we stored;
but with the other changes in this patch, those two other quantities can
*both* trigger overflow and get clamped, which would make us lose track of
how much space to reserve for margin/border/padding. So now we simply
track that space-to-reserve directly.
MozReview-Commit-ID: 9izhOnlS4F1
--HG--
extra : rebase_source : 185f2409dcb2f9c5bd0a2466a8e2233d7db3250a
The frame is notified via its mListener, which is an observer of the
nsImageLoadingContent (mContent).
This last one only notifies for the current and pending requests, otherwise it's
a bug we need to fix there, not wallpaper here, since that'd mean that we forgot
to cancel the previous request. Added assertions to that effect.
Notify() is only called with the this object as a first argument from
imgRequestProxy, so it'd better be non-null, too.
MozReview-Commit-ID: DHaOLph2EAo
So that the imageLoader code is all grouped together. LoadIcons should probably
be a static, and the change shouldn't have any observable behavior.
MozReview-Commit-ID: Anxe8c5OfLe
Before that we were not notifying the image frame in any way if we ended up not
doing a load, and we were instead relying on the reflow the viewport resize
caused to get the new density in ComputeSize from the content node (but nowhere
else, since that's the bug part 1 fixes).
This was generally unsound, since you can stash random media in a sizes=
attribute, which don't necessarily needs to cause a reflow.
Now we need to notify necessarily because nsImageFrame stores the adjusted
intrinsic size.
mCurrentDensity could also get out of sync as well, when the selected image
density changed, but we ended up returning early because our source hadn't
change in the first early exit.
This patch moves us to a model where we don't re-trigger loads for density
changes if the source doesn't change (unless we pass aAlwaysLoad when we need
to, per spec).
This matches our previous behavior (without the bugginess of not updating the
intrinsic size), and also Chromium, at least.
This changes behavior in one case, which is when we don't load the same source
node, but we have the same source URL, and the density does change. This could
happen with <picture> and two <source>s with same source and different media and
sizes. This makes our behavior consistent with the behavior we have when both
the source and the density doesn't change.
Blink and WebKit do trigger a second image load both when the source changes
without changing density and when density changes. I'll file a spec issue, since
per:
https://html.spec.whatwg.org/#reacting-to-environment-changes
We should be triggering the load when the density changes but the source
doesn't as well, but no UA does that.
I filed https://github.com/whatwg/html/issues/3709 with a little summary of the
situation and what I think the behavior should be (which is what this patch
implements). That being said, I'll update the impl if the spec people think
otherwise :).
MozReview-Commit-ID: Eqy16ygHRLo
Only doing it in ComputeSize (via GetNaturalSize) is unsound, and the rest of
the users of mIntrinsicSize definitely do need scaling accounted for.
Move the adjustment to nsImageFrame for two reasons:
* Prevents adding more dependencies from nsIImageLoadingContent, which
otherwise would need to go away anyway in bug 215083.
* Avoids having to duplicate the image orientation logic, since mImage is
already an OrientedImage if needed.
MozReview-Commit-ID: EA0n0TctZhN
If the mMayHaveOpacityAnimation is false there, we don't need to check opacity
animations at all.
MozReview-Commit-ID: LTYPPXzF8V6
--HG--
extra : rebase_source : ee2c90e04003140944fb4cc255aa3c6f1c07f0b0
Currently, NAC always inherits from the closest non-NAC ancestor element,
regardless of whether it is for an element-backed pseudo or not.
This patch changes the inheritance so that for element-backed pseudos, we
inherit from the closest native anonymous root's parent, and for other NAC we
inherit from the parent.
This prevents the following two issues and allows us to remove the
NODE_IS_NATIVE_ANONYMOUS flag:
* Avoiding inheriting from the non-NAC ancestor in XBL bindings bound to NAC.
- This is no longer a problem since we apply the rule only if we're a
pseudo-element, and all pseudo-elements are in native anonymous subtrees.
- This also allows to remove the hack that propagates the
NODE_IS_NATIVE_ANONYMOUS flag from the ::cue pseudo-element from
BindToTree.
* Inheriting from the wrong thing if we're a nested NAC subtree.
- We no longer look past our NAC subtree, with the exception of
::-moz-number-text's pseudo-elements, for which we do want to propagate
::placeholder to.
A few rules from forms.css have been modified because they're useless or needed
to propagate stuff to the anonymous form control in input[type="number"] which
previously inherited from the input itself.
MozReview-Commit-ID: IDKYt3EJtSH
nsDisplayListBuilder::DisplayCaret returning true means that we set canSkipWrapList to true, and then we build an nsDisplayWrapList.
We need to make sure we're invalidated for this changing in nesting level to be handled.
MozReview-Commit-ID: 4j3WIJDcHtI
--HG--
extra : rebase_source : b64d0af756c297de42aa2e164ee32ccbe01890d1
