I'd claim that we don't need it because, in order to enqueue the event, we
already need to have overflowed the event in a normal reflow.
For now this should not break anything (or anything that wasn't already racy
depending on when we paint).
The only reason the flush is there is according to roc is to decide whether to
fire the event, and because it needs the layout information:
https://bugzilla.mozilla.org/show_bug.cgi?id=771822#c4
In practice, however, all the layout information we need we have already
computed by the time we post the event.
We don't expose the rects via the event details, which is what could get
out-of-date, so this patch could only mean that we fire the event slightly more
often in cases where people remove stuff from the DOM, right after we do layout
and the content has overflowed. But that's actually pretty unlikely.
This event in general is pretty problematic because it exposes when we do
layout and when we paint, which is not great. Its test coverage is also pretty
low (test_overflow_event.html, which of course still passes without this).
I still want to do this change first since it's trivial to back out if needed.
Then I'd want to change how it fires to match the scrolled area change event
(which would allow us to remove the WillPaintObserver stuff), after verifying
that chrome consumers are still fine with that, and then put behind a pref and
hide it from content, while we leave time for chrome consumers to migrate away
from it, and allow us to revert if something breaks.
Differential Revision: https://phabricator.services.mozilla.com/D5082
ColumnSetWrapperFrame is needed to implement column-span. Patches in bug
1421105 will utilize this frame.
Co-authored-by: Neerja Pancholi <npancholi@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D5092
--HG--
extra : moz-landing-system : lando
All classes deriving from nsIFrame that did not have any subclasses themselves
(at the time of writing this patch) have been marked with `final`.
Some other Layout classes have also been made final, but this was opportunistic
while working on nsIFrame subclasses, and is definitely not exhaustive, further
patches welcome; refer to bug 1332680.
Advantages of marking a class final include:
- Allowing the compiler to devirtualize some method calls (i.e., calling
virtual functions directly instead of going through the vtable),
- Indicating that the class is not currently subclassed,
- Preventing subclassing without being aware that this would remove the
finalization benefits of the parent class.
`final` does not signify that these classes should *never* be subclassed, this
is left for developers to decide.
Differential Revision: https://phabricator.services.mozilla.com/D5020
--HG--
extra : moz-landing-system : lando
I'd claim that we don't need it because, in order to enqueue the event, we
already need to have overflowed the event in a normal reflow.
For now this should not break anything (or anything that wasn't already racy
depending on when we paint).
The only reason the flush is there is according to roc is to decide whether to
fire the event, and because it needs the layout information:
https://bugzilla.mozilla.org/show_bug.cgi?id=771822#c4
In practice, however, all the layout information we need we have already
computed by the time we post the event.
We don't expose the rects via the event details, which is what could get
out-of-date, so this patch could only mean that we fire the event slightly more
often in cases where people remove stuff from the DOM, right after we do layout
and the content has overflowed. But that's actually pretty unlikely.
This event in general is pretty problematic because it exposes when we do
layout and when we paint, which is not great. Its test coverage is also pretty
low (test_overflow_event.html, which of course still passes without this).
I still want to do this change first since it's trivial to back out if needed.
Then I'd want to change how it fires to match the scrolled area change event
(which would allow us to remove the WillPaintObserver stuff), after verifying
that chrome consumers are still fine with that, and then put behind a pref and
hide it from content, while we leave time for chrome consumers to migrate away
from it, and allow us to revert if something breaks.
Differential Revision: https://phabricator.services.mozilla.com/D5082
--HG--
extra : moz-landing-system : lando
Some methods were not overrides and were never overridden, so they could simply
be non-virtual.
Others were overrides but were not overridden, so they could benefit from being
final to hopefully lead to devirtualized calls.
Though some of these are not strictly necessary because they are inside 'final'
classes, I think they're worth adding anyway, because:
- The 'final' keyword becomes more obvious when looking at methods without the
wider context in sight (e.g., in reviews or searchfox).
- If one day any of these classes becomes non-final, it would keep the final
attribute on these methods by default, and force the programmer to explicitly
reflect before removing 'final' from the methods that need to be overridden.
Depends on D5020
Differential Revision: https://phabricator.services.mozilla.com/D5021
--HG--
extra : moz-landing-system : lando
SelectionChangeListener is too generic name but it just dispatches
selectionchange event when it's necessary. So, it should be renamed to
SelectionChangeEventDispatcher. Additionally, it's in mozilla::dom namespace
but it does not represent any DOM object. So, it should be in mozilla namespace
instead.
Differential Revision: https://phabricator.services.mozilla.com/D4913
--HG--
rename : dom/base/SelectionChangeListener.cpp => dom/base/SelectionChangeEventDispatcher.cpp
rename : dom/base/SelectionChangeListener.h => dom/base/SelectionChangeEventDispatcher.h
extra : moz-landing-system : lando
nsDateTimeControlFrame should be a leaf like all the other <input> frames
like nsTextControlFrame, nsCheckboxRadioFrame, etc.
Differential Revision: https://phabricator.services.mozilla.com/D4985
--HG--
extra : moz-landing-system : lando
SelectionChangeListener is an nsISelectionListener class. This is added only
to Selection for "normal" and added by nsFrameSelection::Init() after
AccessibleCaretEventHub. So, we can make Selection directly treat
SelectionChangeListener.
Differential Revision: https://phabricator.services.mozilla.com/D4757
--HG--
extra : moz-landing-system : lando
AccessibleCaretEventHub is an nsISelectionListener of Selection whose type is
"normal". This is added only when nsFrameSelection::Init() is called and
accessible caret is enabled. Additionally, nsFrameSelection::Init() is
always called immediately after creating nsFrameSelection.
Therefore, when AccessibleCaretEventHub is installed to Selection, this is
always second selection listener and won't be installed multiple times. So,
Selection can store pointer of AccessibleCaretEventHub directly only when
it's enabled and the Selection needs to notify it of selection change.
This patch makes Selection stores AccessibleCaretEventHub with RefPtr, then,
makes Selection::NotifySelectionListeners() call its OnSelectionChange()
immediately after AutoCopyListener.
Unfortunately, this patch includes making of MOZ_CAN_RUN_SCRIPT_BOUNDARY and
MOZ_CAN_RUN_SCRIPT a lot since some methods of AccessibleCaretEventHub are
marked as MOZ_CAN_RUN_SCRIPT and including AccessibleCaretEventHub.h into
Selection.h causes compile the compile errors.
Differential Revision: https://phabricator.services.mozilla.com/D4733
--HG--
extra : moz-landing-system : lando
When the frame updates for an animated image, it will trigger
nsImageBoxFrame::OnFrameUpdate to be called. We did not change this for
WebRender, and thus it was missing similar checks added to
nsImageFrame::InvalidateSelf as originally added in bug 1382985. This
caused us to ignore the frame update, and thus the animation never
appeared to progress.
nsAutoCopyListener is a singleton class but refcountable and a selection
listener. nsFrameSelection adds it to only normal Selection when it's on
macOS or it's enabled by the pref. Additionally, it's always first selection
listener since it's added immediately after Selection instance is created.
So, we can make it a static class, and normal Selection instance should have
a bool to decide whether it should notify nsAutoCopyListener of its changes.
Then, we can save the cost of grabbing it with local RefPtr and the virtual
call.
Additionally, this patch renames nsAutoCopyListener to mozilla::AutoCopyListener
and optimizes constructor of nsFrameSelection (using bool var cache to retrieve
the pref, avoid retrieving the pref on macOS).
Differential Revision: https://phabricator.services.mozilla.com/D4504
--HG--
rename : layout/generic/nsAutoCopyListener.h => layout/generic/AutoCopyListener.h
extra : moz-landing-system : lando
We'll re-do the line anyway, and we'll forget about all the already-positioned
floats in the line DoReflowInlineFrames anyway.
Differential Revision: https://phabricator.services.mozilla.com/D4457
--HG--
extra : moz-landing-system : lando
This flag and function name are used for both basic shapes and path function,
so rename it. For now, we treat path() and other basic-shapes as the
different object (i.e. StyleSVGPath and StyleBasicShape), so I rename
these functions and mask flag.
Differential Revision: https://phabricator.services.mozilla.com/D3636
Bug 1478178 regressed this case because bullet frame is the last frame
added to line layout, rather than the first, so when we try to apply
justification, we end up giving it the accumulated offset of the whole
line.
Bullet frame has to be added after other frames in the line have been
placed, because its presence may depend on whether the line is empty.
However, bullet frame is logically the first frame in a line and
appending it to the end is somewhat counter-intuitive.
Thus, this patch tries to fix the issue via prepending bullet frame in
line layout, so that the order of frames there can be more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D3760
--HG--
extra : moz-landing-system : lando
Scrollable elements already trap all of their contents, nothing should spill
out, so there is no need for special handling of the `contain` CSS property.
Differential Revision: https://phabricator.services.mozilla.com/D3854
--HG--
extra : moz-landing-system : lando
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
- Parse SVG Path String into SVGPathData (in Rust).
- Use cbindgen to make sure the layout of PathCommand and StylePathCommand, and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
- Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Depends on D2962
Differential Revision: https://phabricator.services.mozilla.com/D2963
--HG--
extra : moz-landing-system : lando
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
* Parse SVG Path String into SVGPathData (in Rust).
* Use cbindgen to make sure the layout of PathCommand and StylePathCommand,
and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
* Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part
will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Differential Revision: https://phabricator.services.mozilla.com/D2963
Since fixed position elements are now scrollable, we need to ensure that
they're drawn into the viewport that they're attached to.
MozReview-Commit-ID: ADQXkLjwIzR
--HG--
extra : rebase_source : 2a2ec4983e2ec7f69a3c18389661e00e47ac5277