What we actually care about here is whether itemRect is empty bceause that's
the what we'll use for the actual surface size.
Differential Revision: https://phabricator.services.mozilla.com/D48548
--HG--
extra : moz-landing-system : lando
Avoid intermittent test failures on android.
The existing android assertion count was introduced by bug 1405550, to avoid
assertion count failures with stylo.
Differential Revision: https://phabricator.services.mozilla.com/D47792
--HG--
extra : moz-landing-system : lando
If a <details> is a multi-column container, and has a column-span child
inside, aFrame can be ColumnSetWrapper or column-span-wrapper frame (due
to GetInsertionPrevSibling()'s modification). The latter case is handled
by "Situation #5 in WipeContainingBlock(), and can be reproduced by
changing `<article>` tag to `<details>` in
testing/web-platform/tests/css/css-multicol/multicol-span-all-dynamic-add-005.html
In any case, aFrame might end up in a frame generated by the <details>
element. I feel the assertion to check frame types might not be very
useful. Let's remove it.
Differential Revision: https://phabricator.services.mozilla.com/D45585
--HG--
extra : moz-landing-system : lando
If the <details> has ::first-letter, insertion.mParentFrame may be
modified by GetInsertionPrevSibling(), and points to nsFirstLetterFrame.
Fortunately, nsFirstLetterFrame's content is the details element. We can
check the content to determine if reframing the <details> is needed.
Also, add a reftest to test that an appended text should apply styles in
details::first-line.
Differential Revision: https://phabricator.services.mozilla.com/D45454
--HG--
extra : moz-landing-system : lando
Run broken-column-rule-1.html with column-span enabled because it was
regressed by Bug 1548100 Part 2, but fixed by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D41907
--HG--
extra : moz-landing-system : lando
Delete `return false` at the end of the if-statement block that handling
the multicol subtree reframing, and let it fall though the bottom of
WipeContainingBlock() where there is a complete logic for ib-split
reframing.
Differential Revision: https://phabricator.services.mozilla.com/D38548
--HG--
extra : moz-landing-system : lando
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--HG--
extra : moz-landing-system : lando
The test is supposed to test that changing the preference layers.acceleration.disabled doesn't cause a crash, but this pref is only read on startup well before the test has a chance to run and switch the pref.
It's not doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D34781
--HG--
extra : moz-landing-system : lando
This crashes both debug and opt builds pretty badly without the fix for this
bug.
Differential Revision: https://phabricator.services.mozilla.com/D29497
--HG--
extra : moz-landing-system : lando
This patch does something similar to GetIBContainingBlockFor() because
pseudo frames are not good reframe target.
Differential Revision: https://phabricator.services.mozilla.com/D26858
--HG--
extra : moz-landing-system : lando
We avoid removing subsumed hints for out-of-flow and column-span frames
in RestyleManager::ProcessPostTraversal(). We should do something
similar here.
Differential Revision: https://phabricator.services.mozilla.com/D24578
--HG--
extra : moz-landing-system : lando
The test case triggers MOZ_ASSERT(!IsFramePartOfIBSplit(aParentFrame))
in MaybeRecreateForColumnSpan() because WipeContainingBlock() returns
early when the FrameConstructionItemList is empty. Thus, it doesn't wipe
the aParentFrame even if it's part of an IB split.
An empty FrameConstructionItemList constructs no frames. Therefore,
MaybeRecreateForColumnSpan() doesn't need to do anything if aFrameList is empty
since an empty frame list cannot contain any column-span.
Differential Revision: https://phabricator.services.mozilla.com/D23820
--HG--
extra : moz-landing-system : lando
aFrameList can contain placeholder frames. If we decide to nuke
aFrameList, we need to destroy the out-of-flow frames gracefully.
In this case, out-of-flow frames are still in nsFrameConstructorState's
absolute item lists. To rely on nsPlaceholderFrame::DestroyFrom() to
remove its out-of-flow frame properly, we manually flush all the frame
insertions for all the lists in aState before destroying aFrameList.
Differential Revision: https://phabricator.services.mozilla.com/D19460
--HG--
extra : moz-landing-system : lando
The added crashtest still crashes on Android verify runs (TV) for
unknown reasons, so skip it.
Differential Revision: https://phabricator.services.mozilla.com/D16395
--HG--
extra : moz-landing-system : lando
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
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
Brendan Dahl
Jeff Muizelaar
Geoff Brown
Hiroyuki Ikezoe
Ting-Yu Lin
L. David Baron
Jonathan Kew
Emilio Cobos Álvarez
Noemi Erli
Sean Feng
Jean-Yves Avenard
Matt Woodrow
Mats Palmgren
Ting-Yu Lin
Ryan VanderMeulen
Henri Sivonen
Andreea Pavel
Timothy Guan-tin Chien