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
There are two issues being fixed here. First, if DisallowBFCaching is called
before CanSavePresentation, we should really return false from
CanSavePresentation. Otherwise we'll end up doing a bunch of state-capturing
work for no reason.
Second, if DisallowBFCaching is called between CanSavePresentation and
nsDocumentViewer::Destroy, we need to actually tear down the viewer state.
What we do right now is avoid putting the viewer into the SHEntry, but still
not tear down its presshell and so forth, which leads to asserts in
~nsDocumentViewer when this case is hit.
We should always have the pipeline information for in-process things like
async images, but for cross-process iframes we might not have the information
right away if the content process doesn't get around to sending it for a while.
MozReview-Commit-ID: 18F5nqilXoV
--HG--
extra : rebase_source : 610046cbaaefb38b8e11bda857fd64a00722df27
This value is used to determine whether we should create nsDisplayFixedPosition, and if the result changes without an invalidation, then retained-dl gets confused with the insertion/removal of a wrap list.
MozReview-Commit-ID: JuXwCzKOxec
--HG--
extra : rebase_source : a62a2ce003eb57582c8a11bffb6c0cb766c6db15
Even if the sticky item has a fixed descendant, we want to use the
sticky container item's "real" ASR when computing the WR clips because
otherwise the WR item doesn't get attached to the correct scrolling
layer.
MozReview-Commit-ID: JVnzEIBeLKp
--HG--
extra : rebase_source : 806e43eb65d46eb5151e21b0a5eb09168b2df82d
This moves reftest-preferences.js to:
testing/profiles/reftest/user.js
Developers can also now add extensions to:
testing/profiles/reftest/extensions
MozReview-Commit-ID: IVLsT5MWtcJ
--HG--
rename : layout/tools/reftest/reftest-preferences.js => testing/profiles/reftest/user.js
extra : rebase_source : 1725627d439998d92545e0d4693fbb76a266945f
This adds an assertion checking for duplicate items whenever we create an item, and when we merge an item into the final list.
I had to disable tracking for the anonymous inner list for nsDisplayPerspective and nsDisplayTransform (and manually forward RemoveFrame to them), as well as skipping the assertion for multi-page (since we can end up duplicating wrap lists, but isn't a problem, since we don't retain these).
MozReview-Commit-ID: 4n6rx9bQNan
--HG--
extra : source : ff93cd94b7c548ef57fa13b7eaf85992a0a60587
For doing this, ServoComputedData is split into separate files, so that
files don't need to include ServoBindings.h just for accessing style
structs from ComputedStyles.
MozReview-Commit-ID: DPAd7PUUCl9
--HG--
extra : rebase_source : 7d6f739b7fb58a46e1624ba62e717412057ea9c1
And also remove ComputedImageUrl::from_url_value_data.
MozReview-Commit-ID: 5zifQlU7tOz
--HG--
extra : rebase_source : 23631ad2e9144cf30951a3d07421a8e5ae0ba8ec
Both tests fail on WebRender without the fix in this patch series.
In the delay phase, those animations should be painted using non-animated
value (i.e. opacity:0 or translateX(100px)), but on WebRender they were painted
using opacity: 1 or identity transform.
MozReview-Commit-ID: DOHopfleWB0
--HG--
extra : rebase_source : 1075557f04d4ae1ce049e2c4513b00287ee9d4be
This adds an assertion checking for duplicate items whenever we create an item, and when we merge an item into the final list.
I had to disable tracking for the anonymous inner list for nsDisplayPerspective and nsDisplayTransform (and manually forward RemoveFrame to them), as well as skipping the assertion for multi-page (since we can end up duplicating wrap lists, but isn't a problem, since we don't retain these).
MozReview-Commit-ID: 4n6rx9bQNan
--HG--
extra : rebase_source : 49da303965d63258f4c6023a0b09ef0de7553724
Now that BeginUpdate is useless for the UPDATE_STYLE case, we don't need the
update mechanism at all. Just ensure that ApplicableStylesChanged is called on
the pres shell via the relevant RuleChanged, etc. notifications.
There's a big hidden gotcha here. nsIDocument::BeginUpdate does put a script
blocker on the stack for these updates. However it's not needed, since no script
can run during these notifications (only the stylesheet events we post for
devtools, but those use AsyncEventDispatcher and PostDOMEvents, so they don't
try to run immediately).
nsIDocument::BeginUpdate also does XBL binding attached queue stuff, but we
can't change bindings during these notifications anyway, so it also doesn't
matter.
MozReview-Commit-ID: HJvK6zQfloh
They're empty, and make PresShell::BeginUpdate useless. Now we don't have
document observers that listen for these anymore.
MozReview-Commit-ID: GpDDNonFUFC
We can unconditionally delete the item though, and just put a placeholder entry into the DAG.
MozReview-Commit-ID: 7a2UnaByIZu
--HG--
extra : rebase_source : f9cf83f09c1a6b9b23f469f7d3ab3a67f99f4018
This is needed to serialize computed URLs correctly from getComputedStyle.
MozReview-Commit-ID: 9wakhqNrszb
--HG--
extra : rebase_source : 7d120ac0917a5e13de4e52b7dfa0d784495fd8f7
We probably need more fixes for counters and Shadow DOM. The spec only mentions
"document order", and this is the most reasonable thing to do accounting for
shadow DOM in that regard...
This ensures a reasonable behavior for all callers which pretty much expect
otherwise for all children to be connected.
MozReview-Commit-ID: YEQIKdjRTK
--HG--
extra : rebase_source : 9b31f5d00d270cf21476776144d62350b5453f99
Removed comparison to NS_STYLE_BORDER_STYLE_NONE and replaced with NS_STYLE_TEXT_DECORATION_STYLE_NONE
--HG--
extra : rebase_source : 559d47c0379229c169c5da75d38db6850ff3d60b
These tests rely on an optimization within Gecko where it stops firing
MozAfterPaint events if there was no visible change to the generated
layers. This allows the reftest harness to exit the
waiting-for-MozAfterPaint loop and proceed with the test. However, with
webrender, this optimization does not exist and so the loop never exits.
In order to solve this problem, this patch adds an explicit mechanism to
exit the loop by means of a class attribute on the root element of the
test page.
MozReview-Commit-ID: 17ta5kLPDr9
--HG--
extra : rebase_source : 96ea462274724c6c65f1186f473bc1767253fd6b
It's been removed for a while on Nightly without any known regressions. This
gives us a full beta cycle of telemetry and two nightly cycles without the API
before shipping.
This only removes the API, followup work will replace serialization by Servo's,
and remove the remaining DOM interfaces.
MozReview-Commit-ID: 2m1taYg5xEr
Our implementation is totally not what the spec says, but totally what other
UAs do, see https://github.com/w3c/csswg-drafts/issues/2474.
So given this is causing webcompat pain, I think we should be pragmatic and just
unprefix this.
We could keep serialization and getComputedStyle with ::selection working with a
bit more effort, like we do for :-moz-placeholder, but I'd prefer not doing at
least the serialization bit, and just alias in nsCSSPseudoElements
:-moz-selection to selection too.
MozReview-Commit-ID: 6lxctozRDqv
We will remove animation.effect.timing in the next patch.
MozReview-Commit-ID: EyeFNM81NbN
--HG--
extra : rebase_source : 9fe5eb0e5d141ffffa017db255328c742a059611
MozReview-Commit-ID: CYeBKhDYD1F
The distance field does not calculate a true Euclidean distance, so it is
unreasonable to require that the intervals span all of the BStart() to BEnd()
float area. The final block pixel may not generate an interval at all due to
rounding errors. This change makes accomodation for the rounding errors and
adds asserts to ensure we aren't tolerating errors outside the area of the
last block pixel.
--HG--
extra : rebase_source : 114c1667861c90a055295f9bd40a3991cbb5dc88
Move from nsStyleColor::CalcComplexColor to StyleComplexColor::CalcColor.
MozReview-Commit-ID: FkYovvPZLc8
--HG--
extra : rebase_source : 54f1966e0ef9258f20e954cd6250774008eca04c
