This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
This patch creates new header, `mozilla/PresShellForwards.h`. It should have
all forward declarations of global class/struct in `nsIPresShell.h` and
`mozilla/PresShell.h`.
Additionally, this moves all `enum`s and `constant`s in them into the new file
with changing them to `enum class`es.
This will make other headers which require only specific types in the header
files not include them.
Differential Revision: https://phabricator.services.mozilla.com/D28605
--HG--
extra : moz-landing-system : lando
Wayland protocol allows to have only one popup window attached to a parent widget.
Recently we use a toplevel window widget as parent for all popups.
That means a second level menu (like File -> New Container Tab)
is not displayed as both ("File" and "New Container Tab" menus)
have the same parent widget.
As a solution allow to get the actual parent run-time and set that
when we open the window on toolkit level.
This patch covers menu widgets in the same frame hierarchy.
Differential Revision: https://phabricator.services.mozilla.com/D26112
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
(more a feedback request than review request at this stage)
Adding a new attribute to the panel was the easiest way I could find to make this work without too much plumbing
However I don't know how to check that the attribute comes from a chrome privileged script. I tried using PresContext()->IsChrome() but this is also false in our situation.
Would you prefer another approach? Otherwise what kind of test would you write for this kind of feature?
Differential Revision: https://phabricator.services.mozilla.com/D26211
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
For now, only add the MozMenuPopup base class to MozElements,
and don't define a custom element for it with
`customElements.define`. This is to help avoid conflicts in
de-xbl work. (See the bug for details.)
Includes a function to do 'manual slotting', moving child
elements into place. Dynamically adding, modifying, or
removing child nodes after the element is connected needs
to be handled manually as well.
Differential Revision: https://phabricator.services.mozilla.com/D25467
--HG--
rename : toolkit/content/widgets/popup.xml => toolkit/content/widgets/menupopup.js
extra : moz-landing-system : lando
This allows this enumeration to be used from nsIPresShell.h without introducing
a circular dependency.
Its new home in layout/base/ScrollTypes.h, included as mozilla/ScrollTypes.h.
Others similar enums can be added to that file if desired.
This patch also makes ScrollMode an enum class (as it's no longer nested
inside a class) and switches its enumerators to the |eName| naming convention.
Differential Revision: https://phabricator.services.mozilla.com/D24796
--HG--
extra : moz-landing-system : lando
The trouble with utility functions that take an nsIFrame is it's not clear what
the caller's intention is. For example, with
nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on
that frame? Or animations on _both_ that frame and its corresponding
style/primary frame?
Probably the caller hasn't even thought about it and there are likely to be bugs
when display:table content is encountered.
Where practical it's much better to take an element/pseudo pair since it's clear
that the caller is concerned with all animations (or transitions in this case)
on the element regardless of how it is represented in the frame tree.
This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo
pair and moves it to mozilla::AnimationUtils at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D23280
--HG--
extra : moz-landing-system : lando
It only works basically by chance with XBL and doesn't handle any kind of
dynamic insertion. See comment 4 in the bug for the diagnostic.
Differential Revision: https://phabricator.services.mozilla.com/D19489
--HG--
extra : moz-landing-system : lando
It only works basically by chance with XBL and doesn't handle any kind of
dynamic insertion. See comment 4 in the bug for the diagnostic.
Differential Revision: https://phabricator.services.mozilla.com/D19489
--HG--
extra : moz-landing-system : lando
sizetopopup is set to "pref" by default by the menulist XBL binding, however
when converting the binding to custom element, it did not set the attribute value
at a time that is early enough.
This patch updates nsMenuPopupFrame and nsMenuFrame so that it considers
<menulist> with unset sizetopopup attribute as equal to "pref" to avoid
the problem above.
This reftest
layout/reftests/xul/menulist-shrinkwrap-2.xul
can detect this failure.
The sizetopopup attribute is never meant to be set dynamically;
the fix here does not allow us to do so.
Differential Revision: https://phabricator.services.mozilla.com/D16410
--HG--
extra : moz-landing-system : lando
This prepares this binding for the unification with the "popup" binding, and removes the last consumer of the scrollByIndex method of XULScrollElement.
Because some code paths in "arrowscrollbox" are optimized using requestAnimationFrame, the related scrolling tests are now asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D15276
--HG--
extra : rebase_source : f5d26df106785f2c0d158b8a23a648a71ab06b2d
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
This hack was introduced at Bug 630346 and we should not need it any more.
MozReview-Commit-ID: FsRLY9A1T5O
--HG--
extra : rebase_source : 663f7ddd121be1b064b87b725892d2039576b12a
Test changes for removal of PopupBoxObject and popup.xml methods, some reflow tests now have different stacks now that they are not going through popup.xml binding methods, test_popupanchor.xul changes due to need to wait for popuppositioned event after resizing. The old code would just adjust the arrow directly when sizeTo was called, but the new code does this through an asynchronous popuppositioned event. Changes to some places that check for XULElement class.
--HG--
rename : dom/webidl/PopupBoxObject.webidl => dom/webidl/XULPopupElement.webidl
rename : layout/xul/PopupBoxObject.cpp => dom/xul/XULPopupElement.cpp
rename : layout/xul/PopupBoxObject.h => dom/xul/XULPopupElement.h
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
There are several behaviors that we only need to apply to popups which are
known to contain remote content. And since those behaviors can cause issues
elsewhere, we need to be able to identify popups which should contain remote
content, and treat them specially, where appropriate.
MozReview-Commit-ID: EMFrSP8lZiD
--HG--
extra : rebase_source : 5ee9da422081098d8099a048c7704008a06a7241
This avoids conflicts with mozilla::dom::FrameType.
MozReview-Commit-ID: 7aEMbHRaTFk
--HG--
extra : rebase_source : 2d01321f5ce0ec8c0e3f70984674f82678034b3c
Masayuki Nakano
Emilio Cobos Álvarez
Martin Stransky
Sylvestre Ledru
Hiroyuki Ikezoe
Julian Descottes
Paul Morris
Botond Ballo
Brian Birtles
Neil Deakin
Ryan Hunt
Dorel Luca
Timothy Guan-tin Chien
Paolo Amadini
Cameron McCormack
Nicholas Nethercote
Ting-Yu Lin
Brendan Dahl
Kris Maglione
Jeff Gilbert
Boris Zbarsky
Dão Gottwald
Ciure Andrei
Coroiu Cristina
Mats Palmgren
Daniel Holbert
Julian Seward
Wes Kocher
Bevis Tseng
Johann Hofmann
Markus Stange
Doug Thayer
Carsten "Tomcat" Book
KuoE0