Dynamic changes are handled correctly because content property changes already
cause a reframe.
This implements the same bits as Blink / WebKit do (single content item which is
an image, otherwise gets ignored), except for the edge cases where you use this
on an image.
In order to handle the edge cases right, we completely isolate the
nsImageLoadingContent usage based on `mKind`.
Blink's and WebKit's behavior there makes no sense and it's erratic, what I
implemented is consistent (we apply to images as long as they don't generate a
box, and we don't look at alt text or broken icons), though I'll update to
whatever the WG decides in https://github.com/w3c/csswg-drafts/issues/2831 /
https://github.com/w3c/csswg-drafts/issues/2832.
I don't think it matters in terms of web compat in any case.
MozReview-Commit-ID: JUurhC60hWr
The methods where it's used don't run from reflow (they're image notifications
that run off runnables and such), so should be an idempotent change.
MozReview-Commit-ID: LdmSOcKDdw1
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
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
nsIFrame::mClass is of type enum class nsQueryFrame::ClassID which is
a strict subset of the nsQueryFrame::FrameIID values. For a concrete
frame class, its FrameIID is the same numeric value as its ClassID.
MozReview-Commit-ID: 1N0AkCGo1ol
