And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
We never extend xul:tooltip, xul:menupopup or xul:popup, so this can go away.
MozReview-Commit-ID: LZsGYRdI5tW
--HG--
extra : rebase_source : 7d520fa9729f27b1a6a0b2ad3f4eed55f9729aeb
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
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
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
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
nsMenuPopupFrame will constrain the size of its widget to its min and max size.
It will also request its nsView to resize to its frame rect. If its frame rect
is larger or smaller than the min or max size, nsView will be unable to change
the size of the widget, and each ViewManagerFlush will attempt a resize and
force a composite. When there are a lot of ViewManagerFlushes, this can
overload the compositor.
--HG--
extra : rebase_source : e32c3bb5445365ef76ea2a0700abb6911974afcc
extra : source : cadcf04ef23cee5ddbbbf216573c05d3fc0e53f2
This is in response to an issue that's affecting the new app
update doorhangers on OSX, where the problem is more obvious.
On OSX, the panel styling makes it so that the doorhanger
overflows the window a little bit. This is fine until you enter
fullscreen with ctrl+command+F. At this point, the doorhanger
should come back onto the screen and the arrow should be rooted
to its anchor element (in our case the hamburger menu icon), but
instead it lags and the panel is not adjusted right away. This
is because right after the window is resized, which ends up
calling SetPopupPosition with aIsMove == false, SetPopupPosition
is called again from CheckForAnchorChange with aIsMove set to
true. There could be other solutions to this particular problem,
but since the aIsMove boolean is intended to limit the visual
noise when moving a window between screens, it seemed appropriate
for it to only prevent sliding or flipping if the panel isn't
already slid or flipped.
There was another issue affecting specifically the arrow, where
the logic for notifying observers of a positioning change in the
panel doesn't account for changes only to the position of the
anchor rect. This change adds tracking of that and sets aNotify
to true when called from ReflowFinished, since this is where
the position of the anchor element relative to the window can
need to change, even when the screen position of the panel rect
doesn't change.
MozReview-Commit-ID: Lpfokwkgl33
--HG--
extra : rebase_source : b05adc0b3f876196ff45499f0d70533f78cafb0e
nsIFrame::mClass is of type enum class nsQueryFrame::ClassID which is
a strict subset of the nsQueryFrame::FrameIID values. For a concrete
frame class, its FrameIID is the same numeric value as its ClassID.
MozReview-Commit-ID: 1N0AkCGo1ol
Transparency is not handled correctly for composited popups on any platform,
but works with varying degrees of success on some platforms, for some popups.
Oddly, out of the three main desktop platforms, Linux seems to handle it the
best, so long as we render the popup as opaque, and let the platform
compositor handle the transparency.
MozReview-Commit-ID: E8NQlToUQq3
--HG--
extra : rebase_source : c77da6eed1e95769798a14e873798df920fcb9b7
