If a ColumnSetWrapperFrame already has column-span children,
ColumnSetWrapperFrame::GetContentInsertionFrame() will return itself to
let WipeContainingBlock() aware this is the case to reframe.
To make this work, we need to move the reframe condition prior to check
NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit because the top level
ColumnSetWrapperFrame never has NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR bit
set.
Differential Revision: https://phabricator.services.mozilla.com/D14819
--HG--
extra : moz-landing-system : lando
The <iframe> in the test case is getting the "column-span:all" style,
but it's under a position:fixed frame subtree. After the patch in bug
1507244 landed, NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR won't be added
incorrectly to the out-of-flow subtree.
Differential Revision: https://phabricator.services.mozilla.com/D14626
--HG--
extra : moz-landing-system : lando
Support unprefixed min-content and max-content and treat the prefixed
version as aliases for
1. width, min-width, max-width if inline-axis is horizontal, and
2. height, min-height, max-height if inline-axis is vertical, and
3. inline-size, min-inline-size, max-inline-size, and
4. flex-basis.
Besides, update the test cases to use unprefixed max-content and
min-content.
Depends on D7535
Differential Revision: https://phabricator.services.mozilla.com/D7536
--HG--
extra : moz-landing-system : lando
Bug 1506163 fixed only part of the issue. There are more types of frames
such as table, grid, flex, etc. that create their own block formatting
context.
Instead of propagating NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR to the
children, we explicit carry the bit over to block and inline frames by
checking that their parent doesn't suppress column-span descendants.
Also, remove the unused "onload" from <body> in the tests.
Differential Revision: https://phabricator.services.mozilla.com/D13597
--HG--
extra : moz-landing-system : lando
Bug 1505887 changed the behavior here from content calling into nsFind via
window.find(), by making the SetStart and SetEnd calls here fail instead of
succeed for NAC (like the text in textareas).
This patch makes us handle that error gracefully moving on to the next match,
instead of trying to preserve the previous behavior.
This means that we'll fail to highlight textarea content and such from
window.find, which Chromium does, looks like. Though Chromium doesn't expose
the ranges as selection either. In any case I don't think that this is a very
common thing given bugs like bug 1442466, which this bug fixes.
I haven't found anything close to a spec for what window.find() should do... If
we decide to go with this patch then I'll add a crashtest for this and a test
for bug 1442466 as well. Otherwise I'll add a way to skip the security check in
nsFind somehow for NAC, or relax the security restrictions in SetStart /
SetEnd, I guess.
Differential Revision: https://phabricator.services.mozilla.com/D14013
--HG--
extra : moz-landing-system : lando
When removing an out of flow frame under a multicol subtree, it shouldn't affect
the multicol tree structure. We should instead check the in flow frame's
relationship with the multicol subtree.
Differential Revision: https://phabricator.services.mozilla.com/D11540
--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 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
We rely on the bit being on the block to restyle them in the right order.
Differential Revision: https://phabricator.services.mozilla.com/D7086
--HG--
extra : moz-landing-system : lando
We're trying to insert a table caption via an append into a display: contents
element. We pass the content-insertion-frame (the table frame) instead of the
siblings' parent (the table wrapper frame).
This is the right thing to pass though, we adjust the caption parent frame
later, on AdjustCaptionParentFrame, and we ensure that we don't get here for a
non-caption thing because of IsValidSibling (though note that that can actually
lie, see bug 1424656, we'd get the layout wrong if the title element was a
replaced element for example), so a normal append without a previous sibling
will still be correct.
It'd be nice to make this a bit less messy, fwiw, but I don't have the ideas or
the time to do it now.
Differential Revision: https://phabricator.services.mozilla.com/D7067
--HG--
extra : moz-landing-system : lando
Avoid processing anon content in nsCanvasFrame, then getting more anon content
via AccessibleCaretEventHub::Init. Instead call Init before creating the custom
content container. We could also throw a script runner at it I guess, but this
prevents the reentrancy issue.
Avoid cloning nodes during layout, just use the same node (already cloned in
InsertAnonymousContent) instead.
The RemoveChild in GetAnonymousContent to handle the reframes instead of cloning
around is a bit hacky, but I don't think it's really worth extending
PostDestroyData for this special case.
Differential Revision: https://phabricator.services.mozilla.com/D1889
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 preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
This gets set to a non-zero value when we have an inactive ContainerLayer ancestor (filter in this case).
The current code assumes we'd never call BuildLayer on an image when that happen, but we force the pseudo-active
state here because background-position is animated (all properties have a transition).
MozReview-Commit-ID: 6pL8EJTNgWy
--HG--
extra : rebase_source : 6370fc79d5f47f0b5c4bbe86c0b605b90256b653
Since the test relies on missing keyframes handling.
MozReview-Commit-ID: IfbMvRhIeOh
--HG--
extra : rebase_source : 447bec6c7bc8d8a79f00bb738182e0647ee68ec5
Continuations do not have placeholders. There's a bunch of code that already
deals with that in other places in the tree.
MozReview-Commit-ID: Htizql7692e
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
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
Ting-Yu Lin
Boris Chiou
Emilio Cobos Álvarez
Timothy Guan-tin Chien
Andreea Pavel
Botond Ballo
Andrea Marchesini
Mats Palmgren
Xidorn Quan
Tyson Smith
Paolo Amadini
Brian Birtles
Matt Woodrow
Ciure Andrei
Simon Montagu
Hiroyuki Ikezoe
Noemi Erli
Jason Kratzer
arthur.iakab
Ryan VanderMeulen
Csoregi Natalia
cku