gecko-dev/layout/base/nsCaret.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

918 lines
32 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 11:12:37 +00:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
1999-02-11 23:49:08 +00:00
/* the caret is the text cursor used, e.g., when editing */
1999-02-11 23:49:08 +00:00
#include "nsCaret.h"
1999-02-11 23:49:08 +00:00
#include <algorithm>
1999-02-11 23:49:08 +00:00
#include "gfxUtils.h"
#include "mozilla/gfx/2D.h"
#include "nsCOMPtr.h"
#include "nsFontMetrics.h"
#include "nsITimer.h"
#include "nsFrameSelection.h"
1999-02-11 23:49:08 +00:00
#include "nsIFrame.h"
#include "nsIScrollableFrame.h"
1999-02-11 23:49:08 +00:00
#include "nsIContent.h"
#include "nsIPresShell.h"
#include "nsLayoutUtils.h"
#include "nsPresContext.h"
1999-09-14 23:41:19 +00:00
#include "nsBlockFrame.h"
2000-04-27 07:37:12 +00:00
#include "nsISelectionController.h"
#include "nsTextFrame.h"
#include "nsXULPopupManager.h"
#include "nsMenuPopupFrame.h"
#include "nsTextFragment.h"
#include "mozilla/Preferences.h"
#include "mozilla/LookAndFeel.h"
#include "mozilla/dom/Selection.h"
#include "nsIBidiKeyboard.h"
#include "nsContentUtils.h"
using namespace mozilla;
using namespace mozilla::dom;
using namespace mozilla::gfx;
// The bidi indicator hangs off the caret to one side, to show which
// direction the typing is in. It needs to be at least 2x2 to avoid looking like
// an insignificant dot
static const int32_t kMinBidiIndicatorPixels = 2;
// The default caret blinking rate (in ms of blinking interval)
static const uint32_t kDefaultCaretBlinkRate = 500;
/**
* Find the first frame in an in-order traversal of the frame subtree rooted
* at aFrame which is either a text frame logically at the end of a line,
* or which is aStopAtFrame. Return null if no such frame is found. We don't
* descend into the children of non-eLineParticipant frames.
*/
static nsIFrame* CheckForTrailingTextFrameRecursive(nsIFrame* aFrame,
nsIFrame* aStopAtFrame) {
if (aFrame == aStopAtFrame ||
((aFrame->IsTextFrame() &&
(static_cast<nsTextFrame*>(aFrame))->IsAtEndOfLine())))
return aFrame;
if (!aFrame->IsFrameOfType(nsIFrame::eLineParticipant)) return nullptr;
for (nsIFrame* f : aFrame->PrincipalChildList()) {
nsIFrame* r = CheckForTrailingTextFrameRecursive(f, aStopAtFrame);
if (r) return r;
}
return nullptr;
}
static nsLineBox* FindContainingLine(nsIFrame* aFrame) {
while (aFrame && aFrame->IsFrameOfType(nsIFrame::eLineParticipant)) {
nsIFrame* parent = aFrame->GetParent();
nsBlockFrame* blockParent = nsLayoutUtils::GetAsBlock(parent);
if (blockParent) {
bool isValid;
nsBlockInFlowLineIterator iter(blockParent, aFrame, &isValid);
return isValid ? iter.GetLine().get() : nullptr;
}
aFrame = parent;
}
return nullptr;
}
static void AdjustCaretFrameForLineEnd(nsIFrame** aFrame, int32_t* aOffset) {
nsLineBox* line = FindContainingLine(*aFrame);
if (!line) return;
int32_t count = line->GetChildCount();
for (nsIFrame* f = line->mFirstChild; count > 0;
--count, f = f->GetNextSibling()) {
nsIFrame* r = CheckForTrailingTextFrameRecursive(f, *aFrame);
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
if (r == *aFrame) {
return;
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
}
if (r) {
// We found our frame, but we may not be able to properly paint the caret
// if -moz-user-modify differs from our actual frame.
MOZ_ASSERT(r->IsTextFrame(), "Expected text frame");
*aFrame = r;
*aOffset = (static_cast<nsTextFrame*>(r))->GetContentEnd();
return;
}
}
}
static bool IsBidiUI() { return Preferences::GetBool("bidi.browser.ui"); }
Bug 1048752. Part 22: Factor out SelectionLanguageChange call to run early in nsCaret::GetPaintGeometry. r=tn This code is somewhat tricky. nsCaret::ComputeCaretRects was checking to see if we have a bidi keyboard, and if so, what direction it's set to. If the direction changed from the last direction seen for *this caret*, we fired a SelectionLanguageChange notification on the caret's current Selection. This looked bogus because the caret can be switched between selections so it would seem some selections won't get a notification when they should, but that's how it was. Also, when the SelectionLanguageChange notification fired we then didn't draw the caret in that iteration, which seems even more bogus. This patch fixes all that by moving the logic to fire SelectionLanguageChange out to GetPaintGeometry and firing the notification every single time without trying to detect whether the state has changed or not. I carefully examined the implementation of SelectionLanguageChange and I'm pretty sure it's idempotent so this should be correct. That doesn't look like an expensive function, and runs at most once per window paint, so I'm not worried about perf. Because we now fire SelectionLanguageChange before reading selection or frame state, it should be fine to carry on after calling SelectionLanguageChange and drawing the caret based on whatever changes SelectionLanguageChange has performed. This also lets us remove mKeyboardRTL, which as noted above seems inherently bogus. --HG-- extra : rebase_source : 3ddfd10f6f30033e090e72b4bb43f2695218752e
2014-08-06 05:19:28 +00:00
1999-02-11 23:49:08 +00:00
nsCaret::nsCaret()
: mOverrideOffset(0),
mBlinkCount(-1),
mBlinkRate(0),
mHideCount(0),
mIsBlinkOn(false),
mVisible(false),
mReadOnly(false),
mShowDuringSelection(false),
mIgnoreUserModify(true) {}
1999-02-11 23:49:08 +00:00
nsCaret::~nsCaret() { StopBlinking(); }
nsresult nsCaret::Init(nsIPresShell* inPresShell) {
NS_ENSURE_ARG(inPresShell);
mPresShell =
do_GetWeakReference(inPresShell); // the presshell owns us, so no addref
NS_ASSERTION(mPresShell, "Hey, pres shell should support weak refs");
2000-04-27 07:37:12 +00:00
mShowDuringSelection =
LookAndFeel::GetInt(LookAndFeel::eIntID_ShowCaretDuringSelection,
mShowDuringSelection ? 1 : 0) != 0;
// get the selection from the pres shell, and set ourselves up as a selection
// listener
2000-04-27 07:37:12 +00:00
nsCOMPtr<nsISelectionController> selCon = do_QueryReferent(mPresShell);
if (!selCon) {
2000-04-27 07:37:12 +00:00
return NS_ERROR_FAILURE;
}
RefPtr<Selection> selection =
selCon->GetSelection(nsISelectionController::SELECTION_NORMAL);
if (!selection) {
return NS_ERROR_FAILURE;
}
selection->AddSelectionListener(this);
mDomSelectionWeak = selection;
return NS_OK;
1999-02-11 23:49:08 +00:00
}
static bool DrawCJKCaret(nsIFrame* aFrame, int32_t aOffset) {
nsIContent* content = aFrame->GetContent();
const nsTextFragment* frag = content->GetText();
if (!frag) return false;
if (aOffset < 0 || uint32_t(aOffset) >= frag->GetLength()) return false;
char16_t ch = frag->CharAt(aOffset);
return 0x2e80 <= ch && ch <= 0xd7ff;
}
nsCaret::Metrics nsCaret::ComputeMetrics(nsIFrame* aFrame, int32_t aOffset,
nscoord aCaretHeight) {
// Compute nominal sizes in appunits
nscoord caretWidth =
(aCaretHeight *
LookAndFeel::GetFloat(LookAndFeel::eFloatID_CaretAspectRatio, 0.0f)) +
nsPresContext::CSSPixelsToAppUnits(
LookAndFeel::GetInt(LookAndFeel::eIntID_CaretWidth, 1));
if (DrawCJKCaret(aFrame, aOffset)) {
caretWidth += nsPresContext::CSSPixelsToAppUnits(1);
}
nscoord bidiIndicatorSize =
nsPresContext::CSSPixelsToAppUnits(kMinBidiIndicatorPixels);
bidiIndicatorSize = std::max(caretWidth, bidiIndicatorSize);
// Round them to device pixels. Always round down, except that anything
// between 0 and 1 goes up to 1 so we don't let the caret disappear.
int32_t tpp = aFrame->PresContext()->AppUnitsPerDevPixel();
Metrics result;
result.mCaretWidth = NS_ROUND_BORDER_TO_PIXELS(caretWidth, tpp);
result.mBidiIndicatorSize = NS_ROUND_BORDER_TO_PIXELS(bidiIndicatorSize, tpp);
return result;
}
1999-02-11 23:49:08 +00:00
void nsCaret::Terminate() {
// this doesn't erase the caret if it's drawn. Should it? We might not have
// a good drawing environment during teardown.
StopBlinking();
mBlinkTimer = nullptr;
// unregiser ourselves as a selection listener
if (mDomSelectionWeak) {
mDomSelectionWeak->RemoveSelectionListener(this);
}
mDomSelectionWeak = nullptr;
mPresShell = nullptr;
mOverrideContent = nullptr;
}
NS_IMPL_ISUPPORTS(nsCaret, nsISelectionListener)
1999-02-11 23:49:08 +00:00
Selection* nsCaret::GetSelection() { return mDomSelectionWeak; }
void nsCaret::SetSelection(Selection* aDOMSel) {
MOZ_ASSERT(aDOMSel);
mDomSelectionWeak = aDOMSel;
ResetBlinking();
SchedulePaint(aDOMSel);
}
void nsCaret::SetVisible(bool inMakeVisible) {
mVisible = inMakeVisible;
mIgnoreUserModify = mVisible;
ResetBlinking();
SchedulePaint();
1999-02-11 23:49:08 +00:00
}
void nsCaret::AddForceHide() {
MOZ_ASSERT(mHideCount < UINT32_MAX);
if (++mHideCount > 1) {
return;
}
ResetBlinking();
SchedulePaint();
}
void nsCaret::RemoveForceHide() {
if (!mHideCount || --mHideCount) {
return;
}
ResetBlinking();
SchedulePaint();
}
void nsCaret::SetCaretReadOnly(bool inMakeReadonly) {
mReadOnly = inMakeReadonly;
ResetBlinking();
SchedulePaint();
1999-02-11 23:49:08 +00:00
}
/* static */ nsRect nsCaret::GetGeometryForFrame(nsIFrame* aFrame,
int32_t aFrameOffset,
nscoord* aBidiIndicatorSize) {
nsPoint framePos(0, 0);
nsRect rect;
nsresult rv = aFrame->GetPointFromOffset(aFrameOffset, &framePos);
if (NS_FAILED(rv)) {
if (aBidiIndicatorSize) {
*aBidiIndicatorSize = 0;
}
return rect;
}
nsIFrame* frame = aFrame->GetContentInsertionFrame();
if (!frame) {
frame = aFrame;
}
NS_ASSERTION(!(frame->GetStateBits() & NS_FRAME_IN_REFLOW),
"We should not be in the middle of reflow");
nscoord baseline = frame->GetCaretBaseline();
nscoord ascent = 0, descent = 0;
RefPtr<nsFontMetrics> fm =
nsLayoutUtils::GetInflatedFontMetricsForFrame(aFrame);
NS_ASSERTION(fm, "We should be able to get the font metrics");
if (fm) {
ascent = fm->MaxAscent();
descent = fm->MaxDescent();
}
nscoord height = ascent + descent;
WritingMode wm = aFrame->GetWritingMode();
bool vertical = wm.IsVertical();
if (vertical) {
if (wm.IsLineInverted()) {
framePos.x = baseline - descent;
} else {
framePos.x = baseline - ascent;
}
} else {
framePos.y = baseline - ascent;
}
Metrics caretMetrics = ComputeMetrics(aFrame, aFrameOffset, height);
nsTextFrame* textFrame = do_QueryFrame(aFrame);
if (textFrame) {
gfxTextRun* textRun =
textFrame->GetTextRun(nsTextFrame::TextRunType::eInflated);
if (textRun) {
// For "upstream" text where the textrun direction is reversed from the
// frame's inline-dir we want the caret to be painted before rather than
// after its nominal inline position, so we offset by its width.
bool textRunDirIsReverseOfFrame =
wm.IsInlineReversed() != textRun->IsInlineReversed();
// However, in sideways-lr mode we invert this behavior because this is
// the one writing mode where bidi-LTR corresponds to inline-reversed
// already, which reverses the desired caret placement behavior.
// Note that the following condition is equivalent to:
// if ( (!textRun->IsSidewaysLeft() && textRunDirIsReverseOfFrame) ||
// (textRun->IsSidewaysLeft() && !textRunDirIsReverseOfFrame) )
if (textRunDirIsReverseOfFrame != textRun->IsSidewaysLeft()) {
int dir = wm.IsBidiLTR() ? -1 : 1;
if (vertical) {
framePos.y += dir * caretMetrics.mCaretWidth;
} else {
framePos.x += dir * caretMetrics.mCaretWidth;
}
}
}
}
rect = nsRect(framePos, vertical ? nsSize(height, caretMetrics.mCaretWidth)
: nsSize(caretMetrics.mCaretWidth, height));
// Clamp the inline-position to be within our scroll frame. If we don't, then
// it clips us, and we don't appear at all. See bug 335560.
nsIFrame* scrollFrame =
nsLayoutUtils::GetClosestFrameOfType(aFrame, LayoutFrameType::Scroll);
if (scrollFrame) {
// First, use the scrollFrame to get at the scrollable view that we're in.
nsIScrollableFrame* sf = do_QueryFrame(scrollFrame);
nsIFrame* scrolled = sf->GetScrolledFrame();
nsRect caretInScroll = rect + aFrame->GetOffsetTo(scrolled);
// Now see if the caret extends beyond the view's bounds. If it does,
// then snap it back, put it as close to the edge as it can.
if (vertical) {
nscoord overflow = caretInScroll.YMost() -
scrolled->GetVisualOverflowRectRelativeToSelf().height;
if (overflow > 0) {
rect.y -= overflow;
}
} else {
nscoord overflow = caretInScroll.XMost() -
scrolled->GetVisualOverflowRectRelativeToSelf().width;
if (overflow > 0) {
rect.x -= overflow;
}
}
}
if (aBidiIndicatorSize) {
*aBidiIndicatorSize = caretMetrics.mBidiIndicatorSize;
}
return rect;
}
nsIFrame* nsCaret::GetFrameAndOffset(Selection* aSelection,
nsINode* aOverrideNode,
int32_t aOverrideOffset,
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
int32_t* aFrameOffset,
nsIFrame** aUnadjustedFrame) {
if (aUnadjustedFrame) {
*aUnadjustedFrame = nullptr;
}
nsINode* focusNode;
int32_t focusOffset;
if (aOverrideNode) {
focusNode = aOverrideNode;
focusOffset = aOverrideOffset;
} else if (aSelection) {
focusNode = aSelection->GetFocusNode();
focusOffset = aSelection->FocusOffset();
} else {
return nullptr;
}
if (!focusNode || !focusNode->IsContent()) {
return nullptr;
}
nsIContent* contentNode = focusNode->AsContent();
nsFrameSelection* frameSelection = aSelection->GetFrameSelection();
nsBidiLevel bidiLevel = frameSelection->GetCaretBidiLevel();
nsIFrame* frame;
nsresult rv = nsCaret::GetCaretFrameForNodeOffset(
frameSelection, contentNode, focusOffset, frameSelection->GetHint(),
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
bidiLevel, &frame, aUnadjustedFrame, aFrameOffset);
if (NS_FAILED(rv) || !frame) {
return nullptr;
}
return frame;
}
/* static */ nsIFrame* nsCaret::GetGeometry(Selection* aSelection,
nsRect* aRect) {
int32_t frameOffset;
nsIFrame* frame = GetFrameAndOffset(aSelection, nullptr, 0, &frameOffset);
if (frame) {
*aRect = GetGeometryForFrame(frame, frameOffset, nullptr);
}
return frame;
}
void nsCaret::SchedulePaint(Selection* aSelection) {
Selection* selection;
if (aSelection) {
selection = aSelection;
} else {
selection = GetSelection();
}
int32_t frameOffset;
nsIFrame* frame = GetFrameAndOffset(selection, mOverrideContent,
mOverrideOffset, &frameOffset);
if (frame) {
frame->SchedulePaint();
}
}
void nsCaret::SetVisibilityDuringSelection(bool aVisibility) {
mShowDuringSelection = aVisibility;
SchedulePaint();
}
void nsCaret::SetCaretPosition(nsINode* aNode, int32_t aOffset) {
mOverrideContent = aNode;
mOverrideOffset = aOffset;
ResetBlinking();
SchedulePaint();
}
Bug 1048752. Part 22: Factor out SelectionLanguageChange call to run early in nsCaret::GetPaintGeometry. r=tn This code is somewhat tricky. nsCaret::ComputeCaretRects was checking to see if we have a bidi keyboard, and if so, what direction it's set to. If the direction changed from the last direction seen for *this caret*, we fired a SelectionLanguageChange notification on the caret's current Selection. This looked bogus because the caret can be switched between selections so it would seem some selections won't get a notification when they should, but that's how it was. Also, when the SelectionLanguageChange notification fired we then didn't draw the caret in that iteration, which seems even more bogus. This patch fixes all that by moving the logic to fire SelectionLanguageChange out to GetPaintGeometry and firing the notification every single time without trying to detect whether the state has changed or not. I carefully examined the implementation of SelectionLanguageChange and I'm pretty sure it's idempotent so this should be correct. That doesn't look like an expensive function, and runs at most once per window paint, so I'm not worried about perf. Because we now fire SelectionLanguageChange before reading selection or frame state, it should be fine to carry on after calling SelectionLanguageChange and drawing the caret based on whatever changes SelectionLanguageChange has performed. This also lets us remove mKeyboardRTL, which as noted above seems inherently bogus. --HG-- extra : rebase_source : 3ddfd10f6f30033e090e72b4bb43f2695218752e
2014-08-06 05:19:28 +00:00
void nsCaret::CheckSelectionLanguageChange() {
if (!IsBidiUI()) {
return;
}
bool isKeyboardRTL = false;
nsIBidiKeyboard* bidiKeyboard = nsContentUtils::GetBidiKeyboard();
if (bidiKeyboard) {
bidiKeyboard->IsLangRTL(&isKeyboardRTL);
}
// Call SelectionLanguageChange on every paint. Mostly it will be a noop
// but it should be fast anyway. This guarantees we never paint the caret
// at the wrong place.
Selection* selection = GetSelection();
if (selection) {
selection->SelectionLanguageChange(isKeyboardRTL);
Bug 1048752. Part 22: Factor out SelectionLanguageChange call to run early in nsCaret::GetPaintGeometry. r=tn This code is somewhat tricky. nsCaret::ComputeCaretRects was checking to see if we have a bidi keyboard, and if so, what direction it's set to. If the direction changed from the last direction seen for *this caret*, we fired a SelectionLanguageChange notification on the caret's current Selection. This looked bogus because the caret can be switched between selections so it would seem some selections won't get a notification when they should, but that's how it was. Also, when the SelectionLanguageChange notification fired we then didn't draw the caret in that iteration, which seems even more bogus. This patch fixes all that by moving the logic to fire SelectionLanguageChange out to GetPaintGeometry and firing the notification every single time without trying to detect whether the state has changed or not. I carefully examined the implementation of SelectionLanguageChange and I'm pretty sure it's idempotent so this should be correct. That doesn't look like an expensive function, and runs at most once per window paint, so I'm not worried about perf. Because we now fire SelectionLanguageChange before reading selection or frame state, it should be fine to carry on after calling SelectionLanguageChange and drawing the caret based on whatever changes SelectionLanguageChange has performed. This also lets us remove mKeyboardRTL, which as noted above seems inherently bogus. --HG-- extra : rebase_source : 3ddfd10f6f30033e090e72b4bb43f2695218752e
2014-08-06 05:19:28 +00:00
}
}
nsIFrame* nsCaret::GetPaintGeometry(nsRect* aRect) {
// Return null if we should not be visible.
if (!IsVisible() || !mIsBlinkOn) {
return nullptr;
}
Bug 1048752. Part 22: Factor out SelectionLanguageChange call to run early in nsCaret::GetPaintGeometry. r=tn This code is somewhat tricky. nsCaret::ComputeCaretRects was checking to see if we have a bidi keyboard, and if so, what direction it's set to. If the direction changed from the last direction seen for *this caret*, we fired a SelectionLanguageChange notification on the caret's current Selection. This looked bogus because the caret can be switched between selections so it would seem some selections won't get a notification when they should, but that's how it was. Also, when the SelectionLanguageChange notification fired we then didn't draw the caret in that iteration, which seems even more bogus. This patch fixes all that by moving the logic to fire SelectionLanguageChange out to GetPaintGeometry and firing the notification every single time without trying to detect whether the state has changed or not. I carefully examined the implementation of SelectionLanguageChange and I'm pretty sure it's idempotent so this should be correct. That doesn't look like an expensive function, and runs at most once per window paint, so I'm not worried about perf. Because we now fire SelectionLanguageChange before reading selection or frame state, it should be fine to carry on after calling SelectionLanguageChange and drawing the caret based on whatever changes SelectionLanguageChange has performed. This also lets us remove mKeyboardRTL, which as noted above seems inherently bogus. --HG-- extra : rebase_source : 3ddfd10f6f30033e090e72b4bb43f2695218752e
2014-08-06 05:19:28 +00:00
// Update selection language direction now so the new direction will be
// taken into account when computing the caret position below.
CheckSelectionLanguageChange();
int32_t frameOffset;
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
nsIFrame* unadjustedFrame = nullptr;
nsIFrame* frame =
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
GetFrameAndOffset(GetSelection(), mOverrideContent, mOverrideOffset,
&frameOffset, &unadjustedFrame);
MOZ_ASSERT(!!frame == !!unadjustedFrame);
if (!frame) {
return nullptr;
}
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
// Now we have a frame, check whether it's appropriate to show the caret here.
// Note we need to check the unadjusted frame, otherwise consider the
// following case:
//
// <div contenteditable><span contenteditable=false>Text </span><br>
//
// Where the selection is targeting the <br>. We want to display the caret,
// since the <br> we're focused at is editable, but we do want to paint it at
// the adjusted frame offset, so that we can see the collapsed whitespace.
const nsStyleUI* ui = unadjustedFrame->StyleUI();
if ((!mIgnoreUserModify && ui->mUserModify == StyleUserModify::ReadOnly) ||
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
unadjustedFrame->IsContentDisabled()) {
return nullptr;
}
// If the offset falls outside of the frame, then don't paint the caret.
int32_t startOffset, endOffset;
if (frame->IsTextFrame() &&
(NS_FAILED(frame->GetOffsets(startOffset, endOffset)) ||
startOffset > frameOffset || endOffset < frameOffset)) {
return nullptr;
}
nsRect caretRect;
nsRect hookRect;
ComputeCaretRects(frame, frameOffset, &caretRect, &hookRect);
aRect->UnionRect(caretRect, hookRect);
return frame;
}
nsIFrame* nsCaret::GetFrame(int32_t* aContentOffset) {
return GetFrameAndOffset(GetSelection(), mOverrideContent, mOverrideOffset,
aContentOffset);
}
void nsCaret::PaintCaret(DrawTarget& aDrawTarget, nsIFrame* aForFrame,
const nsPoint& aOffset) {
int32_t contentOffset;
nsIFrame* frame = GetFrame(&contentOffset);
if (!frame) {
return;
}
NS_ASSERTION(frame == aForFrame, "We're referring different frame");
int32_t appUnitsPerDevPixel = frame->PresContext()->AppUnitsPerDevPixel();
nsRect caretRect;
nsRect hookRect;
ComputeCaretRects(frame, contentOffset, &caretRect, &hookRect);
Rect devPxCaretRect = NSRectToSnappedRect(caretRect + aOffset,
appUnitsPerDevPixel, aDrawTarget);
Rect devPxHookRect =
NSRectToSnappedRect(hookRect + aOffset, appUnitsPerDevPixel, aDrawTarget);
ColorPattern color(ToDeviceColor(frame->GetCaretColorAt(contentOffset)));
aDrawTarget.FillRect(devPxCaretRect, color);
if (!hookRect.IsEmpty()) {
aDrawTarget.FillRect(devPxHookRect, color);
}
}
NS_IMETHODIMP
nsCaret::NotifySelectionChanged(Document*, Selection* aDomSel,
int16_t aReason) {
// Note that aDomSel, per the comment below may not be the same as our
// selection, but that's OK since if that is the case, it wouldn't have
// mattered what IsVisible() returns here, so we just opt for checking
// the selection later down below.
if ((aReason & nsISelectionListener::MOUSEUP_REASON) ||
!IsVisible(aDomSel)) // this wont do
return NS_OK;
// The same caret is shared amongst the document and any text widgets it
// may contain. This means that the caret could get notifications from
// multiple selections.
//
// If this notification is for a selection that is not the one the
// the caret is currently interested in (mDomSelectionWeak), then there
// is nothing to do!
if (mDomSelectionWeak != aDomSel) return NS_OK;
ResetBlinking();
SchedulePaint(aDomSel);
return NS_OK;
1999-02-11 23:49:08 +00:00
}
void nsCaret::ResetBlinking() {
mIsBlinkOn = true;
if (mReadOnly || !mVisible || mHideCount) {
StopBlinking();
return;
}
uint32_t blinkRate = static_cast<uint32_t>(LookAndFeel::GetInt(
LookAndFeel::eIntID_CaretBlinkTime, kDefaultCaretBlinkRate));
if (mBlinkRate == blinkRate) {
// If the rate hasn't changed, then there is nothing to do.
return;
}
mBlinkRate = blinkRate;
if (mBlinkTimer) {
mBlinkTimer->Cancel();
} else {
nsIEventTarget* target = nullptr;
if (nsCOMPtr<nsIPresShell> presShell = do_QueryReferent(mPresShell)) {
if (nsCOMPtr<Document> doc = presShell->GetDocument()) {
target = doc->EventTargetFor(TaskCategory::Other);
}
}
mBlinkTimer = NS_NewTimer(target);
if (!mBlinkTimer) {
return;
}
}
if (blinkRate > 0) {
mBlinkCount = Preferences::GetInt("ui.caretBlinkCount", -1);
mBlinkTimer->InitWithNamedFuncCallback(CaretBlinkCallback, this, blinkRate,
nsITimer::TYPE_REPEATING_SLACK,
"nsCaret::CaretBlinkCallback_timer");
}
1999-02-11 23:49:08 +00:00
}
void nsCaret::StopBlinking() {
if (mBlinkTimer) {
mBlinkTimer->Cancel();
mBlinkRate = 0;
}
1999-02-11 23:49:08 +00:00
}
nsresult nsCaret::GetCaretFrameForNodeOffset(
nsFrameSelection* aFrameSelection, nsIContent* aContentNode,
int32_t aOffset, CaretAssociationHint aFrameHint, nsBidiLevel aBidiLevel,
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
nsIFrame** aReturnFrame, nsIFrame** aReturnUnadjustedFrame,
int32_t* aReturnOffset) {
if (!aFrameSelection) return NS_ERROR_FAILURE;
nsIPresShell* presShell = aFrameSelection->GetShell();
if (!presShell) return NS_ERROR_FAILURE;
if (!aContentNode || !aContentNode->IsInComposedDoc() ||
presShell->GetDocument() != aContentNode->GetComposedDoc())
return NS_ERROR_FAILURE;
nsIFrame* theFrame = nullptr;
int32_t theFrameOffset = 0;
theFrame = aFrameSelection->GetFrameForNodeOffset(
aContentNode, aOffset, aFrameHint, &theFrameOffset);
if (!theFrame) return NS_ERROR_FAILURE;
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
if (aReturnUnadjustedFrame) {
*aReturnUnadjustedFrame = theFrame;
}
// if theFrame is after a text frame that's logically at the end of the line
// (e.g. if theFrame is a <br> frame), then put the caret at the end of
// that text frame instead. This way, the caret will be positioned as if
// trailing whitespace was not trimmed.
AdjustCaretFrameForLineEnd(&theFrame, &theFrameOffset);
// Mamdouh : modification of the caret to work at rtl and ltr with Bidi
//
// Direction Style from visibility->mDirection
// ------------------
// NS_STYLE_DIRECTION_LTR : LTR or Default
// NS_STYLE_DIRECTION_RTL
Bug 1506547 - Align user-select behavior more with other UAs. r=mats 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 --HG-- extra : moz-landing-system : lando
2018-11-26 09:21:37 +00:00
if (theFrame->PresContext()->BidiEnabled()) {
// If there has been a reflow, take the caret Bidi level to be the level of
// the current frame
if (aBidiLevel & BIDI_LEVEL_UNDEFINED) {
aBidiLevel = theFrame->GetEmbeddingLevel();
}
int32_t start;
int32_t end;
nsIFrame* frameBefore;
nsIFrame* frameAfter;
nsBidiLevel levelBefore; // Bidi level of the character before the caret
nsBidiLevel levelAfter; // Bidi level of the character after the caret
theFrame->GetOffsets(start, end);
if (start == 0 || end == 0 || start == theFrameOffset ||
end == theFrameOffset) {
nsPrevNextBidiLevels levels =
aFrameSelection->GetPrevNextBidiLevels(aContentNode, aOffset, false);
/* Boundary condition, we need to know the Bidi levels of the characters
* before and after the caret */
if (levels.mFrameBefore || levels.mFrameAfter) {
frameBefore = levels.mFrameBefore;
frameAfter = levels.mFrameAfter;
levelBefore = levels.mLevelBefore;
levelAfter = levels.mLevelAfter;
if ((levelBefore != levelAfter) || (aBidiLevel != levelBefore)) {
aBidiLevel = std::max(aBidiLevel,
std::min(levelBefore, levelAfter)); // rule c3
aBidiLevel = std::min(aBidiLevel,
std::max(levelBefore, levelAfter)); // rule c4
if (aBidiLevel == levelBefore || // rule c1
(aBidiLevel > levelBefore && aBidiLevel < levelAfter &&
IS_SAME_DIRECTION(aBidiLevel, levelBefore)) || // rule c5
(aBidiLevel < levelBefore && aBidiLevel > levelAfter &&
IS_SAME_DIRECTION(aBidiLevel, levelBefore))) // rule c9
{
if (theFrame != frameBefore) {
if (frameBefore) { // if there is a frameBefore, move into it
theFrame = frameBefore;
theFrame->GetOffsets(start, end);
theFrameOffset = end;
} else {
// if there is no frameBefore, we must be at the beginning of
// the line so we stay with the current frame. Exception: when
// the first frame on the line has a different Bidi level from
// the paragraph level, there is no real frame for the caret to
// be in. We have to find the visually first frame on the line.
nsBidiLevel baseLevel = frameAfter->GetBaseLevel();
if (baseLevel != levelAfter) {
nsPeekOffsetStruct pos(eSelectBeginLine, eDirPrevious, 0,
nsPoint(0, 0), false, true, false,
true, false);
if (NS_SUCCEEDED(frameAfter->PeekOffset(&pos))) {
theFrame = pos.mResultFrame;
theFrameOffset = pos.mContentOffset;
}
}
}
}
} else if (aBidiLevel == levelAfter || // rule c2
(aBidiLevel > levelBefore && aBidiLevel < levelAfter &&
IS_SAME_DIRECTION(aBidiLevel, levelAfter)) || // rule c6
(aBidiLevel < levelBefore && aBidiLevel > levelAfter &&
IS_SAME_DIRECTION(aBidiLevel, levelAfter))) // rule c10
{
if (theFrame != frameAfter) {
if (frameAfter) {
// if there is a frameAfter, move into it
theFrame = frameAfter;
theFrame->GetOffsets(start, end);
theFrameOffset = start;
} else {
// if there is no frameAfter, we must be at the end of the line
// so we stay with the current frame.
// Exception: when the last frame on the line has a different
// Bidi level from the paragraph level, there is no real frame
// for the caret to be in. We have to find the visually last
// frame on the line.
nsBidiLevel baseLevel = frameBefore->GetBaseLevel();
if (baseLevel != levelBefore) {
nsPeekOffsetStruct pos(eSelectEndLine, eDirNext, 0,
nsPoint(0, 0), false, true, false,
true, false);
if (NS_SUCCEEDED(frameBefore->PeekOffset(&pos))) {
theFrame = pos.mResultFrame;
theFrameOffset = pos.mContentOffset;
}
}
}
}
} else if (aBidiLevel > levelBefore &&
aBidiLevel < levelAfter && // rule c7/8
// before and after have the same parity
IS_SAME_DIRECTION(levelBefore, levelAfter) &&
// caret has different parity
!IS_SAME_DIRECTION(aBidiLevel, levelAfter)) {
if (NS_SUCCEEDED(aFrameSelection->GetFrameFromLevel(
frameAfter, eDirNext, aBidiLevel, &theFrame))) {
theFrame->GetOffsets(start, end);
levelAfter = theFrame->GetEmbeddingLevel();
if (IS_LEVEL_RTL(aBidiLevel)) // c8: caret to the right of the
// rightmost character
theFrameOffset = IS_LEVEL_RTL(levelAfter) ? start : end;
else // c7: caret to the left of the leftmost character
theFrameOffset = IS_LEVEL_RTL(levelAfter) ? end : start;
}
} else if (aBidiLevel < levelBefore &&
aBidiLevel > levelAfter && // rule c11/12
// before and after have the same parity
IS_SAME_DIRECTION(levelBefore, levelAfter) &&
// caret has different parity
!IS_SAME_DIRECTION(aBidiLevel, levelAfter)) {
if (NS_SUCCEEDED(aFrameSelection->GetFrameFromLevel(
frameBefore, eDirPrevious, aBidiLevel, &theFrame))) {
theFrame->GetOffsets(start, end);
levelBefore = theFrame->GetEmbeddingLevel();
if (IS_LEVEL_RTL(aBidiLevel)) // c12: caret to the left of the
// leftmost character
theFrameOffset = IS_LEVEL_RTL(levelBefore) ? end : start;
else // c11: caret to the right of the rightmost character
theFrameOffset = IS_LEVEL_RTL(levelBefore) ? start : end;
}
}
}
}
}
}
*aReturnFrame = theFrame;
*aReturnOffset = theFrameOffset;
return NS_OK;
1999-02-11 23:49:08 +00:00
}
size_t nsCaret::SizeOfIncludingThis(mozilla::MallocSizeOf aMallocSizeOf) const {
size_t total = aMallocSizeOf(this);
if (mPresShell) {
// We only want the size of the nsWeakReference object, not the PresShell
// (since we don't own the PresShell).
total += mPresShell->SizeOfOnlyThis(aMallocSizeOf);
}
if (mBlinkTimer) {
total += mBlinkTimer->SizeOfIncludingThis(aMallocSizeOf);
}
return total;
}
bool nsCaret::IsMenuPopupHidingCaret() {
#ifdef MOZ_XUL
// Check if there are open popups.
nsXULPopupManager* popMgr = nsXULPopupManager::GetInstance();
nsTArray<nsIFrame*> popups;
popMgr->GetVisiblePopups(popups);
if (popups.Length() == 0)
return false; // No popups, so caret can't be hidden by them.
// Get the selection focus content, that's where the caret would
// go if it was drawn.
if (!mDomSelectionWeak) {
return true; // No selection/caret to draw.
}
nsCOMPtr<nsIContent> caretContent =
nsIContent::FromNodeOrNull(mDomSelectionWeak->GetFocusNode());
if (!caretContent) return true; // No selection/caret to draw.
// If there's a menu popup open before the popup with
// the caret, don't show the caret.
for (uint32_t i = 0; i < popups.Length(); i++) {
nsMenuPopupFrame* popupFrame = static_cast<nsMenuPopupFrame*>(popups[i]);
nsIContent* popupContent = popupFrame->GetContent();
if (nsContentUtils::ContentIsDescendantOf(caretContent, popupContent)) {
// The caret is in this popup. There were no menu popups before this
// popup, so don't hide the caret.
return false;
}
if (popupFrame->PopupType() == ePopupTypeMenu &&
!popupFrame->IsContextMenu()) {
// This is an open menu popup. It does not contain the caret (else we'd
// have returned above). Even if the caret is in a subsequent popup,
// or another document/frame, it should be hidden.
return true;
}
}
#endif
// There are no open menu popups, no need to hide the caret.
return false;
}
1999-09-14 23:41:19 +00:00
void nsCaret::ComputeCaretRects(nsIFrame* aFrame, int32_t aFrameOffset,
nsRect* aCaretRect, nsRect* aHookRect) {
NS_ASSERTION(aFrame, "Should have a frame here");
WritingMode wm = aFrame->GetWritingMode();
bool isVertical = wm.IsVertical();
nscoord bidiIndicatorSize;
*aCaretRect = GetGeometryForFrame(aFrame, aFrameOffset, &bidiIndicatorSize);
// on RTL frames the right edge of mCaretRect must be equal to framePos
const nsStyleVisibility* vis = aFrame->StyleVisibility();
if (NS_STYLE_DIRECTION_RTL == vis->mDirection) {
if (isVertical) {
aCaretRect->y -= aCaretRect->height;
} else {
aCaretRect->x -= aCaretRect->width;
}
}
// Simon -- make a hook to draw to the left or right of the caret to show
// keyboard language direction
aHookRect->SetEmpty();
if (!IsBidiUI()) {
return;
}
bool isCaretRTL;
nsIBidiKeyboard* bidiKeyboard = nsContentUtils::GetBidiKeyboard();
// if bidiKeyboard->IsLangRTL() fails, there is no way to tell the
// keyboard direction, or the user has no right-to-left keyboard
// installed, so we never draw the hook.
if (bidiKeyboard && NS_SUCCEEDED(bidiKeyboard->IsLangRTL(&isCaretRTL))) {
// If keyboard language is RTL, draw the hook on the left; if LTR, to the
// right The height of the hook rectangle is the same as the width of the
// caret rectangle.
if (isVertical) {
bool isSidewaysLR = wm.IsVerticalLR() && !wm.IsLineInverted();
if (isSidewaysLR) {
aHookRect->SetRect(aCaretRect->x + bidiIndicatorSize,
aCaretRect->y + (!isCaretRTL ? bidiIndicatorSize * -1
: aCaretRect->height),
aCaretRect->height, bidiIndicatorSize);
} else {
aHookRect->SetRect(aCaretRect->XMost() - bidiIndicatorSize,
aCaretRect->y + (isCaretRTL ? bidiIndicatorSize * -1
: aCaretRect->height),
aCaretRect->height, bidiIndicatorSize);
}
} else {
aHookRect->SetRect(aCaretRect->x + (isCaretRTL ? bidiIndicatorSize * -1
: aCaretRect->width),
aCaretRect->y + bidiIndicatorSize, bidiIndicatorSize,
aCaretRect->width);
}
}
}
1999-02-11 23:49:08 +00:00
/* static */
void nsCaret::CaretBlinkCallback(nsITimer* aTimer, void* aClosure) {
nsCaret* theCaret = reinterpret_cast<nsCaret*>(aClosure);
if (!theCaret) {
return;
}
theCaret->mIsBlinkOn = !theCaret->mIsBlinkOn;
theCaret->SchedulePaint();
// mBlinkCount of -1 means blink count is not enabled.
if (theCaret->mBlinkCount == -1) {
return;
}
// Track the blink count, but only at end of a blink cycle.
if (!theCaret->mIsBlinkOn) {
// If we exceeded the blink count, stop the timer.
if (--theCaret->mBlinkCount <= 0) {
theCaret->StopBlinking();
}
}
1999-02-11 23:49:08 +00:00
}
void nsCaret::SetIgnoreUserModify(bool aIgnoreUserModify) {
mIgnoreUserModify = aIgnoreUserModify;
SchedulePaint();
}