In particular, split the computation of the resolved stops into its own
function, and inside of it, the switch computing the specified length of a
gradient too, since in bug 1352643 there'll be two of those.
MozReview-Commit-ID: FSYzzAxNBbV
--HG--
extra : rebase_source : 9b3a0dc89c5c107adfa9a5e3743a709d3cac240c
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
Patch originally developed on bug 1458921 but needs to land with the WR update.
MozReview-Commit-ID: 82BYyNWBAfn
--HG--
extra : rebase_source : e6bca2f446c019fd41a37c2c28db73bbe1cfc216
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
This ensures that the nsDisplaySVGWrapper's mFrame and its reference frame are the same frame: the nsSVGOuterSVGAnonChildFrame.
It'll also cause the nsDisplaySVGWrapper to be *inside* the nsDisplayTransform for the <svg> element's viewbox transform.
This patch reverts nsSVGOuterSVGFrame::BuildDisplayList to its pre-bug 1407938 form.
(That's the bug that introduced nsDisplaySVGWrapper.)
MozReview-Commit-ID: 3jCyP6Sj8x9
This is caused by an existing bug (bug 1458353) about the fact that we treat 2d transforms in
SVG as isolated groups. In this test, that bug didn't manifest because the viewbox transform
happened to be the identity matrix. Now that we no longer treat identity viewbox transforms as
special, bug 1458353 starts affecting this test.
MozReview-Commit-ID: JEYtsqvBTwI
I don't think this part is necessary, but putting the patch up in case we decide we want to take it.
MozReview-Commit-ID: G0JTNddvZma
--HG--
extra : rebase_source : 442a6a563044c2c510f332f881d9fab55c4455be
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
We will still crash in Nightly/DevEdition builds (so that we can fix the bug), but we'll just accept the possible duplication of items (and maybe minor rendering issues) for releases.
MozReview-Commit-ID: LNzjO8vJjGp
--HG--
extra : rebase_source : 3a755c0929bba42c0f6148e50f8d16567eea87e5
This adds several tests to ensure that computation of float areas for
shape-outside shapes works for elements that are offset from their containing
block.
(Part of original patch relanded by dbaron in the correct master directory.)
Instead of just storing the gfx::Matrix from the nsDisplayTransform on
the stacking context for scrolldata use, we now store a pointer to the
entire nsDisplayTransform item. We will need this in the next patch.
This patch should not have any functional changes.
MozReview-Commit-ID: 7qsZpL3Ka0X
--HG--
extra : rebase_source : b42957c83ef0591e72fa5b58ceb6650fda96e0b2
Those classes are only applied when !IsSingleLineTextControl(). No need for the
rules.
MozReview-Commit-ID: KOIWJVaw4pt
--HG--
extra : rebase_source : f4c738b7b1637c9cc7ad6958b53705cd82966864
Only <textarea> has GetWrapRows() > 0, and the rule for textarea disappeared in
bug 82711.
MozReview-Commit-ID: ERcoLVcufbH
--HG--
extra : rebase_source : 687ae89ce94e0e7f3682f434264661f7b9554819
Using concrete class types with static IIDs in QueryInterface methods is a
pretty common pattern which isn't supported by any existing helper macros.
That's lead to separate ad-hoc implementations, with varying degrees of
dodginess, being scattered around the tree.
This patch adds a helper macro with a canonical (and safe) implementation, and
updates existing ad-hoc users to use it.
MozReview-Commit-ID: HaTGF7MN5Cv
--HG--
extra : rebase_source : ace930129d85960d22bc3048ca3bb19bbbd4a63e
extra : histedit_source : 03a87f746d957789d41381e4e1bfcc4fd7eebaf2%2C9c5bae9feeeef7721105db67be0f83e0ded66bb7
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : source : 653c6b7480997c4e1dbead5f0441bc06a0605b7a
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 540e68ffff618a6dc3c14b3702b2c042988061a3
These properties no longer use calc() as an intermediate value as long as the
types of the values match.
But they don't resolve percentages to pixels in getComputedStyle as
transform-origin and perspective-origin.
MozReview-Commit-ID: 1CtN10ctGPF
