This reverts commit 88008cd8ca.
Revert "Bug 2012637 - part 8: Make `nsContentUtils::ComparePoints` handle `TreeKind::Flat` and `TreeKind::FlatForSelection` correctly r=smaug,dom-core"
This reverts commit 73e6f6587b.
Revert "Bug 2012637 - part 7: Make `RangeUtils::CompareNodeToRangeBoundaries()` use `nsContentUtils::ComparePoints` with valid point in the tree r=smaug"
This reverts commit 6985d5e80f.
Revert "Bug 2012637 - part 6: Make `nsRange::CutContents()` convert the range boundaries to the ones in the DOM before comparing r=smaug"
This reverts commit 73b585af3d.
Revert "Bug 2012637 - part 5: Delete the default template parameter of `nsContentUtils::ComparePoints` and relatives r=smaug,dom-core"
This reverts commit 1a7f24e5b5.
Revert "Bug 2012637 - part 4: Make `nsContentUtils` use `nsIContent` for taking a child node as a parameter r=smaug"
This reverts commit a6ea8d6824.
Revert "Bug 2012637 - part 3: Add template `nsINode` API which can switch to call API from `TreeKind` r=smaug,dom-core,webidl"
This reverts commit a4211e9df0.
Revert "Bug 2012637 - part 2: Add `TreeKind::FlatForSelection` and change the template parameter of `ChildIteratorBase` to `TreeKind` r=smaug,dom-core"
This reverts commit 0241749ee7.
Revert "Bug 2012637 - part 1: Make `ChildIterBase` template class to re-implement `FlattenedChildIterator` for DOM, Flat and FlatForSelection TreeKind r=smaug,dom-core,layout-reviewers,emilio"
This reverts commit 9e71cb77fb.
This will make the main patch simpler. However, some of them do not
support `TreeKind::ShadowIncludingDOM` because it's unclear what
should return as a parent node of a child of `ShadowRoot`, what should
return as a child node of a shadow host. To avoid the developers to use
them on wrong assumptions, this patch makes the users use `DOM`, `Flat`
or `FlatForSelection` explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D281305
There's still a ton of things that can be cleaned up after this, but
this setup is nicer.
For now, editor keeps getting set-up / torn down on BindToFrame. Seems
all that could be untangled, but step by step.
The preview stuff and placeholder can just be created on demand now,
rather than requiring frame reconstruction.
Also, nsSearchControlFrame and co no longer do anything of interest, so
move the still relevant bits elsewhere and remove them.
test_bug1248459.html is removed because it messes with the editor
selection using SpecialPowers, in a way such that it crosses shadow
boundaries, and messes up the selected state triggering debug asserts.
test_focus_docnav.xhtml now triggers a different code-path because of
the shadow root (rather than the frame tree traversal). Keep it working
for now by replacing it with something that isn't a shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D282953
Much like bug 1979014 did for other attributes (these ones were a bit
harder because there's also native code that looked at them).
Make disabled imply :disabled, and checked imply :checked, which
simplifies the theming code while at it.
Differential Revision: https://phabricator.services.mozilla.com/D277665
Checking for attribute presence is cheaper. Also stop propagating it to
slider / thumb. Slider doesn't use it, and thumb can just look at the
scrollbar.
Differential Revision: https://phabricator.services.mozilla.com/D260688
We're not using the validate or triggeringprincipal attributes, so get
rid of them.
Main benefit is that now `image` can use srcset, which allows for hidpi
stuff and so on.
Main drawback is that `list-style-image` doesn't work on <html:img>, so
we need to use a separate variable.
Differential Revision: https://phabricator.services.mozilla.com/D258733
This is technically a behavior change because we don't really look at
the appearance value of the progressbar etc anymore. We could do that if
wanted, but it's more consistent to just look at the individual frame
(looking forward to appearance: base and other potential compat
improvements we could make in the area).
Differential Revision: https://phabricator.services.mozilla.com/D253256
Our current drawing code doesn't really match the platform anymore.
Since Big Sur, toolbars are taller on macOS than what we can draw. I
tried to hook NSControlSizeLarge to our code but that went anywhere
(CoreUI doesn't even know about it it seems), so this seems like the
best path forward, and also allows us to get rid of a fair chunk of
code.
Turn the page info window tabs into flat buttons, and turn the places
window buttons into regular non-native toolbarbuttons like on Windows
and Linux, which IMO still look good.
Differential Revision: https://phabricator.services.mozilla.com/D253210
We keep it as a <compat-auto> value as per spec, but we don't need to do
the specialness for number/password (at least for now), as
nsSearchControlFrame doesn't allow removing the x like that, nor it has
-moz-default-appearance: searchfield.
Differential Revision: https://phabricator.services.mozilla.com/D253213
This looks better on the native theme, and on the built-in themes too.
It's a mixed improvement and regression for non-native themes:
* On one hand, we use the system icons.
* On the other, we don't use the theme fill (which usually would be
used via context-fill / context-stroke).
So over-all I think it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D248603
* Spinner and spinner-textfield are totally unused.
* up/down buttons are only used for <input type=number>. The only
number inputs we have in our UI use the non-native theme already (the
print preview dialog).
* Windows already always uses non-native spinner up/down unconditionally, and
linux does it on mismatched color scheme.
We can probably live without native theme support for these. It's
completely unused right now.
Differential Revision: https://phabricator.services.mozilla.com/D236904
This was caught by Markus. When you hover over an overlay scrollbar on
macOS, you'd hit this the PaintScrollbar() code-path (or rather, you
won't bail out from the if (overlay && !hovered)), but macOS draws the
track in PaintScrollbarTrack().
Android doesn't hit this because android scrollbars can't ever be
hovered (they have pointer-events: none). This is a better fix than
D222172, which didn't paint the background for the non-overlay
scrollbars...
This doesn't change behavior since scrollbar and the track have the same
size (as cocoa scrollbars can never have buttons). Removing
nsSliderFrame is a refactor for another day if ever.
Differential Revision: https://phabricator.services.mozilla.com/D222194
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
In order to do it, expose the button padding to CSS via env(), and make
the buttons just use the regular drawing.
This slightly changes the padding to the end of the titlebar to match
one half of the inter-button spacing, rather that however much padding
the headerbar has.
We could improve on this slightly by also exposing the headerbar padding
and applying that to the last button, but that's not terribly easy to do
due to us supporting re-ordering of the titlebar buttons, and reversing
their placement, so it'd involve some rather hacky CSS. Not impossible,
but not trivial, and this looks good enough IMO.
Differential Revision: https://phabricator.services.mozilla.com/D202616
This fixes various things, like sort arrows not working, even in regular
non-mixed-color-scheme settings, and is a lot less code.
The toolbarbutton appearance on the problematic case described in
comment 0 could get some work (the extra borders aren't exactly pretty),
but it's still a much better improvement.
Differential Revision: https://phabricator.services.mozilla.com/D195345
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
I didn't find a single GTK theme that drew something useful for this:
* The container appearance isn't needed. It is a hack needed to get the
right styles for the native checkbox, but that's it, we don't need to
expose it to CSS.
* The label appearance was meant to draw the focus outline but since it
didn't work reliably we've been doing it manually since seven years
ago (see bug 582951 and bug 1312169).
Other platforms also don't use these so this simplifies the code a bit.
Depends on D185279
Differential Revision: https://phabricator.services.mozilla.com/D185286
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
I was looking into simplifying our scrollbar styles:
* StyleAppearance::Resizer is not used in content, and some of the
values were only for <xul:window> which are not supported anymore.
* Statusbarpanel and Resizerpanel aren't used. Statusbar is only used
once on macOS so we only need to keep it there.
Differential Revision: https://phabricator.services.mozilla.com/D178374
I was looking into simplifying our scrollbar styles:
* StyleAppearance::Resizer is not used in content, and some of the
values were only for <xul:window> which are not supported anymore.
* Statusbarpanel and Resizerpanel aren't used. Statusbar is only used
once on macOS so we only need to keep it there.
Differential Revision: https://phabricator.services.mozilla.com/D178374
I was looking into simplifying our scrollbar styles:
* StyleAppearance::Resizer is not used in content, and some of the
values were only for <xul:window> which are not supported anymore.
* Statusbarpanel and Resizerpanel aren't used. Statusbar is only used
once on macOS so we only need to keep it there.
Differential Revision: https://phabricator.services.mozilla.com/D178374
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
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
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
This element had a really weird dependency on the order of the command
events from the menuitems and the button which broke in bug 1790920.
Instead of keeping this element as a XULButtonElement, have a separate
button and popup. That's simpler and less prone to breakage, and allows
to get rid of special cases in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D158438
This element had a really weird dependency on the order of the command
events from the menuitems and the button which broke in bug 1790920.
Instead of keeping this element as a XULButtonElement, have a separate
button and popup. That's simpler and less prone to breakage, and allows
to get rid of special cases in Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D158438
Sylvestre Ledru