Most of the Shadow DOM related code are behind "dom.webcomponents.enabled" and
this pref is only used by Shadow DOM right now, so we should rename it to
"dom.webcomponents.shadowdom.enabled"
MozReview-Commit-ID: er1c7AsSSW
This also changes the function to return a sequence (JS Array) instead of
an nsFontFaceList object, and converts nsFontFace/nsIDOMFontFace into a
Web IDL implemented object too.
MozReview-Commit-ID: 1iAW3DYe5kO
--HG--
rename : layout/inspector/nsFontFace.cpp => layout/inspector/InspectorFontFace.cpp
The whole function doesn't have much sense.
I killed its only DOM use in bug 1427511.
Now it only has two callers in nsCSSFrameConstructor, which basically only want
to know whether the children of the same node can have different flattened tree
parents.
So let's check that directly instead (checking whether the element has a binding
or a shadow root), and simplify a bit other surrounding code while at it.
Leave the XUL popup / menubar code doing the broken thing they were doing
beforehand, because it doesn't look to me like it's trivial to fix... They're
effectively assuming that the children of the menupopup end up in a single
insertion point, which is true, but doesn't need to be. Maybe they should walk
the DOM tree? Don't want to dig into that right now, since XUL insertion points
can be filtered and all that... Not fun.
Also, this removes the broken optimization that used to check
mParentFrame->GetContent()->HasChildren(), because it's pretty broken. It used
to be relevant before bug 653881, because <children> element used to not exist,
but now the insertion point at least needs to contain the <children> element all
the time.
There even used to be a XXX comment saying that the optimization didn't work,
which was removed in:
https://hg.mozilla.org/mozilla-central/rev/2d8585ec74b3
We could still check for "no insertion points", and optimize that, but it
doesn't seem worth it.
MozReview-Commit-ID: L4lspkxKENr
For an OOF frame, the parent frame that's associated with our parent
style context is the *placeholder's* parent -- not the OOF frame's
parent.
MozReview-Commit-ID: CUSBkWDqxWz
--HG--
extra : rebase_source : 96dfef60ed87b94fe7ec1ea5c3104658e283b3ea
The whole function doesn't have much sense.
I killed its only DOM use in bug 1427511.
Now it only has two callers in nsCSSFrameConstructor, which basically only want
to know whether the children of the same node can have different flattened tree
parents.
So let's check that directly instead (checking whether the element has a binding
or a shadow root), and simplify a bit other surrounding code while at it.
Leave the XUL popup / menubar code doing the broken thing they were doing
beforehand, because it doesn't look to me like it's trivial to fix... They're
effectively assuming that the children of the menupopup end up in a single
insertion point, which is true, but doesn't need to be.
Maybe they should walk the DOM tree? Don't want to dig into that right now,
since XUL insertion points can be reordered and all that... Not fun.
MozReview-Commit-ID: L4lspkxKENr
We remove async from the DOM all the time now since bug 1389743.
We could, before this patch, recurse into frame construction in a sync way, due
to the way we handle the weird insertion cases for <fieldset>, <details>, and
<mathml>.
This patch makes those also async, making the IssueSingleInsertNotifications
condition unnecessary.
MozReview-Commit-ID: LujPaYPwA4G
--HG--
extra : rebase_source : 3fc9dc9589a0c43f9f211e22873bf6b960d416f7
The event targets of touch events are not necessarily to be the same as their corresponding pointer events. So we don't have to cache the event target of pointer events when they are generated from touch.
MozReview-Commit-ID: 9Gd6ion7NXf
It doesn't fill the ancestors of the first frame if aCommonAncestor is null,
which means that we get garbage afterwards.
MozReview-Commit-ID: G85dv7KM1Xd
--HG--
extra : rebase_source : 80168515b122c60461bf1cde1695fb7b98aaaa99
Now that accessing nsIContent slots is not a blob of virtual function calls, we
should be able to unify logic here, and speed up the not-so-rare case for
chrome, while keeping the usual case fast.
MozReview-Commit-ID: 87iY5Cbhx4T
This code was relying on nsImageFrame::ContentRemoved running before it.
MozReview-Commit-ID: Imjhd9exjQS
--HG--
extra : rebase_source : 7c6367f515dc140176e50d959c07250057e28354
This makes the pres shell be notified as the last observer unconditionally.
In practice this doesn't matter, and it may already be the case if an iframe
goes display: none and back. In practice, the only dependency that requires this
order is that the pres shell needs to be notified _after_ the content sink, so
we don't try to enter frame construction before beginning the shell update.
That may be worth looking into, but definitely not in the scope of this bug... :)
MozReview-Commit-ID: 9WeJ5kaUtBq
--HG--
extra : rebase_source : 6589df0aa8a875dc270894fabb6b4bc170d6b6fe
There may be some pending input events in the queue of thread when content starts a dnd operation. Spec says that input events should be suppressed when there is a dnd operation. Add a flag in ESM and turn on/off when start/finish a dnd operation. Checking the flag in PresShell::HandleEvent because we may start a dnd operation with pointermove and we want to suppress the mousemove as well.
MozReview-Commit-ID: 43NZrA7SW4c
This feature is intended to help Firefox frontend developers experiment with
replacing XUL content with modern flexbox. We might also eventually use
this emulation to *actually* render most or all of our legacy XUL UI.
MozReview-Commit-ID: 3g2W9o3t23H
--HG--
extra : rebase_source : a3e8b443d9b58e5af3287a23de6edc276ed5e847
XUL popups (i.e. FrameConstructionItem instances with mIsPopup==true) behave
like out-of-flow content -- in particular, they generate nsPlaceholderFrame
instances. So, they need the same placeholder-wrapping behavior that we have
for other out-of-flow frames inside of an emulated legacy box, in order to
satisfy our existing invariants.
MozReview-Commit-ID: KnspN4kTPnx
--HG--
extra : rebase_source : 8487f4ee50b21dc0389514fe34a17a73375a58ab
This patch does not change behavior. This patch just refactors the logic in
IsXULDisplayType so that -moz-box and -moz-inline-box are handled via a
dedicated early-return. This lets a later patch in this series make a more
understandable targeted tweak to add pref-controlled behavior for these display
values.
MozReview-Commit-ID: 6keGrxJcA5l
--HG--
extra : rebase_source : a4c7a6dd205da7d7c39c172ebb6d0c3bb7cd5458
Now that (per previous patch) NS_STATE_FLEX_IS_EMULATING_LEGACY_BOX isn't just
a webkit-box-specific tag: this patch here generalizes the variable-names and
comments associated with that flag in nsCSSFrameConstructor.cpp.
This patch does not make any changes to behavior; it's simply renaming &
comment tweaks.
MozReview-Commit-ID: DcF5GirAQwD
--HG--
extra : rebase_source : d847c5579399a4cc31dc14a52a93b03ed917034e
This patch isn't changing semantics of this bit at all - it just renames it to
a more general name. In other words, this patch does not change behavior.
MozReview-Commit-ID: 4wb13X4YinJ
--HG--
extra : rebase_source : 9a89ce8782f735d7f4a8ad471606a2af5201ac83
See bug 1422633, there are assertions missing, and servo doesn't assert at all
anymore.
I don't think it's worth optimizing / lazily resolving it, each time the
document state changes.
We usually just restyle the world anyway (which requires recomputing it), and
the changes that it's optimizing (nsWindow::SetActive() and XUL root element
localedir attribute changes) aren't common enough to warrant the complexity I'd
say.
This doesn't handle invalidating the cache in the case the root element goes
away, I haven't bothered because it was already broken, and GetRootElement() is
already gone in RemoveSubtreeFromDocument.
MozReview-Commit-ID: 9RuQhmmy7Kr
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
I've verified that this asserts without the patch.
MozReview-Commit-ID: 8j6x4xswrCe
--HG--
extra : rebase_source : 37ec24fc08b1f492e5d48e1323602b315c319fb4
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
The LastContinuation stuff behavior was what we did before the other patches, so
let's do that all the time to avoid surprises, though unfortunately I don't have
test-cases.
This effectively restores exactly the same behavior we had before all my frame
constructor patches, just with less code.
MozReview-Commit-ID: IkQ3H3rtlQM
--HG--
extra : rebase_source : 037f3564a4bb137fe7b9ed08deb248b61bf5fe8c
Jessica Jong
Cameron McCormack
Emilio Cobos Álvarez
Daniel Holbert
Kartikaya Gupta
Margareta Eliza Balazs
KuoE0
Matt Woodrow
Sebastian Hengst
Jonathan Watt
Andrea Marchesini
Jonathan Kew
Botond Ballo
Stone Shih
Cosmin Sabou
Olli Pettay
Gijs Kruitbosch
Noemi Erli
Andreea Pavel
Csoregi Natalia
Mats Palmgren
Gerald Squelart
Narcis Beleuzu
Moritz Brunner
Miko Mynttinen
Samathy Barratt
Ciure Andrei
Sylvestre Ledru