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
XPCShell allows interaction with object that are cycle collected, but we never run the
cycle collector in it. In XPCShell we don't call nsJSContext::EnsureStatics.
nsJSContext::EnsureStatics is responsible for setting DOMGCSliceCallback as a GC callback,
which we need for running the cycle collector.
--HG--
extra : rebase_source : 5f12c15dabf3b23d9e4b1d8d88920e476d2d4bd6
Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
--HG--
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/MessageBroadcaster.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/MessageBroadcaster.h
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/ParentProcessMessageManager.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/ParentProcessMessageManager.h
rename : dom/base/ChromeMessageSender.cpp => dom/base/ProcessMessageManager.cpp
rename : dom/base/ChromeMessageSender.h => dom/base/ProcessMessageManager.h
extra : rebase_source : 6694ae975bc2af1b496db6b8cef645ec62582d9a
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
Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
--HG--
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/MessageBroadcaster.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/MessageBroadcaster.h
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/ParentProcessMessageManager.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/ParentProcessMessageManager.h
rename : dom/base/ChromeMessageSender.cpp => dom/base/ProcessMessageManager.cpp
rename : dom/base/ChromeMessageSender.h => dom/base/ProcessMessageManager.h
extra : rebase_source : d19120fb59b413aecf4e78aee8dc845022cd84dd
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
In this case we have a shadow hoot with display: contents, with no children.
Those children wouldn't be flattened tree children of the shadow host.
Instead of using the last light dom child and seek to it, use
FlattenedChildIterator's reverse iteration.
MozReview-Commit-ID: 18XL5Ong7ww
--HG--
extra : rebase_source : 2d34bd5b1fdd509a069ffa5052a7b7b3302be24c
