The SCROLLABLE_FIXEDPOS_FINDS_ROOT flag makes GetNearestScrollableFrame return the root scroll frame for fixed pos frames. Fixed pos frames are direct children of the root _frame_, which means that the frame we pass to TransformFrameRectToAncestor are not ancestors of each other in either direction.
Differential Revision: https://phabricator.services.mozilla.com/D73587
The SCROLLABLE_FIXEDPOS_FINDS_ROOT flag makes GetNearestScrollableFrame return the root scroll frame for fixed pos frames. Fixed pos frames are direct children of the root _frame_, which means that the frame we pass to TransformFrameRectToAncestor are not ancestors of each other in either direction.
So we treat fixed pos frames specially and don't pass that flag.
Differential Revision: https://phabricator.services.mozilla.com/D73587
Even with the fix above, we get the caret baseline wrong because the
line is non-empty, but the baseline is all the way to the top.
Maybe an alternative to this would be to move the line-height hack to
the beginning of layout but that sounds a bit more fishy.
Otherwise we should do this more often, I suspect. I added one test that
fails because of nsInlineFrame... Anyhow probably follow-up material?
Depends on D73362
Differential Revision: https://phabricator.services.mozilla.com/D73363
It seems like a reasonable expectation, but it may not hold with massive
ratios. Make it hold by returning the floating point epsilon in that
case.
Differential Revision: https://phabricator.services.mozilla.com/D73029
Even in comm-central and BlueGriffon, `nsISelectionController::*ForDelete()`
are not used. Therefore, we can remove them safely.
Differential Revision: https://phabricator.services.mozilla.com/D72296
Currently, `EditorBase::ExtendSelectionForDelete()` depends on some
`nsISelectionController` methods to compute extended range for deletion
from collapsed selection. They are implemented by
`nsFrameSelection::MoveCaret()` and `nsFrameSelection::TakeFocus()`.
Ideally, we should split these methods for computation part and performing
part. However, they change selection with updating other selection state,
for example, table selection state and bidi information. Therefore, it's
impossible to split them with simple code. However, I need to change
`EditorBase::ExtendSelectionForDelete()` just return extended range.
Therefore, this patch creates `nsFrameSelection::PeekOffsetForCaretMove()`
which has the main path in `MoveCaret()` for the `EditorBase` method.
Then, `MoveCaret()` and new `nsFrameSelection::CreateRangeExtendedToSomewhere()`
share the computation code of expanding normal selection.
Finally, this patch wraps `nsFrameSelection::CreateRangeExtendedToSomewhere()`
with new public inline methods for `EditorBase`.
The following patch will remove no-user methods of `nsISelectionController`.
Differential Revision: https://phabricator.services.mozilla.com/D72295
Fixes tooltips/menus in responsive design mode. A few accesibility tests
had to be adjusted since tooltips are now automatically created
for them.
Differential Revision: https://phabricator.services.mozilla.com/D72400
I believe the image descriptor was stale, since the code that updated it
was only doing this in case of a new image key. So if there was a new scene with the same image key
but different image descriptor, we'd not be updating it properly.
Differential Revision: https://phabricator.services.mozilla.com/D72404
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This allows headers which nsLayoutUtils.h includes to use these types without
creating a circular dependency.
As part of this change, the types are also moved into namespace mozilla.
Differential Revision: https://phabricator.services.mozilla.com/D71704
This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
The check for generated content in nsTextFrame is to the best of my
knowledge useless: We don't display generated content as selected when
the parent is selected anyhow, and the offsets would be wrong.
We special-case text inputs and textarea because of ::placeholder, see
the comment, but otherwise there's no reason you shouldn't be able to
find-in-page generated content / fallback / etc.
I added ForceBreakBetween so as to not create ranges that span across
shadow / anonymous content boundaries. They don't work anyway (see the
TODO in test_find.html), so it seems better to make that explicit until
we properly handle them (bug 1590379).
I added a pref just to be safe since this is long-standing behavior, but
I think it should be uncontroversial.
Differential Revision: https://phabricator.services.mozilla.com/D72447
`DeleteSelection*()` are members of `TextEditor`, but they are also used by
`HTMLEditor`. Therefore, they and pref cache members for them should be
in `EditorBase` too.
Depends on D71911
Differential Revision: https://phabricator.services.mozilla.com/D72290
nsBidi.h currently includes nsIFrame.h only to import nsBidi* types. This patch moves those types to nsBidi.h where it's more relevant, to reduce the size of nsIFrame.h.
Differential Revision: https://phabricator.services.mozilla.com/D72442
This is used by platforms with overlay scrollbars, only in order to
reserve enough space for the chevron of the `<select>` element.
So our general min-widget-size, which is the same as for scrollbars
works.
Differential Revision: https://phabricator.services.mozilla.com/D71825