Граф коммитов

35 Коммитов

Автор SHA1 Сообщение Дата
Masayuki Nakano 2a450c5196 Bug 1444847 - part 2: Sort out basic API of `nsRange` for consistency with coming `StaticRange` r=smaug
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd.  This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.

Differential Revision: https://phabricator.services.mozilla.com/D35141

--HG--
extra : moz-landing-system : lando
2019-06-28 07:47:29 +00:00
Masayuki Nakano 761f01d612 Bug 1533913 - Make HTMLEditRules::ApplyBlockStyle() stop handling it if target node is moved from expected container unexpectedly r=m_kato
`HTMLEditRules::ApplyBlockStyle()` stores `curBlock` and `newBlock` during its
loop to keep handling from deeper child to ancestor, and may do two things for
a `curNode`.  If `curBlock` and/or `newBlock` is moved from expected container
when it sets one of or both of them, this patch check whether mutation event
listeners change the DOM tree.  Additionally, this patch also checks whether
`curNode' is moved by mutation event listener at first step of two jobs for it.

Differential Revision: https://phabricator.services.mozilla.com/D32689

--HG--
extra : moz-landing-system : lando
2019-05-29 04:44:23 +00:00
Masayuki Nakano 33d3bc7789 Bug 1547898 - part 1: The constructor of EditorDOMPointBase which takes all information should allow non-end point of text node r=m_kato
This is a simple mistake of `MOZ_ASSERTION()` in it. When `mParent` is a node
which can have children, `mChild` should be non-`nullptr` or `mOffset` should
/ be set to the end of `mParent`.  But when `mParent` is not a container, any
`mOffset` value should be allowed.

Differential Revision: https://phabricator.services.mozilla.com/D30014

--HG--
extra : moz-landing-system : lando
2019-05-07 07:44:04 +00:00
Sylvestre Ledru 265e672179 Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset

--HG--
extra : amend_source : 4d301d3b0b8711c4692392aa76088ba7fd7d1022
2018-11-30 11:46:48 +01:00
Masayuki Nakano 9f7af9d8fc Bug 1504910 - part 1: Clean up methods which are called by TextEditor::OnDrop() r=m_kato
TextEditor::OnDrop() calls TextEditor::InsertFromDataTransfer() or
HTMLEditor::InsertFromDataTransfer() and they are called only by
TextEditor::OnDrop().

TextEditor::InsertFromDataTransfer() calls only TextEditor::InsertTextAt()
and TextEditor::InsertTextAt() calls only TextEditor::InsertTextAsSubAction() if
insertion point is nullptr.  Therefore, if the callers sets nullptr, they
should call TextEditor::InsertTextAsSubAction() directly.  Then, we can
make TextEditor::InsertTextAt() require non-nullptr insertion point.

HTMLEditor::InsertFromDataTransfer() calls HTMLEditor::InsertObject(),
HTMLEditor::DoInsertHTMLWithContext() or TextEditor::InsertTextAt().

HTMLEditor::InsertObject() calls HTMLEditor::DoInsertHTMLWithContext()
directly or via BlobReader (in this case, calls asynchronously).

Unfortunately both HTMLEditor::InsertObject() and
HTMLEditor::DoInsertHTMLWithContext() are called by
HTMLEditor::InsertFromTransferable() which is paste event handler.  Therefore,
we cannot make them require non-nullptr insertion point, though, anyway,
they cannot become simpler even if we could do that.

This patch marks them as MOZ_CAN_RUN_SCRIPT as far as possible and
makes them take |const EditorDOMPoint&| for insertion point.

Differential Revision: https://phabricator.services.mozilla.com/D11283

--HG--
extra : moz-landing-system : lando
2018-11-09 08:40:57 +00:00
Emilio Cobos Álvarez fe09ffd3af Bug 1465478: Introduce Element::FromNode. r=smaug
And use it in a couple places I noticed.

MozReview-Commit-ID: 8baSMrbdEbF
2018-05-31 02:46:10 +02:00
Boris Zbarsky c73f664888 Bug 1463981 part 3. Remove nsIDOMNode usage in editor. r=masayuki 2018-05-24 13:18:34 -04:00
Masayuki Nakano 94dd5a92a4 Bug 1454126 - HTMLEditor should adjust selection outside native anonymous subtree when it inserts something at selection r=m_kato
HTMLEditor::InsertElementAtSelection() doesn't check if selection is in
native anonymous subtree.  Therefore, it could insert element into <input>
element etc.

This patch adds new API to EditorDOMPointBase to compute ancestor point which
is not in native-anonymous subtree and make
HTMLEditor::GetBetterInsertionPointFor() use it to not return point in any
native-anonymous subtrees.
2018-04-17 17:01:57 +09:00
Emilio Cobos Álvarez 45787fc53f Bug 1454241: Remove nsINode::eDATA_NODE. r=bz
MozReview-Commit-ID: 6HQDAwiGgIo
2018-04-20 03:58:00 +02:00
Andrew McCreight 3f7472aec1 Bug 1449670, part 1 - Convert IsNodeOfType(nsINode::eTEXT) to IsText(). r=bz
This method is not a virtual call, and also looks nicer.

This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.

MozReview-Commit-ID: 8JExxqSRc59

--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
2018-04-12 15:41:00 -07:00
Masayuki Nakano 537b829474 Bug 1447213 - Change editor methods which take |const EditorRawDOMPoint&| but called with EditorDOMPoint.AsRaw() to template methods r=m_kato
A lot of methods take |const EditorRawDOMPoint&| as their argument.  However,
some of them are called with EditorDOMPoint::AsRaw(). This is not good for
performance because:
1. Needs to create temporary instance of EditorRawDOMPoint.
2. EditorRawDOMPoint::AsRaw() may be used by simple mistake.
3. Such methods may call EditorRawDOMPoint::Offset(), however, it's not copied
   to the original EditorDOMPoint instance.  So, callers may need to compute
   offset again.

So, such methods should be changed to template methods if they are not virtual
method and AsRaw() should be gotten rid of for prevent it looking not expensive.

MozReview-Commit-ID: DAqqW4a2EMS

--HG--
extra : rebase_source : 120b920477fe6e7231271411a00994325acdb842
2018-03-20 14:05:47 +09:00
Masayuki Nakano f3c761c198 Bug 1445929 - Make Editor(Raw)DOMPoint::IsEndOfContainer() check if mParent is container node before checking mChild r=m_kato
Editor(Raw)DOMPoint::IsEndOfContainer() checks mIsChildInitialized before
referring mChild.  However, it may be true even if mParent is not a container
node like a text node.  Therefore, if mParent is a text node and
mIsChildInitialized is true, it always returns true (i.e., even if mOffset
isn't same as length of mParent).

This patch makes it check mParent->IsContainerNode() before checking
mIsChildInitialized because after checking mIsChildInitialized, it validates
the relation of the members.  So, this keeps the validation simple.

MozReview-Commit-ID: K2XrAZoNv2I

--HG--
extra : rebase_source : cba8190f199ab2e9d99547948ab50f0cc8c8ff88
2018-03-15 22:08:19 +09:00
Masayuki Nakano c548fd9ae1 Bug 1436663 - EditorBase::JoinNodeDeep() should set result after actually joining the nodes r=m_kato
EditorBase::JoinNodeDeep() returns a DOM point which was start of right node.
Currently, this is set before actually joining the nodes.  Therefore, we see
warnings since right node which becomes joined node may have less children
than left node.

This patch also makes the NS_WARNING_ASSERTION to NS_ASSERTION since no tests
hit this.  So, we can use it to detect regressions.

MozReview-Commit-ID: 3RmRP588AkF

--HG--
extra : rebase_source : 2cab458ffac566c81eb8d3f47e755ffacb1553d2
2018-02-08 16:17:24 +09:00
Masayuki Nakano 1165b53e10 Bug 1436295 - HTMLEditRules::WillInsertBreak() should cancel resetting EditorDOMPoint when HTMLEditRules::ReturnInParagraph() splits DOM node around the point r=m_kato
This patch only fixes warning, not changing actual behavior of editor.

HTMLEditRules::ReturnInParagraph() splits paragraph *around* given point.
Therefore, from point of view of caller, offset of setting point may be
invalid after HTMLEditRules::ReturnInParagraph() handled the edit action.
In this case, invalidating stored child of the point may cause warning
since offset may be larger than length of its container.

So, if HTMLEditRules::ReturnInParagraph() handles the edit action,
the caller, HTMLEditRules::WillInsertBreak(), should cancel invalidating
the stored child for avoiding unnecessary warning.

MozReview-Commit-ID: DKJlr0Awwlo

--HG--
extra : rebase_source : 8fbefff3b46e55daf8db6342f00de904315d7fcc
2018-02-07 19:04:52 +09:00
Masayuki Nakano 283dfdf558 Bug 1434969 - EditorDOMPointBase::RewindOffset() shouldn't treat it as error if offset is same as length of the container r=m_kato
EditorDOMPointBase::RewindOffset() treats it as error when offset is
same as length of container.  However, this is wrong because offset can
be same as length of its container since it means after the last child
or last character.  So, if an instance points end of a container node,
Rewind() always fails unexpectedly.

MozReview-Commit-ID: A9bvsxETDoo

--HG--
extra : rebase_source : f05994f2924adaa29711da3916f431688eaa79b7
2018-02-04 01:00:44 +09:00
Masayuki Nakano dc245c4fee Bug 1422234 - part 1: HTMLEditRules::ReturnInParagraph() should adjust split point if caret position is positioned at edge of anchor element r=m_kato
When Enter key is pressed at start or end of <a href="foo"> element, we
shouldn't split it (in other words, we shouldn't create empty <a href="foo">
element in new paragraph) because users must not want to keep editing *same*
link in new paragraph in most cases.

This patch adjusts HTMLEditRules::ReturnInParagraph() selection start point
locally when it gets selection.  If caret is at start of an <a href="foo">
element, moves caret to before the element.  If caret is at end of an
<a href="foo"> element, moves to after the element.

MozReview-Commit-ID: 3L3eDzc6Dk

--HG--
extra : rebase_source : dfb22486d2709e84ef7ec1eee3a9bfdef11cbe99
2018-01-23 11:14:37 +09:00
Andrea Marchesini b8bb98af8c Bug 1430997 - Rename nsINode::IndexOf to nsINode::ComputeIndexOf, r=catalinb 2018-01-23 14:30:18 +01:00
Andrea Marchesini 00e79ef07b Bug 1425321 - Renaming nsINode::GetChildAt to GetChildAt_Deprecated, r=catalinb
We want to deprecate nsINode::GetChildAt as the first step of removing DOM node
child array storage. See bug 651120.
2018-01-03 13:59:54 +01:00
Masayuki Nakano 6b577ea0fa Bug 1423835 - part 3: Rename EditorDOMPointBase::GetChildAtOffset() to EditorDOMPointBase::GetChild() r=m_kato
Different from RangeBoundaryBase, EditorDOMPointBase can store only child node.
I.e., mOffset may be invalid until its Offset() is called.  So,
GetChildAtOffset() isn't good name.  It should be just GetChild().

Similarly, GetNextSiblingOfChildAtOffset() and
GetPreviousSiblingOfChildAtOffset() should be renamed to GetNextSiblingOfChild()
and GetPreviousSiblingOfChild().

MozReview-Commit-ID: WpkPmDwkrL

--HG--
extra : rebase_source : 2be1fcbee129f4c96e9b166be5a924845340708f
2017-12-07 19:08:56 +09:00
Masayuki Nakano dacd109e2f Bug 1423835 - part 2: Rename EditorDOMPointBase::Container() to EditorDOMPointBase::GetContainer() and add some useful methods to access its container r=m_kato
EditorDOMPointBase::Container() may return nullptr.  So, it should be renamed
to GetContainer().

Then, the method name becomes longer and a lot of callers access the result
directly.  So, there should be following methods to make the callers shorter:

- GetContainerAsContent() to return the container as nsIContent*.
- GetContainerAsElement() to return the container as dom::Element*.
- GetContainerAsText() to return the container as dom::Text.
- GetContainerAsDOMNode() to return the container as nsIDOMNode*.
- CanContainerHaveChildren() to check if the container can have child nodes.
- IsInDataNode() to check if the point is in a data node including text node.
- IsInTextNode() to check if the point is in a text node.
- IsContainerHTMLElement() to check if the container is specific HTML element.
- IsContainerAnyOfHTMLElements() to check if the container is one of the
  specified HTML elements.

MozReview-Commit-ID: LkN2WBbCPj0

--HG--
extra : rebase_source : 9da1e70d4c74f7ad573e244cf6c7b21a0c7b4410
2017-12-07 18:45:52 +09:00
Masayuki Nakano d95c27869d Bug 1423835 - part 1: Add EditorDOMPointBase::SetToEndOf() to initialize the instance at end of container node r=m_kato
Editor code sometimes sets a DOM point to end of a node.  In this case, we
need to write |Set(node, node->Length())|.  So, it should have
|void SetToEndOf(const nsINode* aContainer)| for making meaning of the code
clearer.

MozReview-Commit-ID: 91shMCD2d84

--HG--
extra : rebase_source : 3401af50aabc1b677deeae664e8c56506182d28c
2017-12-07 17:27:20 +09:00
Masayuki Nakano d942210f2e Bug 1408125 - part 5: Redesign HTMLEditor::NormalizeEOLInsertPosition() with EditorRawDOMPoint r=m_kato
HTMLEditor::NormalizeEOLInsertPosition() takes a set of container node and
offset in it for specifying insertion point.  So, this should be replaced
with |const EditorRawDOMPoint&| and it should return |EditorDOMPoint| rather
than modifying the argument.

Additionally, perhaps, GetBetterInsertionPointFor() is better name for it.

MozReview-Commit-ID: IB1FhrkzK2G

--HG--
extra : rebase_source : 55f8c1d9fa1f149e81114c929f6e6232aba03905
2017-12-05 15:36:49 +09:00
Masayuki Nakano 36d48397f0 Bug 1408125 - part 4: Redesign HTMLEditor::InsertNodeAtPoint() with EditorRawDOMPoint r=m_kato
HTMLEditor::InsertNodeAtPoint() should take |const EditorRawDOMPoint&| as
an argument which specifies point to insert.  Additionally, it should take
|EditorDOMPoint*| to return the next point of actual insertion point.

Additionally, this patch renames it to InsertNodeAtProperAncestor() for
explaining what it will do.

MozReview-Commit-ID: HYUzSlyPxAd

--HG--
extra : rebase_source : 57033cdc4458b45a5fe9d6aa642c185133a79304
2017-11-28 22:28:07 +09:00
Masayuki Nakano 0b2f749b62 Bug 1422668 - Back out changes of RangeBoundary.h which were added for EditorDOMPoint r=catalinb
EditorDOMPoint was a subclass of RangeBoundary.  Therefore, for heavy
use of it in editor, we've implemented a lot of complicated feature
into RangeBoundary.  However, EditorDOMPoint stopped inheriting
RangeBoundary.  So, we can get simple RangeBoundary implementation
back now.

This patch makes RangeBoundary.h almost same as 3f7cbec2446b except
keeps implementing GetPreviousSiblingOfChildAtOffset() and
GetNextSiblingOfChildAtOffset() because the former is used by
Selection and both of them are simple.  And also keeps making it
a friend of EditorDOMPoint because EditorDOMPoint still needs to
copy to/from RangeBoundary.

MozReview-Commit-ID: Hr5SA52ScK0

--HG--
extra : rebase_source : a00a46ff931a5c4fcabf910510fa448b513f50c5
2017-12-04 16:28:50 +09:00
Masayuki Nakano 5c35d9705d Bug 1421504 - EditorBase should move children carefully r=m_kato
While moving children of a container to another container, mutation observer
may move children before moving and/or move node immediately after the
insertion point.  Therefore, EditorBase should store all children which
should be moved with a local variable.  Then, move one by one carefully.
E.g., if a child before being moved is moved to different container, it
shouldn't be moved because JS already handles it as expected for the web
app.  If next sibling of the insertion point has been moved, EditorBase
should stop moving the remaining children because it may move children to
odd position and it may cause dataloss.

This patch creates EditorBase::MoveChildren() and it moves children carefully
with above checks.  Additionally, making its callers simpler, this patch also
creates EditorBase::MovePreviousSiblings() and MoveAllChildren().

MozReview-Commit-ID: FJDdSqXIlqD

--HG--
extra : rebase_source : 54bded29dbbd9547339a2c6e1a1264e22fbdc740
2017-11-29 17:57:00 +09:00
Masayuki Nakano 09957e4f47 Bug 1421877 - Fix some warnings which hit (almost) always in EditorDOMPointBase r=m_kato
There are 3 spam warning assertion in EditorDOMPointBase.

One is in constructor. Which warns if IsSet() returns false, but it checks
before finishing initializing.

The others are in IsStartOfContainer() and IsEndOfContainer().  They try to
check if mOffset is valid value with current DOM tree if it's initialized
when it's at start or end of the container.  However, they do it even when
it's not start nor end of the container.

This patch fixes those spammers.

MozReview-Commit-ID: DvFa501m9V0

--HG--
extra : rebase_source : c97ac371054a54eabc07b3ec726b924d6be61e25
2017-11-30 13:21:12 +09:00
Masayuki Nakano f989a6c4d5 Bug 1419745 - part 3: CreateElementTransaction and SplitNodeTransaction should store DOM point with EditorDOMPoint rather than RangeBoundary r=m_kato
CreateElementTransaction and SplitNodeTransaction store DOM point with
RangeBoundary now.  However, it refers next child of referring point.
Therefore, if it's moved to different container or removed from the DOM
tree, they cannot do undo/redo.  We can say for the child node, however,
it doesn't make sense depending on a node which is not directly referring.

MozReview-Commit-ID: Baohbub3RNZ

--HG--
extra : rebase_source : 6776420271cdaf91aae6213fb6e1bcf1841112b1
2017-11-28 17:13:15 +09:00
Masayuki Nakano 83d8db0fdc Bug 1419745 - part 2: Make EditorDOMPointBase store child node at offset instead of previous sibling of child node at offset r=m_kato
EditorDOMPointBase should store child node at offset directly rather than
previous sibling of child node at offset because if referring child node or
its previous sibling is moved to different DOM point,
EditorDOMPointBase::GetChildAtOffset() may return different node.  However,
users of this class assumes that after it stores child node at offset, it'll
return same node.

So, EditorDOMPointBase should store child node instead of "ref".  Additionally,
when it stores nullptr as the child, it should set mOffset to length of the
mContainer because it means it refers after the last child.

MozReview-Commit-ID: 7ZdkwKLJEjo

--HG--
extra : rebase_source : c2a0a1be1285466e5fa96162779e86c37ae78655
2017-11-23 04:09:00 +09:00
Masayuki Nakano 1bb0ec153d Bug 1419745 - part 1: Make EditorDOMPointBase not a sub class of RangeBoundaryBase and duplicate methods of RangeBoundaryBase into EditorDOMPointBase r=m_kato
EditorDOMPointBase should store child at offset for editor uses.  E.g., when
editor wants to refer a node as child node of an EditorDOMPoint instance,
even if the node is unexpectedly moved to different container, editor wants
to keep referring the child node rather than its previous sibling.

Therefore this patch makes EditorDOMPointBase not a sub class of
RangeBoundaryBase but copying all methods and members of RangeBoundaryBase
into EditorDOMPointBase for keeping current behavior completely.

MozReview-Commit-ID: LIyPFkCfsZ9

--HG--
extra : rebase_source : fd76c4808625f8f8a86f7b4e4c1ac22fbdc11dd5
2017-11-23 00:15:29 +09:00
Masayuki Nakano 02038d75da Bug 1413181 - part 11: Create AutoEditorDOMPointOffsetInvalidator stack class for automatically invalidate offset of EditorDOMPoint r=m_kato
In the following patch, we need to invalidate offset a lot of places after
splitting nodes.  Therefore, there should be a helper stack class before that.

MozReview-Commit-ID: BgijAU7OizU

--HG--
extra : rebase_source : 520f29dacdffe5f7137ba7f11b289241b5fbface
2017-11-17 17:00:56 +09:00
Masayuki Nakano a9b50a718e Bug 1416099 - part 6: Make HTMLEditRules::WillInsertBreak() use EditorDOMPoint to store selection start r=m_kato
The only caller of HTMLEditRules::ReturnInParagraph() is
HTMLEditRules::WillInsertBreak().  It should use EditorDOMPoint for storing
selection start.

Then, this patch makes what is set to ReturnInParagraph() clear.  So, the
point ReturnInParagraph() is always start of selection.

MozReview-Commit-ID: 6X0P5gpwXKr

--HG--
extra : rebase_source : d1814e5b7c8e4005886607691b37fe6a83e8e5be
2017-11-10 16:10:06 +09:00
Masayuki Nakano a3fa902a2d Bug 1415509 - part 2: EditorBase::InsertTextImpl() should take |const EditorRawDOMPoint&| argument as input and |EditorRawDOMPoint*| as out argument instead of a set of container, child and offset of the child in the container as in/out argument r=m_kato
EditorBase::InsertTextImpl() takes |nsCOMPtr<nsINode>*|, |nsCOMPtr<nsIContent>*|
and |int32_t| as in/out arguments for container, child and offset of the child
in the container.  But this makes the callers really hard to read and ugly.

So, we should make the method take |const EditorRawDOMPoint&| argument as input
and |EditorRawDOMPoint*| as out argument.

MozReview-Commit-ID: 2ijIfGl4Zo7

--HG--
extra : rebase_source : b309d9bdc04aac620f138769ba18ad7e4597fe6c
2017-11-09 01:00:36 +09:00
Masayuki Nakano 68294ac1d3 Bug 1415445 - part 4: EditorBase::CreateNode() should take EditorRawDOMPoint as insertion point instead of a set of container, child and offset of the child in the container r=m_kato
EditorBase::CreateNode() should take EditorRawDOMPoint as insertion point of
the new element instead of a set of container, child and offset of the child
in the container.

This patch initializes EditorRawDOMPoint with original 3 arguments as far as
possible.  If the relation of them are broken, MOZ_ASSERT in RawRangeBoundary
constructor detects existing bugs.

MozReview-Commit-ID: 2N55S6pRv7k

--HG--
extra : rebase_source : 2b14a7715815ca0007635b8f791ca9edbe5b65f1
2017-11-08 20:23:10 +09:00
Masayuki Nakano 806668b21a Bug 1415062 - part 2: Editor should use Selection::Collapse(const RawRangeBoundary&) as far as possible r=m_kato
In some places, editor computes index from child node for collapsing selection
at the child node.  However, it's expensive.  Therefore, editor should use
Selection::Collapse(const RawRangeBoundary&) as far as possible.

MozReview-Commit-ID: LF2MwASuXzZ

--HG--
extra : rebase_source : b7afc35c0d9d88845391b6f18de57cbff1935ae4
2017-11-07 19:50:25 +09:00
Masayuki Nakano 8b6c211c36 Bug 1408544 - part 1: Reimplement EditorDOMPoint as a subclass of RangeBoundary r=catalinb,m_kato
A lot of methods in editor returns a child offset with an out param when it
returns its container and offset in the container.  This is ugly hack for
performance of nsINode::IndexOf().  However, there are a lot of regression
since the relation between offset and child node can be broken really easily.

So, we should make EditorDOMPoint as a subclass of RangeBoundary and manage
a set of container, reference child and its offset in it (e.g.,
SetNextSibling() added by this patch).

Note that RangeBoundary's performance is not good for temporary use if we set
a point with offset, it immediately retrieves mRef.  The following patch will
improve this performance.

MozReview-Commit-ID: 7mcJ1P1OjVr

--HG--
rename : editor/libeditor/EditorUtils.h => editor/libeditor/EditorDOMPoint.h
extra : rebase_source : 785094fcfc592d9e5b48cbc36ed225dbb8bb4111
2017-11-01 14:41:03 +09:00