gecko-dev/layout/base/nsCaret.h

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

284 строки
9.5 KiB
C
Исходник Обычный вид История

/* -*- 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 15:12:37 +04: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-12 02:49:08 +03:00
/* the caret is the text cursor used, e.g., when editing */
1999-02-12 02:49:08 +03:00
#ifndef nsCaret_h__
#define nsCaret_h__
#include "mozilla/MemoryReporting.h"
#include "mozilla/dom/Selection.h"
1999-02-12 02:49:08 +03:00
#include "nsCoord.h"
#include "nsISelectionListener.h"
#include "nsIWeakReferenceUtils.h"
#include "CaretAssociationHint.h"
#include "nsPoint.h"
#include "nsRect.h"
1999-02-12 02:49:08 +03:00
class nsFrameSelection;
class nsIContent;
class nsIFrame;
class nsINode;
class nsITimer;
namespace mozilla {
class PresShell;
namespace gfx {
class DrawTarget;
} // namespace gfx
} // namespace mozilla
1999-02-12 02:49:08 +03:00
//-----------------------------------------------------------------------------
class nsCaret final : public nsISelectionListener {
typedef mozilla::gfx::DrawTarget DrawTarget;
public:
nsCaret();
protected:
virtual ~nsCaret();
public:
NS_DECL_ISUPPORTS
typedef mozilla::CaretAssociationHint CaretAssociationHint;
nsresult Init(mozilla::PresShell* aPresShell);
void Terminate();
void SetSelection(mozilla::dom::Selection* aDOMSel);
mozilla::dom::Selection* GetSelection();
/**
* Sets whether the caret should only be visible in nodes that are not
* user-modify: read-only, or whether it should be visible in all nodes.
*
* @param aIgnoreUserModify true to have the cursor visible in all nodes,
* false to have it visible in all nodes except
* those with user-modify: read-only
*/
void SetIgnoreUserModify(bool aIgnoreUserModify);
/** SetVisible will set the visibility of the caret
* @param inMakeVisible true to show the caret, false to hide it
*/
void SetVisible(bool intMakeVisible);
/** IsVisible will get the visibility of the caret.
* This returns false if the caret is hidden because it was set
* to not be visible, or because the selection is not collapsed, or
* because an open popup is hiding the caret.
* It does not take account of blinking or the caret being hidden
* because we're in non-editable/disabled content.
*/
bool IsVisible(mozilla::dom::Selection* aSelection = nullptr) {
if (!mVisible || mHideCount) {
return false;
}
if (!mShowDuringSelection) {
mozilla::dom::Selection* selection;
if (aSelection) {
selection = aSelection;
} else {
selection = GetSelection();
}
if (!selection || !selection->IsCollapsed()) {
return false;
}
}
if (IsMenuPopupHidingCaret()) {
return false;
}
return true;
}
/**
* AddForceHide() increases mHideCount and hide the caret even if
* SetVisible(true) has been or will be called. This is useful when the
* caller wants to hide caret temporarily and it needs to cancel later.
* Especially, in the latter case, it's too difficult to decide if the
* caret should be actually visible or not because caret visible state
* is set from a lot of event handlers. So, it's very stateful.
*/
void AddForceHide();
/**
* RemoveForceHide() decreases mHideCount if it's over 0.
* If the value becomes 0, this may show the caret if SetVisible(true)
* has been called.
*/
void RemoveForceHide();
/** SetCaretReadOnly set the appearance of the caret
* @param inMakeReadonly true to show the caret in a 'read only' state,
* false to show the caret in normal, editing state
*/
void SetCaretReadOnly(bool inMakeReadonly);
/**
* @param aVisibility true if the caret should be visible even when the
* selection is not collapsed.
*/
void SetVisibilityDuringSelection(bool aVisibility);
/**
* Set the caret's position explicitly to the specified node and offset
* instead of tracking its selection.
* Passing null for aNode would set the caret to track its selection again.
**/
void SetCaretPosition(nsINode* aNode, int32_t aOffset);
/**
* Schedule a repaint for the frame where the caret would appear.
* Does not check visibility etc.
*/
void SchedulePaint(mozilla::dom::Selection* aSelection = nullptr);
/**
* Returns a frame to paint in, and the bounds of the painted caret
* relative to that frame.
* The rectangle includes bidi decorations.
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 12:21:37 +03:00
* Returns null if the caret should not be drawn (including if it's blinked
* off).
*/
nsIFrame* GetPaintGeometry(nsRect* aRect);
/**
* A simple wrapper around GetGeometry. Does not take any caret state into
* account other than the current selection.
*/
nsIFrame* GetGeometry(nsRect* aRect) {
return GetGeometry(GetSelection(), aRect);
}
/** PaintCaret
* Actually paint the caret onto the given rendering context.
*/
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 12:21:37 +03:00
void PaintCaret(DrawTarget& aDrawTarget, nsIFrame* aForFrame,
const nsPoint& aOffset);
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 12:21:37 +03:00
// nsISelectionListener interface
NS_DECL_NSISELECTIONLISTENER
/**
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 12:21:37 +03:00
* Gets the position and size of the caret that would be drawn for
* the focus node/offset of aSelection (assuming it would be drawn,
* i.e., disregarding blink status). The geometry is stored in aRect,
* and we return the frame aRect is relative to.
* Only looks at the focus node of aSelection, so you can call it even if
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 12:21:37 +03:00
* aSelection is not collapsed.
* This rect does not include any extra decorations for bidi.
* @param aRect must be non-null
*/
static nsIFrame* GetGeometry(const mozilla::dom::Selection* aSelection,
nsRect* aRect);
static nsIFrame* GetCaretFrameForNodeOffset(
nsFrameSelection* aFrameSelection, nsIContent* aContentNode,
int32_t aOffset, CaretAssociationHint aFrameHint, uint8_t aBidiLevel,
nsIFrame** aReturnUnadjustedFrame, int32_t* aReturnOffset);
static nsRect GetGeometryForFrame(nsIFrame* aFrame, int32_t aFrameOffset,
nscoord* aBidiIndicatorSize);
// Get the frame and frame offset based on the focus node and focus offset
// of aSelection. If aOverrideNode and aOverride are provided, use them
// instead.
// @param aFrameOffset return the frame offset if non-null.
// @param aUnadjustedFrame return the original frame that the selection is
// targeting, without any adjustment for painting.
// @return the frame of the focus node.
static nsIFrame* GetFrameAndOffset(const mozilla::dom::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 12:21:37 +03:00
int32_t* aFrameOffset,
nsIFrame** aUnadjustedFrame = nullptr);
size_t SizeOfIncludingThis(mozilla::MallocSizeOf aMallocSizeOf) const;
nsIFrame* GetFrame(int32_t* aContentOffset);
void ComputeCaretRects(nsIFrame* aFrame, int32_t aFrameOffset,
nsRect* aCaretRect, nsRect* aHookRect);
protected:
static void CaretBlinkCallback(nsITimer* aTimer, void* aClosure);
void CheckSelectionLanguageChange();
void ResetBlinking();
void StopBlinking();
struct Metrics {
nscoord mBidiIndicatorSize; // width and height of bidi indicator
nscoord mCaretWidth; // full caret width including bidi indicator
};
static Metrics ComputeMetrics(nsIFrame* aFrame, int32_t aOffset,
nscoord aCaretHeight);
// Returns true if we should not draw the caret because of XUL menu popups.
// The caret should be hidden if:
// 1. An open popup contains the caret, but a menu popup exists before the
// caret-owning popup in the popup list (i.e. a menu is in front of the
// popup with the caret). If the menu itself contains the caret we don't
// hide it.
// 2. A menu popup is open, but there is no caret present in any popup.
// 3. The caret selection is empty.
bool IsMenuPopupHidingCaret();
nsWeakPtr mPresShell;
mozilla::WeakPtr<mozilla::dom::Selection> mDomSelectionWeak;
nsCOMPtr<nsITimer> mBlinkTimer;
/**
* The content to draw the caret at. If null, we use mDomSelectionWeak's
* focus node instead.
*/
nsCOMPtr<nsINode> mOverrideContent;
/**
* The character offset to draw the caret at.
* Ignored if mOverrideContent is null.
*/
int32_t mOverrideOffset;
/**
* mBlinkCount is used to control the number of times to blink the caret
* before stopping the blink. This is reset each time we reset the
* blinking.
*/
int32_t mBlinkCount;
/**
* mBlinkRate is the rate of the caret blinking the last time we read it.
* It is used as a way to optimize whether we need to reset the blinking
* timer.
*/
uint32_t mBlinkRate;
/**
* mHideCount is not 0, it means that somebody doesn't want the caret
* to be visible. See AddForceHide() and RemoveForceHide().
*/
uint32_t mHideCount;
/**
* mIsBlinkOn is true when we're in a blink cycle where the caret is on.
*/
bool mIsBlinkOn;
/**
* mIsVisible is true when SetVisible was last called with 'true'.
*/
bool mVisible;
/**
* mReadOnly is true when the caret is set to "read only" mode (i.e.,
* it doesn't blink).
*/
bool mReadOnly;
/**
* mShowDuringSelection is true when the caret should be shown even when
* the selection is not collapsed.
*/
bool mShowDuringSelection;
/**
* mIgnoreUserModify is true when the caret should be shown even when
* it's in non-user-modifiable content.
*/
bool mIgnoreUserModify;
1999-02-12 02:49:08 +03:00
};
#endif // nsCaret_h__