There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
There's a few subtle behavior changes here, which I'll try to break down in the
commit message.
The biggest one is the EditableDescendantCount stuff going away. This
was added in bug 1181130, to prevent clicking on the non-editable div from
selecting the editable div inside. This is problematic for multiple reasons:
* First, I don't think non-editable regions of an editable element should
be user-select: all.
* Second, it just doesn't work in Shadow DOM (the editable descendant count is
not kept up-to-date when not in the uncomposed doc), so nested
contenteditables behave differently inside vs. outside a Shadow Tree.
* Third, I think it's user hostile to just entirely disable selection if you
have a contenteditable descendant as a child of a user-select: all thing.
WebKit behaves like this patch in the following test-case (though not Blink):
https://crisal.io/tmp/user-select-all-contenteditable-descendant.html
Edge doesn't seem to support user-select: all at all (no pun intended).
But we don't allow to select anything at all which looks wrong.
* Fourth, it's not tested at all (which explains how we broke it in Shadow DOM
and not even notice...).
In any case I've verified that this doesn't regress the editor from that bug. If
this regresses anything we can fix it as outlined in the first bullet point
above, which should also make us more compatible with other UAs in that
test-case.
The other change is `all` not overriding everything else. So, something like:
<div style="-webkit-user-select: all">All <div style="-webkit-user-select: none">None</div></div>
Totally ignores the -webkit-user-select: none declaration in Firefox before this
change. This doesn't match any other UA nor the spec, and this patch aligns us
with WebKit / Blink.
This in turn makes us not need -moz-text anymore, whose only purpose was to
avoid this.
This also fixes a variety of bugs uncovered by the previous changes, like the
SetIgnoreUserModify(false) call in editor being completely useless, since
presShell->SetCaretEnabled ended in nsCaret::SetVisible, which overrode it.
This in turn uncovered even more bugs, from bugs in the caret painting code,
like not checking -moz-user-modify on the right frame if you're the last frame
of a line, to even funnier bits where before this patch you show the caret but
can't write at all...
In any case, the new setup I came up with is that when you're editing (the
selection is focused on an editable node) moving the caret forces it to end up
in an editable node, thus jumping over non-editable ones.
This has the nice effect of not completely disabling selection of
-moz-user-select: all elements that have editable descendants (which was a very
ad-hoc hack for bug 1181130, and somewhat broken per the above), and also
not needing the -moz-user-select: all for non-editable bits in contenteditable.css
at all.
This also fixes issues with br-skipping like not being able to insert content in
the following test-case:
<div contenteditable="true"><span contenteditable="false">xyz </span><br>editable</div>
If you start moving to the left from the second line, for example.
I think this yields way better behavior in all the relevant test-cases from bug
1181130 / bug 1109968 / bug 1132768, shouldn't cause any regression, and the
complexity is significantly reduced in some places.
There's still some other broken bits that this patch doesn't fix, but I'll file
follow-ups for those.
Differential Revision: https://phabricator.services.mozilla.com/D12687
Now we no longer update the corresponding display items for the animations that
are prevented from running on the compositor if the animations themselves don't
generate any change hints, e.g the same value is specified in both 'from' and
'to' keyframes. So that we can enable the reftests that we had been suffering
from continuous MozAfterPaint events.
Depends on D12397
Differential Revision: https://phabricator.services.mozilla.com/D12369
The modification to nsLayoutUtils::GetFirstLinePosition() is needed because we
need to get the correct first line position from child (i.e. ColumnSet) when
there's an outside bullet on ColumnSetWrapperFrame.
The difference between the two newly added tests is "overflow: hidden" on
the columns.
Differential Revision: https://phabricator.services.mozilla.com/D7009
This change eliminates
- nsLayoutUtils::LastContinuationOrIBSplitSibling calls for each CSS
properties on WebRender
- iterating over each display item for each compositor runnable CSS properties
- a bunch of stuff in the case where the layer manager has not yet created,
i.e. the compositor thread is not ready to receive animations
Depends on D11425
Differential Revision: https://phabricator.services.mozilla.com/D11426
This change gets all effective CSS properties on an nsIFrame just once.
Note that LayerAnimationInfo::GetCSSPropertiesFor intentionally returns
nsCSSPropertyIDSet instead of nsCSSPropertyID since when we support individual
transform properties for the compositor the mapping between display item types
and nsCSSProperty has to be 1:N. E.g. all scale/translate/rotate properties are
mapped to transform display item.
Depends on D11424
Differential Revision: https://phabricator.services.mozilla.com/D11425
It doesn't make much sense to return const UniquePtr<Foo>& for something that
can't be null, it's just confusing.
Also make more stuff actually const.
Differential Revision: https://phabricator.services.mozilla.com/D10647
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
1. Drop {Width|MinWidth|MaxWidh}DependsOnContainer() and
{Height|MinHeight|MaxHeight}DependsOnContainer() because they are bogus
after introducing the writing mode. Dropping these functions needs
update nsLineLayout because it is the only one who still use
these functions.
2. There are still some potential assertions and bugs on handling keywords
in the block size, so we should update them as well.
Depends on D9438
Differential Revision: https://phabricator.services.mozilla.com/D9439
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
FrameMetrics is currently used in about three ways.
1. Main thread to APZ transactions
2. Storing information in AsyncPanZoomController
3. APZ to main thread repaint requests
There's overlap in the use of fields in all these use cases, but it's not perfect. In a
following commit, I'd like to change the information used for (1) to support relative
scroll offset updates. This information isn't needed for (2) or (3), so it would be
good to refactor FrameMetrics out into these use cases.
This commit refactors out (3) as it is fairly easy to do. I'd like to refactor (2) out
as well, but that is trickier. I'd like to leave that for a future followup.
Differential Revision: https://phabricator.services.mozilla.com/D7127
We need to correctly populate the cumulative resolution field in the
ScrollMetadata in order to support zooming. Without this, the cumulative
resolution doesn't include the presShell resolution, and that results in
APZ getting into an inconsistent state.
Currently, the cumulative resolution is populated from the
ContainerLayerParameters object's scale, but in the case of WebRender,
we call ComputeScrollMetadata with an empty ContainerLayerParameters
since don't actually do layer building or rasterization in Gecko.
This patch makes this more explicit by changing the argument to a
Maybe<ContainerLayerParameters> and passing Nothing() from the WebRender
call sites.
In this scenario, we just use the cumulative presShell resolution as
the cumulative resolution, which should be correct for WebRender as
we won't have an "extra" CSS-derived resolution applied on the Gecko
side.
Depends on D9120
Differential Revision: https://phabricator.services.mozilla.com/D9121
In order to get the correct computed value of these keywords, we have to
make sure we store the correct computed values in sizing properties in
both inline axis and block axis.
-moz-max-content and -moz-min-content should behave as the property's
initial value in block axis. -moz-fit-content and -moz-available are not
supported in block axis, so we also treat them as initial values.
Differential Revision: https://phabricator.services.mozilla.com/D8290
We need to move EditorEventListener::HandleMiddleClickPaste() into
EventStateManager to handle middle click paste after all click events are
dispatched. This is preparation of the change.
HandleMiddleClickPaste() uses UIEvent::GetRangeParent() and
UIEvent::RangeOffset() to collapse Selection at clicked point. However,
EventStateManager cannot access them since EventStateManager can handle it
with WidgetMouseEvent. Fortunately, only WidgetMouseEvent is necessary for
implementing them. Therefore, we can move the implementation into
nsLayoutUtils and merge them.
Differential Revision: https://phabricator.services.mozilla.com/D7851
The CSSWG has recently resolved that layout containment
suppress baseline alignment, while size containment does not:
https://github.com/w3c/csswg-drafts/issues/2995
Spec text (https://drafts.csswg.org/css-contain/#containment-layout):
"7. For the purpose of the vertical-align property,
or any other property whose effects need to relate
the position of the containing element's baseline
to something other than its descendants,
the containing element is treated as having no baseline."
And a note in (https://drafts.csswg.org/css-contain/#containment-size):
"Note: size containment does not suppress baseline alignment.
See layout containment for that."
This patch does this change just switching IsContainSize()
by IsLayoutSize() in several places related to baseline alignment
in the source code.
With the patch several WPT tests start to pass. Apart from that,
some of the tests under vendor-imports are updated to follow
the new behavior.
Previously we would log the displayport and the critical displayport separately,
which made it more difficult to write cross-platform APZ tests.
Differential Revision: https://phabricator.services.mozilla.com/D7341
When one of the two factors governing the effective container width for font
inflation changes, we need to mark all affected frames as dirty.
While the visible area commonly changes because of viewport changes and we can
catch those through the check for ISize resizes of the top-level frame
("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation
of the effective container width into the FontInflationData itself, especially
since the effective container width calculation in nsLayoutUtils is the only
consumer of the NCAISize currently stored by the FontInflationData.
That way
- we can be sure that really all changes of the visible width will correctly
mark all affected frames as dirty
- can avoid repeatedly recalculating the effective container width
- can also detect the cases where the effective container width actually remains
the same after a change in one of its input factors and skip forcing a full
dirty reflow for all descendants just because of font inflation.
While the code in nsLayoutUtils was technically always using the writing
mode (horizontal/vertical) of each individual frame for determining which
dimension of the visible size should be used for clamping, just using the
writing mode of the respective flow root should be enough, since each change in
the writing mode should create a new flow root.
This assumption should already hold today because
1. as per the Writing Modes CSS spec, a change in writing mode compared to its
parent means that the affected block cannot be purely "inline", but at most
"inline-block".
2. Generally, any non-inline frame will be marked as a font inflation container.
3. Any block frame whose writing direction doesn't match its parent will be a
block formatting context, which implies NS_BLOCK_FLOAT_MGR.
4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation
container will also become a font inflation flow root.
but because this chain of reasoning is not the most direct, we also add a
corresponding assertion to better catch any potential bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D5578
When one of the two factors governing the effective container width for font
inflation changes, we need to mark all affected frames as dirty.
While the visible area commonly changes because of viewport changes and we can
catch those through the check for ISize resizes of the top-level frame
("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation
of the effective container width into the FontInflationData itself, especially
since the effective container width calculation in nsLayoutUtils is the only
consumer of the NCAISize currently stored by the FontInflationData.
That way
- we can be sure that really all changes of the visible width will correctly
mark all affected frames as dirty
- can avoid repeatedly recalculating the effective container width
- can also detect the cases where the effective container width actually remains
the same after a change in one of its input factors and skip forcing a full
dirty reflow for all descendants just because of font inflation.
While the code in nsLayoutUtils was technically always using the writing
direction of each individual frame for determining which dimension of the
visible size should be used for clamping, just using the writing direction of
the respective flow root should be enough, since each change in writing
direction should create a new flow root.
This assumption should already hold today because
1. as per the Writing Modes CSS spec, a change in writing mode compared to its
parent means that the affected block cannot be purely "inline", but at most
"inline-block".
2. Generally, any non-inline frame will be marked as a font inflation container.
3. Any block frame whose writing direction doesn't match its parent will be a
block formatting context, which implies NS_BLOCK_FLOAT_MGR.
4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation
container will also become a font inflation flow root.
but because this chain of reasoning is not the most direct, we also add a
corresponding assertion to better catch any potential bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D5578
