I assume nsIFrame::IsAbsolutelyPositioned()'s callers really want to
check whether a frame is a real abspos frame, not just check a frame has
a abspos style. This could potentially change the behavior, but I feel
its the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D106580
IsFontSizeInflationContainer() is a helper of nsIFrame::Init(). That is,
when it is called from a caller like
nsCSSFrameConstructor::CreateFloatingLetterFrame(), the
`NS_FRAME_OUT_OF_FLOW` bit is not set yet. There is also a hint at the
call site
https://searchfox.org/mozilla-central/rev/362676fcadac37f9f585141a244a9a640948794a/layout/generic/nsIFrame.cpp#770
To fix it, we need to change the condition to check only the
floating style.
layout/reftests/bidi/with-first-letter-2b.html is one of the testcases
that can trigger the following assertion without this patch.
###!!! ASSERTION: should not be container for font size inflation
Differential Revision: https://phabricator.services.mozilla.com/D106579
Currently when selecting the scroll root for picture caching, if a
non-Zoom transform is encountered we give up and select the root
spatial node. This is because the transform may be non-axis aligned.
When the Fenix dynamic toolbar is enabled, fixed position items must
create a spatial node with an animated transform, so that they can be
positioned asynchronously by APZ when the toolbar moves.
The combination of these two things means for that scroll frames
within fixed position items we always select the root spatial node,
meaning that the entire contents invalidates continuously while
scrolling.
To fix this, add a flag to the Transform ReferenceFrameKind which
marks the transform as always being a 2D scale or translation. When
selecting the scroll root, we can continue searching through such
reference frames, as we already do for Zoom frames. Set this flag true
for references frames created due to the dynamic toolbar.
Additionally, assert that the transform is indeed a 2d scale or
translation after it is resolved.
The condition of the transform being only a 2d scale and translation
is shared with ReferenceFrameKind::Zoom, so that has been removed and
its uses updated to use this new flag instead. An additional
should_snap flag has also been added, so that we continue to snap zoom
transforms, and additionally snap the dynamic-toolbar related
transforms too.
Lastly, this adds some unit tests for find_scroll_root.
Differential Revision: https://phabricator.services.mozilla.com/D106809
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Chrome and Safari move selection at middle button down and does not modify the
range at middle button up. However, they handle middle button down with
`Shift` key is "continue selection". So, we should handle selection in
nsIFrame when `mousedown` event for middle mouse button is fired, but ignore
multiple selection, drag and drop and maintaining selection for aligning the
behavior to the other browsers.
This patch splits `nsIFrame::HandlePress()` and calls new method which
moves selection from `nsIFrame::HandleEvent()` when middle button is pressed.
(Note that this patch does not check whether middle click paste is enabled
because Chrome moves selection even on Windows which Chrome always disable
middle click paste on.)
With this change, "paste" event target is changed. Previously, we used target
of the preceding `mouseup` event, but we start to use the target of the
preceding `mousedown` event.
Note that even with this patch, we still behave differently from Chrome even
in the following cases:
- middle mouse button down in selected range, we collapse it, but Chrome keeps
the selection.
- middle mouse button click in selected range, we dispatch "paste" event, but
Chrome collapse selection and not dispatch "paste" event.
- middle mouse button down in selected range and up in different element,
Chrome does not modify the range nor dispatch "paste" event.
- Shift + middle mouse button in editable `<table>` works as non-editable
in Chrome, but our editor handles it with special path. Therefore, we
don't modify the range but dispatch "paste" event in the selected range.
Changing them requires bigger change and probably requires some other features'
behavior changes. Therefore, we shouldn't touch these issues until they are
actually reported as web-compat issues.
Differential Revision: https://phabricator.services.mozilla.com/D103997
Actually, WPT has no some word-break tests for Japanese (ID and CJ) and
Korean (Hangul Jamos).
So I would like to move layout/reftests/text/wordbreak-2.html and
layout/reftests/text/wordbreak-4a.html into WPT.
Differential Revision: https://phabricator.services.mozilla.com/D105227
GetValue is going to be removed in a subsequent patch. It is no longer needed,
because it can be replaced by functions already provided by nsBaseHashtable,
in particular Lookup and Contains.
Also, its name was confusing, since it specifically returns a pointer that
allows and is intended for modifying the entry within the hashtable, rather
than returning by-value. According to the naming rules to be set on
nsBaseHashtable, it would also needed to be renamed to "Lookup*. Removing
its uses saves this effort.
Differential Revision: https://phabricator.services.mozilla.com/D105476
Backs out bug 1599173 which landed in Firefox 72. The pref has been enabled since bug 1600855 which landed in Firefox 73
Differential Revision: https://phabricator.services.mozilla.com/D106731
cs_clip_rectangle is slow because we evaluate distance AA for every fragment
the shader touches. With SWGL, we can do much better since we have control
over span. We calculate an inner opaque octagon which can just use a cheap
solid fill and an outer AA octagon within which we need to actually we do
AA and outside which we can just do another solid clear. This reduces most
of the cost of rounded-rectangles to just some setup work, a few fragments
of distance AA on the ends of a span, and large runs of solid color where
we don't have to do much work.
Differential Revision: https://phabricator.services.mozilla.com/D106658
