The assert is testing that the content's primary frame shouldn't
generate any native anonymous children, but what we really want to
ensure is that :-moz-column-span-wrapper doesn't create any native
anonymous child (because we don't restyle the wrapper), not the content
which creates ::-moz-column-span-wrapper. The condition is already
guaranteed by !aFrame->HasAnyStateBits(NS_FRAME_OWNS_ANON_BOXES) above.
Also, at this point during the frame construction, we haven't associate
the content with the its primary frame. Therefore,
nsContentUtils::AppendNativeAnonymousChildren() won't return anything
except for scrollbars on root element. That's why we have the crash in
this bug.
Differential Revision: https://phabricator.services.mozilla.com/D12359
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the following functions:
* nsContentUtils::IsCustomElementsEnabled()
* CustomElementRegistry::IsCustomElementEnabled(JSContext* aCx, JSObject* aObject)
* CustomElementRegistry::IsCustomElementEnabled(nsIDocument* aDoc)
and all references of the pref.
Depends on D11183
Differential Revision: https://phabricator.services.mozilla.com/D11249
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch make nsCSSFrameConstructor::CreateGeneratedContentItem() early
returns if the originating element contains an UA Widget shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D6828
--HG--
extra : moz-landing-system : lando
We're traversing primary frames, which are first continuations, so we can't
start from a continuation and expect to get to it. Add an assertion that would
catch further fishyness.
Differential Revision: https://phabricator.services.mozilla.com/D6672
--HG--
extra : moz-landing-system : lando
For browser.xhtml, we have extra whitespace text nodes that appear inside of
mBoundElement, which was causing XBL content to be incorrectly dropped.
Differential Revision: https://phabricator.services.mozilla.com/D5546
--HG--
extra : moz-landing-system : lando
To avoid its deferred reflow potentially killing continuations that are parented
to the parent of the letter frame.
This rolls back to the behavior previous to bug 488725 just for this case, until
we fix it properly in bug 1490281. This also fixes bug 1489863.
Differential Revision: https://phabricator.services.mozilla.com/D5521
We'll re-do the line anyway, and we'll forget about all the already-positioned
floats in the line DoReflowInlineFrames anyway.
Differential Revision: https://phabricator.services.mozilla.com/D4457
--HG--
extra : moz-landing-system : lando
This crash happens because nsVideoFrame didn't know what to do with two
children in the UA Widget Shadow Root.
The two children are both videocontrols, with the first one being the lingering
DOM inserted by first constructor call that throws.
The subsequent appendChild of the same element caused the videocontrols
to be initialized again, since the previous run didn't return a widget
instance to UAWidgetsChild.
The fix here removes the throw statement added in
https://hg.mozilla.org/mozilla-central/rev/dca187f7c72c#l3.15 ,
allowing the constructor to complete.
Without this statement, we will rely on assertion in the test here
https://hg.mozilla.org/mozilla-central/rev/4ddca5eb06c2#l2.18
to fail on slower platforms to ensure the stylesheet is loaded synchronously.
An alternative fix would be to wrap up the contructor in a try catch block
from UAWidgetsChild and make sure the DOM is cleaned up when the constructor
throw. That however will hide the error thrown so I decided to remove the throw
statement instead.
Differential Revision: https://phabricator.services.mozilla.com/D3560
--HG--
extra : moz-landing-system : lando
The key difference is checking the overflow lists from the next in flows, which
is something that PullOneFrame does but ReflowInlineFrame didn't.
MozReview-Commit-ID: I1JwOOeIBo9
Most of the removed tests are specific to listbox code, some are related to fixes already covered elsewhere, and some have no associated fix and were originally checked in just for good measure.
MozReview-Commit-ID: 3AQXoKy6HhU
--HG--
extra : rebase_source : 88781275bfdb436c0bb4249972435ad74e95002e
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
