This testcase used to fatally assert, but doesn't anymore. Hooray!
Let's keep it that way.
--HG--
extra : rebase_source : dad40f528fc56b0d8c4430053d87fbbc4873fe40
extra : amend_source : 8417dcfd116303645fe3d2825e94d2ddf5c3123d
We expose the relevant APIs on textarea and input elements anyway
(chromeonly). The QIs will throw on a non-input or non-textarea element, but
none of these consumers expect that to happen.
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
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
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
