The legacy DOM mutation events shouldn't be used even in content and must not be
used in chrome.
This patch makes it crash if legacy mutation event listener is:
* added to a node in a chrome document
* added to a node in a native anonymous subtree
* added to the system event group
* implemented by C++
This causes some crash tests and chrome tests. Therefore, this patch modifies
them to use `MutationObserver` instead or removes them if it's impossible to
rewrite with `MutationObserver`.
Note that if I prevent to dispatch mutation events in some/all of the cases,
that causes performance regression in Speedometer3. Therefore, this patch
does not touch `EventDispatcher`.
Differential Revision: https://phabricator.services.mozilla.com/D181828
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
This does two things:
* Modify `nsXULPopupManager::ShowPopup()` so it calls `ShowPopupAsNativeMenu()`
as long as an anchor wasn't passed in, and only on Mac.
* Modify `-[MOZMenuOpeningCoordinator _openMenu:atScreenPosition:forView:withAppearance:]`
so it also takes a `aIsContextMenu` param. If the param is true, we synthesize
a right-click event and pop up a context menu as usual. If it's false, we use
`-[NSMenu popUpMenuPositioningItem:atLocation:inView:]` instead.
The reason this works is because `-[NSMenu popUpMenuPositioningItem:atLocation:inView:]`
opens the menu in a sensible place when the x-y coords are near the right edge
of the screen. In contrast, `+[NSMenu popUpContextMenu:withEvent:forView:]` will
anchor the menu's top-right corner to the mouse cursor when near the right edge.
Differential Revision: https://phabricator.services.mozilla.com/D177355
The thumb's position is sent to the compositor in ScrollbarData::mThumbStart
stored on the OwnLayer item built by the slider frame, so we need to
invalidate the slider frame when the thumb's position changes.
Differential Revision: https://phabricator.services.mozilla.com/D176384
This makes our menus closer to GTK4, and depends less on the native menu
rendering etc. Thunderbird already does this to some extent.
Leave the old code behind a pref for now (just in case). Also fix some
code in nsNativeTheme::GetContentState (fixes rendering of radio menu
items).
Differential Revision: https://phabricator.services.mozilla.com/D175664
The tree devtools uses is the light dom + pseudo-elements + NAC, but sometimes
it wants to know stuff about the flat tree like assigned nodes. Previously it
was using a weird mix of the anonymous vs. non-anonymous walkers to get what it
wants, but that's needlessly complicated.
Instead, make InspectorUtils.getChildrenForNode do the right thing, and add
assigned nodes explicitly.
While _getChildren using a walker might seem like a good idea for performance,
realistically it was using InspectorUtils under the hood, and this is much
simpler.
Differential Revision: https://phabricator.services.mozilla.com/D174491
Surprisingly straight-forward:
Use SimpleXULLeafFrame, and override GetIntrinsicBSize to implement the rows
attribute.
Use DidReflow to manage the reflow callback which is equivalent to what the old
code did.
Differential Revision: https://phabricator.services.mozilla.com/D173818
We had these spread around, it's better to have a single central place where we
update the widget based on the styling of the popups.
Differential Revision: https://phabricator.services.mozilla.com/D173836
Surprisingly straight-forward:
Use SimpleXULLeafFrame, and override GetIntrinsicBSize to implement the rows
attribute.
Use DidReflow to manage the reflow callback which is equivalent to what the old
code did.
Differential Revision: https://phabricator.services.mozilla.com/D173818
Use a MiddleCroppingBlockFrame subclass that looks at the value attribute
instead. We don't need accesskey etc for these so we can just reuse it as is.
Differential Revision: https://phabricator.services.mozilla.com/D173669
We still have some remnants of XUL layout due to nsBox / nsLeafBoxFrame
which XUL trees / nsTextBoxFrame still use.
However all this code can go away before we get rid of those.
nsSplitterFrame was the last thing inheriting from nsBoxFrame.
Differential Revision: https://phabricator.services.mozilla.com/D173601
Make it a SimpleXULLeafFrame, and carry on. Ideally we'd instead move
this code out of layout altogether into a XULSplitterElement, but given
splitters can have no children, well.
At this point there's only nsTreeBodyFrame an nsTextBoxFrame left to be
able to remove all of XUL layout.
Differential Revision: https://phabricator.services.mozilla.com/D173600
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
I don't think there's ever a way these should differ.
Got some include hell from removing ReferrerInfo.h from Document.h but
hopefully should be straight-forward to review.
Depends on D173154
Differential Revision: https://phabricator.services.mozilla.com/D173155
Now that we've removed nsXULScrollFrame, ScrollFrameHelper can be
subsumed under nsHTMLScrollFrame.
I want to do this before making scrollbars non-XUL.
Renaming to mozilla::ScrollFrame is left for a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D173063
This preserves the previous behavior more exactly and fixes the display
of the icons, which have src="" but expect list-style-image to take
effect.
Depends on D173265
Differential Revision: https://phabricator.services.mozilla.com/D173266
Otherwise we lose the anchor constraints which can change our layout.
The only thing we want is to stop following the anchor _node_, so we can
just convert it to an anchor rect instead.
Differential Revision: https://phabricator.services.mozilla.com/D173135
The underlying issue here is an invalidation bug with XUL layout. When a
popup opens, we try to lay it out at full size, then post a reflow
callback to constrain it.
There's an intermediate step there where the popup might remain at full
size, and the constraining operates directly on mRect, which isn't quite
sound and doesn't update the scrollport of descendants.
Make nsMenuPopupFrame inherit from nsBlockFrame instead, doing
potentially two layout passes when constrained.
This fixes the issue at hand, and removes XUL layout from menu popups,
so it's a win-win.
To make reasoning about it a bit easier, factor out a bunch of the XUL
positioning code to be const. The mutation of mRect etc which was going
on otherwise was pretty hard to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D170368
In a setup with:
<hbox>
<something flex="1"/>
<something-else/>
</hbox>
Before bug 1822131 <something flex="1"> ended up with flex-basis: auto,
but was the only thing able to shrink, so <something-else> stayed the
same size.
After that bug however <something-else> is able to shrink too, so both
elements shrink. This wouldn't happen if flex="1" actually worked like
flex: 1 does.
However flex: 1 causes stuff like explicit main sizes to be
(effectively) ignored, so we need to fix up a few cases where now we'd
start flexing too much. For that, add a debug assert to
nsFlexContainerFrame to catch the would-be behavior changes here.
For the most part they're actually no-op since they're setting tiny
sizes, but preferences and devtools needed a couple real fixes.
The profile selection spacer is useless (zero-size).
Hopefully the last xul.css change I need to do :')
Differential Revision: https://phabricator.services.mozilla.com/D172704
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
Bug 1821920 and bug 1821871 are instances of an interesting behavior
change from bug 1820534.
The default flex-basis of old XUL was auto instead of max-content,
because of this code:
https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/generic/nsFlexContainerFrame.cpp#1327
So stuff that used to wrap now no longer does, in an horizontal flex
container, since xul.css prevents XUL elements from shrinking.
Per the comment, a few tests relied on this, but I believe it should
generally be safe to shrink the items. This only causes to shrink if
they have an explicit width but no min-width (including min-width:
auto).
Some tests like test_mousescroll.xhtml hit this, because they have
explicit sizes but min-width: auto ends up being 0 effectively, but I
believe we should tweak those tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D172462
Kershaw Chang
Masayuki Nakano
Norisz Fay
Emilio Cobos Álvarez
Razvan Cojocaru
Mark Banner
Katherine Patenio
Drew Willcoxon
Botond Ballo
Robert Longson
Natalia Csoregi
Sandor Molnar
Marian-Vasile Laza