nsCSSFrameConstructor::CreateContinuingFrame creates a frame based on the
result of nsIFrame::Type(). The regressing bug changed the nsFileControlFrame
type from Block to its own FileControlType type, which meant that we stopped
creating nsBlockFrame continuations for it.
Fix it by restoring the previous behavior: changing the Type() back to return
Block, and using QueryFrame instead to check for the specific
nsFileControlFrame where we need to.
This is all rather messy, see bug 1555477 for related discussion.
Differential Revision: https://phabricator.services.mozilla.com/D175062
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
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
Factor a MiddleCroppingBlockFrame that does the double reflow shenanigans.
That should both be faster and easier to reason about. The only thing we need
to be careful about is to use the current inline coord from the line layout if
present to compute the real available isize.
Differential Revision: https://phabricator.services.mozilla.com/D173668
Layout-wise it doesn't have any special code. Only weirdness is:
* Invalidation when size changes (we can do that with a
ResizeObserver).
* Weird paint retargetting to the splitter, which we can fix by using
negative margins instead and using a regular splitter.
Differential Revision: https://phabricator.services.mozilla.com/D171768
nsImageFrame has support for displaying style URIs / an owned image
request, so use it.
The main behavior difference is that we don't fire `load` / `error`
events for those images anymore, but I don't see any event listener for
those around, so I think they can go.
Differential Revision: https://phabricator.services.mozilla.com/D168958
This ended up being a lot more straight-forward than the menu changes.
TLDR:
* nsMenuBarFrame -> XULMenuBarElement
* nsMenuBarListener -> MenuBarListener
Rest should be rather straight-forward.
Depends on D168649
Differential Revision: https://phabricator.services.mozilla.com/D167809
This ended up being a lot more straight-forward than the menu changes.
TLDR:
* nsMenuBarFrame -> XULMenuBarElement
* nsMenuBarListener -> MenuBarListener
Rest should be rather straight-forward.
Depends on D168649
Differential Revision: https://phabricator.services.mozilla.com/D167809
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
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
* Make non-menulist popups just absolute positioned top-layer items.
* Simplify menulist popups to just be static-positioned items under
nsMenuFrame.
We need to keep kPopupList only for nsMenuFrame. In the future it can be
removed, see TODO in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D161404
After bug 1665476, it's pretty much a regular XUL box with a couple
special-cases that we can use IsRootElementStyle for. Do that, and allow
using nsFlexContainerFrame when using flexbox emulation.
Differential Revision: https://phabricator.services.mozilla.com/D158288
After bug 1665476, it's pretty much a regular XUL box with a couple
special-cases that we can use IsRootElementStyle for. Do that, and allow
using nsFlexContainerFrame when using flexbox emulation.
Differential Revision: https://phabricator.services.mozilla.com/D158288
After bug 1665476, it's pretty much a regular XUL box with a couple
special-cases that we can use IsRootElementStyle for. Do that, and allow
using nsFlexContainerFrame when using flexbox emulation.
Differential Revision: https://phabricator.services.mozilla.com/D158288
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
This doesn't change behavior just yet, but seems worth doing separately.
With this patch, we can render content overlaid on top of an image
frame, by attaching a shadow root to it. The idea is to use this for
text recognition (OCR) of text inside images.
I chose to implement this using the DynamicLeaf stuff that I removed in
bug 1746310 (because nsMenuPopupFrame was its only user).
That seems simpler than either a new frame class, or more special cases
in the frame constructor, etc. But let me know if you disagree.
There are further changes that we want to do. For example, trying to
select the overlaid text with the mouse right now will start dragging
the image. For that, we might need to tweak our selection / mouse
dragging code. But those seem all changes that can go on top of this.
Differential Revision: https://phabricator.services.mozilla.com/D140638
It's unused on mozilla-central, and Thunderbird can just use the canvas
frame as regular (X)HTML documents, so just use a canvas frame instead
of an nsRootBoxFrame for XUL as well.
nsRootBoxFrame was needed because of various XUL-specific things like
tooltips and so on lived there. But with the move away from XUL, that
functionality has been added to nsCanvasFrame already, behind a
principal check instead.
This also allows simplifying our background propagation setup, which was
only half-working for XUL documents (this bug is a consequence of that).
With this, most of the callers of nsCSSRendering::IsCanvasFrame can go.
They're only two of the frames that would return true for that that
actually paint backgrounds (nsCanvasFrame and nsRootBoxFrame), so the
codepaths in display list building and painting can just check
frame->IsCanvasFrame() instead.
The remaining caller to that function is
nsContainerFrame::SyncWindowProperties, and the change is also legit, in
the sense that the only thing SyncWindowProperties() really cares about
is propagating the max/min-width constraints from the root element's
style to the view/widget, and the only frame that would return true from
IsCanvasFrame and have a view is the viewport frame which is the root of
the frame tree.
Differential Revision: https://phabricator.services.mozilla.com/D90846
