It is the right place to do it, otherwise we don't have the guarantee of
it invalidating ancestor sizes or anything.
It's also what we invalidate in WaylandPopupPropagateChangesToLayout().
We otherwise do not have the guarantee of SetPopupPosition running
before or after layout, if sizes do not change. That caused the popup
size to remain big, which caused a resize loop.
Differential Revision: https://phabricator.services.mozilla.com/D144314
layout/xul/nsSprocketLayout.cpp:1116:14: error: variable 'pass' set but not used [-Werror,-Wunused-but-set-variable]
for (int pass = 1; true == limit; pass++) {
^
Differential Revision: https://phabricator.services.mozilla.com/D144143
On Wayland popup flipping and such is not Firefox's responsibility.
Once we've decided the final popup position because the compositor told
us, we move the popup to a fixed position, and internally the popup
becomes unanchored.
Using this boolean to make decisions after the initial popuppositioned
event is wrong, so avoid exposing it to JS.
Differential Revision: https://phabricator.services.mozilla.com/D142679
Use mMoveToRectPopupRect popup constrains in nsMenuPopupFrame::SetPopupPosition only and make it pernament.
In such setup works as screen size constraints.
Don't call SetPopupPosition from move-to-rect callback and let layout code to handle that.
Remove MoveToRectPopupRectClear() as it's not needed, we keep mMoveToRectPopupRect
in nsMenuPopupFrame as well as we keep screen sizes there.
Differential Revision: https://phabricator.services.mozilla.com/D141602
Use mMoveToRectPopupRect popup constrains in nsMenuPopupFrame::SetPopupPosition only and make it pernament.
In such setup works as screen size constraints.
Don't call SetPopupPosition from move-to-rect callback and let layout code to handle that.
Remove MoveToRectPopupRectClear() as it's not needed, we keep mMoveToRectPopupRect
in nsMenuPopupFrame as well as we keep screen sizes there.
Differential Revision: https://phabricator.services.mozilla.com/D141602
Rename PreferredPopupRect* methods/attributes to MoveToRectPopupRect* ones as it holds info about coordinates received from move-to-rect popup placement done by Wayland compositor.
Differential Revision: https://phabricator.services.mozilla.com/D141425
What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
Store preferred rect in dev pixels, which simplifies a bit other calculations,
and ensures that the nsMenuPopupFrame code accounts for zoom etc.
Use existing conversion methods for GDK <-> Device <-> CSS conversions.
Differential Revision: https://phabricator.services.mozilla.com/D139623
I had this written somewhere in a branch, but given bug 1419151, I
cleaned it up a bit and turned it into an actual patch that works.
Behind a pref for now, because at the very least it needs:
* Support for some testing-only functions.
* Support for custom icons (for web extensions and so on).
The key point is that this adds the relevant code to map a XUL menu to a
GMenuModel, which we could then export via
`g_dbus_connection_export_menu_model()`, which seems like a much simpler
approach to support stuff like bug 1419151.
See the MenuModel class in NativeMenuGtk as for how is this done.
Differential Revision: https://phabricator.services.mozilla.com/D139845
I don't see why ever mScreenRect would deal with zoom-less coordinates.
I _suspect_ this might have been accounting for screenX/Y not dealing
with zoom in the past, but that was fixed (not long ago, actually) in
bug 1753836.
Also, browser.xhtml never has zoom. I haven't seen this causing problems
in practice in non-Wayland platforms, but I think it's the right thing
to do and the code as is is extremely confusing, since other places
applying screen rects and context menu offsets treat them as real CSS
pixels:
https://searchfox.org/mozilla-central/rev/73a8000b0c0eb527faef01ea17c6d2398622a386/layout/xul/nsMenuPopupFrame.cpp#2407-2411
So I don't think this changes behavior in practice in non-wayland
platforms given we never have full zoom in browser.xhtml and we mostly
hit this code path for context menus, but given the above I think it's
simpler and more correct.
Depends on D139670
Differential Revision: https://phabricator.services.mozilla.com/D139671
We need them for SVG primitives.
This patch adds a bit of plumbing to disable snapping some of the primitives and forcing the antialiasing shader feature where needed, and uses it for SVG solid rectangles and images.
Differential Revision: https://phabricator.services.mozilla.com/D139024
And cleanup similar code in nsXULTooltipListener. That code shouldn't
need to deal with zoom since the target and the tooltip are in the same
document.
Differential Revision: https://phabricator.services.mozilla.com/D139235
This preserves the previous behavior, though arguably we shouldn't call OpenMenu
to begin with if the menu has been rolled up.
Differential Revision: https://phabricator.services.mozilla.com/D138637
Build errors being fixed here:
layout/xul/nsDeckFrame.cpp:164:43: error: unknown type name 'nsSetAttrRunnable'
layout/xul/nsMenuBarListener.cpp:45:7: error: cannot initialize a member subobject of type 'mozilla::dom::EventTarget *' with an rvalue of type 'nsINode::Document *' (aka 'mozilla::dom::Document *')
(...where "Document" is not defined; this patch includes the header that defines it, which fixes this.)
layout/xul/nsBoxFrame.cpp:270:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
dist/include/nsIRollupListener.h:36:38: error: no type named 'LayoutDeviceIntPoint' in namespace 'mozilla'
(For this error, this patch is changing a header outside of layout/xul, but
it's still required in order for layout/xul to build properly, since it's
#included by layout/xul/nsXULPopupManager.cpp (indirectly, via its .h file).
Differential Revision: https://phabricator.services.mozilla.com/D138092
Build errors being fixed here:
layout/xul/nsDeckFrame.cpp:164:43: error: unknown type name 'nsSetAttrRunnable'
layout/xul/nsMenuBarListener.cpp:45:7: error: cannot initialize a member subobject of type 'mozilla::dom::EventTarget *' with an rvalue of type 'nsINode::Document *' (aka 'mozilla::dom::Document *')
(...where "Document" is not defined; this patch includes the header that defines it, which fixes this.)
dist/include/nsIRollupListener.h:36:38: error: no type named 'LayoutDeviceIntPoint' in namespace 'mozilla'
(For this error, this patch is changing a header outside of layout/xul, but
it's still required in order for layout/xul to build properly, since it's
#included by layout/xul/nsXULPopupManager.cpp (indirectly, via its .h file).
Differential Revision: https://phabricator.services.mozilla.com/D138092
For all purposes, this is the same as devicePixelRatio. It was meant to
skip the resistFingerprinting check the devicePixelRatio getter does,
but we do that now using CallerType in WebIDL, so if we cared about that
for these tests (which we don't) we could just do
SpecialPowers.wrap(window).devicePixelRatio.
As a follow-up we could move the NoOverride to window for symmetry. But
it's only used by devtools touch simulation so not sure if worth it.
Differential Revision: https://phabricator.services.mozilla.com/D138021
There's only one caller of it and it's not sound: The runnable captures a
raw frame pointer etc. Instead, just do a dispatch to the main thread
and call OpenMenu there. This simplifies the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D131082
This is the main patch for the bug. It aims to change the grapheme cluster
break's `Next()` API by implementing SegmentIteratorUtf16 interface, and adapt
the callers. It shouldn't change the behavior.
While rewriting the caller, one caveat worth mentioning is the loop termination
condition. If the old code relies on `!AtEnd()` as the loop termination
condition, and it advances the iterator at the end of the loop, it meant
to *skip* its logic when the break position is at the end of the string. For
example, see the `mozTXTToHTMLConv::NumberOfMatches`.
This patch also hooks grapheme cluster break iterator into
Segmenter::TryCreate() interface.
Existing test coverage for the file changed:
- netwerk/test/unit/test_mozTXTToHTMLConv.js
- layout/reftests/forms/input/file/dynamic-max-width.html
Differential Revision: https://phabricator.services.mozilla.com/D135643
Include "nsLayoutUtils.h" in nsFileControlFrame to get rid of warnings in my
editor because it uses utilities such as `nsLayoutUtils::AppUnitWidthOfString`.
We compile it without issues because of unified build.
Differential Revision: https://phabricator.services.mozilla.com/D135640
Part of how invalidation works with WebRender is that we assume frames
with a WebRenderUserData object attached to them are in view. This means
for images that we must ensure we create an empty
WebRenderImageProviderData object even when we have no provider or
surface for display. This will allow us to invalidate properly when we
get the FRAME_COMPLETE notification from imagelib indicating that the
redecode has completed.
Differential Revision: https://phabricator.services.mozilla.com/D135077
Emilio Cobos Álvarez
Mike Hommey
stransky
Norisz Fay
Hector Zhao
Noemi Erli
Nicolas Silva
Miko Mynttinen
Timothy Nikkel
Daniel Holbert
Iulian Moraru
Andi-Bogdan Postelnicu
Gijs Kruitbosch
Ting-Yu Lin
Cristian Tuns
Hiroyuki Ikezoe
Andrew Osmond
Kagami Sascha Rosylight