Move all protected/private methods of TextEditRules/HTMLEditRules to editor class or somewhere
Categories
(Core :: DOM: Editor, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
Details
Attachments
(123 files)
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review |
I'm thinking that for keeping each line history in TextEditRules.cpp and HTMLEditRules.cpp, we should make existing methods in them stay in them. And then, they should be renamed to TextEditSubActionHandler.cpp and HTMLEditSubActionHandler.cpp.
In this bug, I'll move protected/private methods in them to EditorBase/TextEditor/HTMLEditor or some utility classes. If the destination is TextEditor or HTMLEditor, I'll keep them staying in the cpp files.
| Assignee | ||
Comment 1•6 years ago
|
||
This will be longer journey than I expected and becomes risky. So, we shouldn't land all patches once. We should land only several patches every time. Then, it helps to investigate regression point.
| Assignee | ||
Comment 2•6 years ago
|
||
HTMLEditRules::IsBlockNode() just wraps HTMLEditor::NodeIsBlockStatic()
and all its users will be moved into HTMLEditor. Therefore, we should
unwrap it.
| Assignee | ||
Comment 3•6 years ago
|
||
HTMLEditRules::IsInlineNode() is a wrapper of
HTMLEditor::NodeIsInlineStatic(), but returns opposite value.
This patch moves it into HTMLEditor and names it with same rule as
NodeIsBlockStatic().
Note that this method may return true if given node is unexpected node type.
E.g., comment node, CDATA node, etc. However, it's not scope of this bug.
| Assignee | ||
Comment 4•6 years ago
|
||
It's called immediately before setting mHTMLEditor and sets mHTMLEditor to
nullptr. So, it does nothing actually. We can get rid of it.
| Assignee | ||
Comment 5•6 years ago
|
||
| Assignee | ||
Comment 6•6 years ago
|
||
| Assignee | ||
Comment 7•6 years ago
|
||
| Assignee | ||
Comment 8•6 years ago
|
||
It's declared, but not defined.
| Assignee | ||
Comment 9•6 years ago
|
||
| Assignee | ||
Comment 10•6 years ago
|
||
| Assignee | ||
Comment 11•6 years ago
|
||
| Assignee | ||
Comment 12•6 years ago
|
||
| Assignee | ||
Comment 13•6 years ago
|
||
| Assignee | ||
Comment 14•6 years ago
|
||
| Assignee | ||
Comment 15•6 years ago
|
||
| Assignee | ||
Comment 16•6 years ago
|
||
| Assignee | ||
Comment 17•6 years ago
|
||
| Assignee | ||
Comment 18•6 years ago
|
||
| Assignee | ||
Comment 19•6 years ago
|
||
| Assignee | ||
Comment 20•6 years ago
|
||
This does not move the method simply. Instead, splits it to 4 simpler
methods.
Despite of the name, it modifies the DOM tree if aTouchContent is
TouchContent::yes. For avoiding this confusion and avoiding unnecessary
MOZ_CAN_RUN_SCRIPT attribute, the main part is split to
HTMLEditor::CollectEditTargetNodes().
If callers want to call HTMLEditRules::GetNodesForOperation() with
TouchContent::no, only calling this method equals to the call of
GetNodesForOperation().
Otherwise, the callers should call
HTMLEditor::SplitContentsAndCollectEditTargetNodes(). This calls internal
methods automatically.
First, HTMLEditor::SplitTextNodesAtRangeEnd() splits text nodes at end of
each range. Then, HTMLEditor::SplitParentInlineElementsAtRangeEdges()
overload splits inline elements at both edges of each range. Then, collects
event target nodes with calling HTMLEditor::CollectEditTargetNodes().
Finally, HTMLEditor::MaybeSplitElementsAtEveryBRElement() may split the
result nodes at every <br> element in them.
| Assignee | ||
Comment 21•6 years ago
|
||
HTMLEditRules::GetPromotedPoint() does too many things. Therefore, this patch
splits it to 3 methods. One is for specific EditSubAction values, that's
the first block in GetPromotedPoint(). It's named as
GetWhiteSpaceEndPoint(). Next one is for expanding start of the range to
start of its line. It's named as GetCurrentPhysicalLineStartPoint(). The
last one is for expanding end of the range to end of its line. It's named as
GetCurrentPhysicalLineEndPoint().
Comment 22•6 years ago
|
||
Comment 23•6 years ago
|
||
| bugherder | ||
Comment 24•6 years ago
|
||
Comment 25•6 years ago
|
||
| Assignee | ||
Comment 26•6 years ago
|
||
The method name is really unclear what's done. The method does 3 things.
One is try to select a <br> element in empty block if given range is
collapsed in the block. This is moved as
HTMLEditor::SelectBRElementIfCollapsedInEmptyBlock(). Next, it extends the
given range to include adjuscent whitespaces only when edit sub-action is
inserting or deleting text. This is moved as
HTMLEditor::CreateRangeIncludingAdjuscentWhiteSpaces(). Finally, when
handling the other edit sub-actions, extends the given range to start/end
of line at both edges. This is moved as
HTMLEditor::CreateRangeExtendedToHardLineStartAndEnd().
And also this patch makes each caller of PromoteRange() to check edit
sub-action by themselves. Unfortunately, this duplicates same logic to
multiple places, but makes what they do clearer. I think that the duplication
issue should be fixed later if necessary. Instead, we should shine the
blackbox of HTMLEditRules right now.
| Assignee | ||
Comment 27•6 years ago
|
||
HTMLEditRules::GetPromotedRanges() does 2 things. Calling
CreateRangeIncludingAdjuscentWhiteSpaces() or
CreateRangeExtendedToHardLineStartAndEnd() with each range of Selection.
The difference is considered with current edit sub-action. Therefore, we cal
split it to GetSelectionRangesExtendedToIncludeAdjuscentWhiteSpaces() and
GetSelectionRangesExtendedToHardLineStartAndEnd(). Then, we got clearer code
at each caller.
| Assignee | ||
Comment 28•6 years ago
|
||
HTMLEditRules::GetNodesFromSelection() has a patch to call
HTMLEditor::GetSelectionRangesExtendedToIncludeAdjuscentWhiteSpaces().
However, nobody uses this path so that we can get rid of this path.
Then, it becomes just calling SplitInlinesAndCollectEditTargetNodes() or
CollectEditTargetNodes() with result of
GetSelectionRangesExtendedToHardLineStartAndEnd(). Therefore, we can split
it to SplitInlinesAndCollectEditTargetNodesInExtendedSelectionRanges() and
CollectEditTargetNodesInExtendedSelectionRanges(). Then, we can mark
only the former as MOZ_CAN_RUN_SCRIPT.
| Assignee | ||
Comment 29•6 years ago
|
||
It's called only from HTMLEditRules::MoveBlock(). Even though it has 4
patters to call different methods, we need only one of them. Therefore,
this patch moves it into HTMLEditor.h as
SplitInlinesAndCollectEditTargetNodesInOneHardLine().
| Assignee | ||
Comment 30•6 years ago
|
||
It just collects all children of given node so that it can be a static method
in HTMLEditor.
| Assignee | ||
Comment 31•6 years ago
|
||
HTMLEditRules::LookInsideDivBQandList() does complicated things and I cannot
explain with a method name what it does. Fortunately, there are only 2 callers.
Therefore, this patch duplicates the part of modifying the range and creates
a method to retrieve "deepest and only editable child of <div>, <blockquote>
and one of list items".
| Assignee | ||
Comment 32•6 years ago
|
||
First half of HTMLEditoRules::GetListActionNodes() does 2 things. One is
trying to get parent list element of Selection ranges if aEntireList is
EntireList::yes. If it found a list element, it does nothing anymore.
Otherwise, falls backs to EntireList::no case. So, if each caller which
calls it with EntireList::yes, GetListActionNodes() does not need the
argument. Therefore, this patch does it first.
Then, GetListActionNodes() calls
CollectEditTargetNodesInExtendedSelectionRanges() or
SplitInlinesAndCollectEditTargetNodesInExtendedSelectionRanges(). It's
considered with aTouchContent is yes or no. So, this should be done
by each caller for making it clearer.
| Assignee | ||
Comment 33•6 years ago
|
||
HTMLEditRules::GetListActionNodes() removes non-editable element. However,
this should've been done by collector methods.
Comment 34•6 years ago
|
||
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=262875579&repo=autoland&lineNumber=3044
Backout: https://hg.mozilla.org/integration/autoland/rev/2ce3d67170d9c443f2e856460d0fe95a151a3509
Comment 35•6 years ago
|
||
Comment 36•6 years ago
|
||
Comment 37•6 years ago
|
||
Comment 38•6 years ago
|
||
Comment 39•6 years ago
|
||
| bugherder | ||
Comment 40•6 years ago
|
||
| bugherder | ||
Comment 41•6 years ago
|
||
Comment 42•6 years ago
|
||
| Assignee | ||
Comment 43•6 years ago
|
||
This patch fixes an existing bug with this clean up.
Except HTMLEditRules::MoveBlock(), GetListActionNodes() is called after
calling SplitInlinesAndCollectEditTargetNodesInExtendedSelectionRanges()
or CollectEditTargetNodesInExtendedSelectionRanges() with
EditSubAction::eCreateOrChangeList. I think that HTMLEditRules::MoveBlock()
using the edit sub-action is a simple mistake. Perhaps, it should be
EditSubAction::eCreateOrRemvoeBlock. However, I'm not 100% sure because
HTMLEditor::CollectEditTargetNodes() does special handling for
EditSubAction::eCreateOrRemvoeBlock but not so for
EditSubAction::eCreateOrChangeList. The behavior of difference between
those edit sub-actions are only here. Therefore, this patch creates new
EditSubAction eMergeBlockContents for MoveBlock().
Then, this patch makes HTMLEditor::CollectEditTargetNodes() handle
EditSubAction::eCreateOrChangeList insead of GetListActionNodes().
This causes one logic change in SplitInlinesAndCollectEditTargetNodes().
It calls MaybeSplitElementsAtEveryBRElement() after CollectEditTargetNodes()
so that this change makes calling MaybeSplitElementsAtEveryBRElement() at
last. According to my tests, new behavior must be expected since <br>
elements outside and in <table> should be handled consistently. Therefore,
this patch adds some simple testcases into WPT.
| Assignee | ||
Comment 44•6 years ago
|
||
| Assignee | ||
Comment 45•6 years ago
|
||
| Assignee | ||
Comment 46•6 years ago
|
||
| Assignee | ||
Comment 47•6 years ago
|
||
| Assignee | ||
Comment 48•6 years ago
|
||
| Assignee | ||
Comment 49•6 years ago
|
||
| Assignee | ||
Comment 50•6 years ago
|
||
| Assignee | ||
Comment 51•6 years ago
|
||
| Assignee | ||
Comment 52•6 years ago
|
||
Comment 53•6 years ago
|
||
Comment 54•6 years ago
|
||
Comment 55•6 years ago
|
||
Comment 56•6 years ago
|
||
Comment 57•6 years ago
|
||
| bugherder | ||
Comment 58•6 years ago
|
||
Comment 59•6 years ago
|
||
| Assignee | ||
Updated•6 years ago
|
Comment 60•6 years ago
|
||
Comment 61•6 years ago
|
||
Comment 62•6 years ago
|
||
Comment 63•6 years ago
|
||
| bugherder | ||
Comment 64•6 years ago
|
||
| bugherder | ||
Comment 65•6 years ago
|
||
Comment 66•6 years ago
|
||
Comment 67•6 years ago
|
||
Comment 68•6 years ago
|
||
| bugherder | ||
Comment 69•6 years ago
|
||
Comment 70•6 years ago
|
||
| bugherder | ||
Comment 71•6 years ago
|
||
Comment 72•6 years ago
|
||
| bugherder | ||
Comment 73•6 years ago
|
||
Comment 74•6 years ago
|
||
Comment 75•6 years ago
|
||
Comment 76•6 years ago
|
||
Comment 79•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/74ce25be0e9a
https://hg.mozilla.org/mozilla-central/rev/ada62f7a9760
https://hg.mozilla.org/mozilla-central/rev/65b324e80076
https://hg.mozilla.org/mozilla-central/rev/65a9f716e652
https://hg.mozilla.org/mozilla-central/rev/8804f2b110be
https://hg.mozilla.org/mozilla-central/rev/c3e4c8a6b1ff
Comment 81•6 years ago
|
||
Comment 82•6 years ago
|
||
Comment 83•6 years ago
|
||
Comment 84•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/15bfd420d024
https://hg.mozilla.org/mozilla-central/rev/8257421bca60
https://hg.mozilla.org/mozilla-central/rev/c701cf449d2c
https://hg.mozilla.org/mozilla-central/rev/9d63a239b705
https://hg.mozilla.org/mozilla-central/rev/85b7e9527466
https://hg.mozilla.org/mozilla-central/rev/2871d02f3f7b
Comment 85•6 years ago
|
||
Comment 86•6 years ago
|
||
| bugherder | ||
Updated•6 years ago
|
| Assignee | ||
Comment 87•6 years ago
|
||
| Assignee | ||
Comment 88•6 years ago
|
||
And this fixes the caller which has not guaranteed the lifetime of the
start container.
| Assignee | ||
Comment 89•6 years ago
|
||
| Assignee | ||
Comment 90•6 years ago
|
||
HTMLEditRules::WillMakeBasicBlock() just calls
HTMLEditor::FormatBlockContainer() and it's called only for
EditSubAction::eCreateOrRemoveBlock and it's used only in
HTMLEditor::InsertBasicBlockWithTransaction(). Therefore, we can replace
calling HTMLEditRules::WillDoAction() in it with what
HTMLEditRules::WIllMakeBasicBlock() does.
First, HTMLEditRules::WillDoAction() checks whether first selection range
is editable. If it's not so, it returns NS_OK with setting aCancel to
true. Therefore, this patch moves this part to
HTMLEditor::CanHandleHTMLEditSubAction() for making
HTMLEditor::InsertBasicBlockWithTransaction() can check it easier.
Next, HTMLEditor::InsertBasicBlockWithTransaction() does something if
HTMLEditRules::WillDoAction() returns as not handled nor canceled.
However, this special handling requires at least one selection range:
https://searchfox.org/mozilla-central/rev/597a69c70a5cce6f42f159eb54ad1ef6745f5432/editor/libeditor/HTMLEditor.cpp#2284-2288
Surprisingly, handled is set to false only when there is an error or
there is no selection range. Therefore, this long block has already been
dead code so that we can remove this. Removing this block causes that we
become not throwing exception when Document.execCommand("formatblock")
without selection ranges. But this is better since Chrome does not throw
excption.
Finally, this patch renames some related methods:
HTMLEditor::FormatBlockContainer()->HTMLEditor::FormatBlockContainerWithTransaction()HTMLEditor::InsertBasicBlockWithTransaction()->HTMLEditor::FormatBlockContainerAsSubAction()
| Assignee | ||
Comment 91•6 years ago
|
||
| Assignee | ||
Comment 92•6 years ago
|
||
| Assignee | ||
Comment 93•6 years ago
|
||
| Assignee | ||
Comment 94•6 years ago
|
||
| Assignee | ||
Comment 95•6 years ago
|
||
| Assignee | ||
Comment 96•6 years ago
|
||
| Assignee | ||
Comment 97•6 years ago
|
||
| Assignee | ||
Comment 98•6 years ago
|
||
It's used both by TextEditRules and HTMLEditRules so that EditorBase
should have it instead.
| Assignee | ||
Comment 99•6 years ago
|
||
| Assignee | ||
Comment 100•6 years ago
|
||
Meaningful job of HTMLEditor::InsertParagraphSeparatorAsSubAction() is only
calling HTMLEditRules::WillInsertParagraph() via
HTMLEditRules::WillDoAction(). Therefore, we can move all jobs in them
into HTMLEditRules::WillInsertParagraph() and rename it to
HTMLEditor::InsertParagraphSeparatorAsSubAction().
| Assignee | ||
Comment 101•6 years ago
|
||
| Assignee | ||
Comment 102•6 years ago
|
||
| Assignee | ||
Comment 103•6 years ago
|
||
Additionally, this patch makes it use early-return style with continue as
far as making number of changing line minimized.
| Assignee | ||
Comment 104•6 years ago
|
||
HTMLEditRules::WillMakeDefinitionList() just calls
HTMLEditRules::WillMakeList() and HTMLEditRules::WillMakeList() can be
called as HTMLEditRules::MakeOrChangeListAndListItemAsSubAction() so that
we should merge them and make HTMLEditor call it directly.
This patch also removes default action part of
HTMLEditor::MakeOrChangeListAsAction() because it runs only when
HTMLEditRules::WillDoAction() does not return canceled nor error but not
handled, however, it's won't occur since HTMLEditRules::WillMakeList()
always sets aHandled to true when it returns NS_OK.
| Assignee | ||
Comment 105•6 years ago
|
||
| Assignee | ||
Comment 106•6 years ago
|
||
This is defined as too complicated than what it does actually since there
was not EditorDOMPointBase.
If given point's offset is 0, returns nullptr. If aWhere is
BRLocation::blockEnd, treats aOffset is length of aBlock. Otherwise,
using given point. Then, if the WSRun start reason is br, returns the
start reason node. This means that this method just retrieves invisible
<br> element if it starts WSRun at given point.
Now, callers can specify end of block with EditorDOMPointBase::SetToEndOf()
easier. Therefore, we can make it take only an EditorDOMPointBase instance.
| Assignee | ||
Comment 107•6 years ago
|
||
| Assignee | ||
Comment 108•6 years ago
|
||
Making them return next insertion point with nsresult makes the callers
easier to understand. Therefore, this patch declares MoveNodeResult class
newly and make them use it.
And also we can get rid of the case of setting *aInOutDestOffset to -1
because it's a hacky case of HTMLEditRules::MoveBlock(). If we keep it,
MoveNodeSmart() needs to compute new insertion point with different logic.
Therefore, this patch makes HTMLEditRules::MoveBlock() adjust new insertion
point with checking its argument.
| Assignee | ||
Comment 109•6 years ago
|
||
| Assignee | ||
Comment 110•6 years ago
|
||
Additionally, WSRunObject::ScrabBlockBoundary() and
WSRunObject::PreparetToJoinBlocks() are used only the it. Therefore, we
can clean them up.
| Assignee | ||
Comment 111•6 years ago
|
||
| Assignee | ||
Comment 112•6 years ago
|
||
| Assignee | ||
Comment 113•6 years ago
|
||
| Assignee | ||
Comment 114•6 years ago
|
||
And this patch makes the new method do not touch Selection, instead, return
new StaticRange. Although the creation cost may make damage to the
performance but let's keep using StaticRange for now. There should be
a stack only class which have 2 RangeBoundaryBase or EditorDOMPointBase.
Comment 115•6 years ago
|
||
Comment 116•6 years ago
|
||
Comment 117•6 years ago
|
||
| bugherder | ||
| Assignee | ||
Comment 118•6 years ago
|
||
Before moving the largest method in our tree, we should split it. This is
first preparation of that.
| Assignee | ||
Comment 119•6 years ago
|
||
| Assignee | ||
Comment 120•6 years ago
|
||
First, we can split it with 3 parts:
- preparation with current selection part.
- handling deletion with collapsed selection part.
- handling deletion with non-collapsed selection part.
The first should leave inWillDeleteSelection(), but the others should be
moved to independent methods.
With this change, we need to fix an odd case when there is no visible node
and GetFirstSelectedTableCellElement() returned error due to crossing
the method boundary. The method returns error only when there is no selection
ranges. In such case, we cannot handle deletion of current selection anyway.
So, it must not be a problem to handle the error immediately after calling
GetFirstSelectedTableCellElement(). Note that this shouldn't occur in
normal cases since WillDoAction() checks it before calling
WillDeleteSelection().
| Assignee | ||
Comment 121•6 years ago
|
||
| Assignee | ||
Comment 122•6 years ago
|
||
Before splitting the method, we should make it use EditorDOMPoint to
treat selection edges.
| Assignee | ||
Comment 123•6 years ago
|
||
| Assignee | ||
Comment 124•6 years ago
|
||
| Assignee | ||
Comment 125•6 years ago
|
||
| Assignee | ||
Comment 126•6 years ago
|
||
The next simple case is using early-return style and does not refer modified
firstRangeStart nor firstRangeEnd so that it can do same thing without
AutoTrackDOMPoint.
Then, there is remaining the complicated case. We cannot split it anymore.
Note that we should not split HandleDeleteNonCollapsedSelection() anymore
because as you know, it does not make sense. It checks only first range
and consider how to treat all ranges. We should split it after we investigate
deeper with writing new WPT.
| Assignee | ||
Comment 127•6 years ago
|
||
| Assignee | ||
Comment 128•6 years ago
|
||
It scans children and returns whether <dt> and <dd> are found or not.
So, we can make it a stack class and makes caller pick the necessary value
with getter methods.
| Assignee | ||
Comment 129•6 years ago
|
||
| Assignee | ||
Comment 130•6 years ago
|
||
| Assignee | ||
Comment 131•6 years ago
|
||
| Assignee | ||
Comment 132•6 years ago
|
||
Comment 133•6 years ago
|
||
| bugherder | ||
Comment 134•6 years ago
|
||
Comment 135•6 years ago
|
||
Comment 136•6 years ago
|
||
| bugherder | ||
Comment 137•6 years ago
|
||
Comment 138•6 years ago
|
||
Comment 139•6 years ago
|
||
| bugherder | ||
Comment 140•6 years ago
|
||
Comment 141•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/428adee67846
https://hg.mozilla.org/mozilla-central/rev/d00ed80a7115
https://hg.mozilla.org/mozilla-central/rev/fc87b392688b
https://hg.mozilla.org/mozilla-central/rev/7ece9cd0da19
https://hg.mozilla.org/mozilla-central/rev/b7d720cd37f9
https://hg.mozilla.org/mozilla-central/rev/fae7917900bd
https://hg.mozilla.org/mozilla-central/rev/0c0302b3db46
Comment 142•6 years ago
|
||
Comment 143•6 years ago
|
||
Comment 144•6 years ago
|
||
| Assignee | ||
Comment 145•6 years ago
|
||
And also this patch fixes unexpected behavior change by bug 1460509:
https://searchfox.org/mozilla-central/diff/d5d67de86f23655fcccc7bbcf4423bb75148fd34/editor/libeditor/HTMLEditRules.cpp#4466
| Assignee | ||
Comment 146•6 years ago
|
||
| Assignee | ||
Comment 147•6 years ago
|
||
| Assignee | ||
Comment 148•6 years ago
|
||
| Assignee | ||
Comment 149•6 years ago
|
||
The caller of HTMLEditRules::WillDoAction() is shared with "outdent".
Therefore, this patch is a preparation of makes HTMLEditor stop calling it.
Be aware, HTMLEditRules::WillIndent() won't cancel the action, and also
always handles the action unless editor has already been destroyed. Therefore,
we can remove the dead code in HTMLEditor::IndentOrOutdentAsSubAction()
right now.
| Assignee | ||
Comment 150•6 years ago
|
||
| Assignee | ||
Comment 151•6 years ago
|
||
| Assignee | ||
Comment 152•6 years ago
|
||
| Assignee | ||
Comment 153•6 years ago
|
||
| Assignee | ||
Comment 154•6 years ago
|
||
| Assignee | ||
Comment 155•6 years ago
|
||
HTMLEditRules::MakeSureElemStartsOrEndsOnCR() is unclear what it does.
And fortunately, its job is simple if we split it to each mode. Therefore,
this patch splits it to EnsureHardLineBeginsWithFirstChildOf() and
EnsureHardLineEndsWithLastChildOf(). Finally, the batch caller of them,
HTMLEditRules::MakeSureElemStartsAndEndsOnCR() is removed since directly
calling both of them is clearer.
| Assignee | ||
Comment 156•6 years ago
|
||
And also this patch removes unnecessary declarations in HTMLEditRules.h.
| Assignee | ||
Comment 157•6 years ago
|
||
With guaranteeing the argument element type with MOZ_ASSERT(), we can
make it really simpler.
| Assignee | ||
Comment 158•6 years ago
|
||
And also this splits large 2 blocks of
HTMLEditRules::AlignContentsAtSelection() to 2 methods.
| Assignee | ||
Comment 159•6 years ago
|
||
| Assignee | ||
Comment 160•6 years ago
|
||
| Assignee | ||
Comment 161•6 years ago
|
||
| Assignee | ||
Comment 162•6 years ago
|
||
| Assignee | ||
Comment 163•6 years ago
|
||
| Assignee | ||
Comment 164•6 years ago
|
||
| Assignee | ||
Comment 165•6 years ago
|
||
| Assignee | ||
Comment 166•6 years ago
|
||
| Assignee | ||
Comment 167•6 years ago
|
||
Comment 168•6 years ago
|
||
Comment 169•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/b08d2e18630f
https://hg.mozilla.org/mozilla-central/rev/38bf4be88279
https://hg.mozilla.org/mozilla-central/rev/576017f68d3a
https://hg.mozilla.org/mozilla-central/rev/363362abb3e9
https://hg.mozilla.org/mozilla-central/rev/082159fea413
https://hg.mozilla.org/mozilla-central/rev/cd2b83d5dda7
https://hg.mozilla.org/mozilla-central/rev/9ced245d5835
https://hg.mozilla.org/mozilla-central/rev/4b5edaf3b72c
https://hg.mozilla.org/mozilla-central/rev/81c375145c55
https://hg.mozilla.org/mozilla-central/rev/4d5dde4e72b4
https://hg.mozilla.org/mozilla-central/rev/68fad864eca4
Comment 170•6 years ago
|
||
Comment 171•6 years ago
|
||
Comment 172•6 years ago
|
||
| bugherder | ||
Comment 173•6 years ago
|
||
Comment 174•6 years ago
|
||
| bugherder | ||
Comment 175•6 years ago
|
||
Comment 176•6 years ago
|
||
Comment 177•6 years ago
|
||
Comment 178•6 years ago
|
||
Comment 179•6 years ago
|
||
| bugherder | ||
Comment 180•6 years ago
|
||
Comment 181•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/23057aa94ccc
https://hg.mozilla.org/mozilla-central/rev/ec96ba02db83
https://hg.mozilla.org/mozilla-central/rev/6db67114e977
https://hg.mozilla.org/mozilla-central/rev/f6967548beb1
https://hg.mozilla.org/mozilla-central/rev/e9b7ba436ec2
https://hg.mozilla.org/mozilla-central/rev/3764a05b6288
https://hg.mozilla.org/mozilla-central/rev/c3a59e9eeba8
https://hg.mozilla.org/mozilla-central/rev/4f6733afb731
https://hg.mozilla.org/mozilla-central/rev/196ce3ca6e9d
Comment 182•6 years ago
|
||
Comment 183•6 years ago
|
||
| bugherder | ||
Comment 184•6 years ago
|
||
Comment 185•6 years ago
|
||
Comment 186•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a139a607ac27
https://hg.mozilla.org/mozilla-central/rev/9ea3f12721ae
https://hg.mozilla.org/mozilla-central/rev/edaf6d0b4d04
https://hg.mozilla.org/mozilla-central/rev/4351a64b385e
https://hg.mozilla.org/mozilla-central/rev/8c629098c9c9
https://hg.mozilla.org/mozilla-central/rev/bc646246502b
https://hg.mozilla.org/mozilla-central/rev/82d915a1e498
https://hg.mozilla.org/mozilla-central/rev/fd513039041e
https://hg.mozilla.org/mozilla-central/rev/7a484d560816
Comment 187•6 years ago
|
||
Comment 188•6 years ago
|
||
| Assignee | ||
Comment 189•6 years ago
|
||
Oddly, absolute position is handled as following steps.
WillAbsolutePosition()callsPrepareToMakeElementAbsolutePosition()
to consider the target element.- Set TopLevelEditSubActionData::mNewBlockElement to it.
DidAbsolutePosition()makes it absolute-positioned.
So that, all of them can be done in WillAbsolutePosition() like other
edit sub-action handling.
| Assignee | ||
Comment 190•6 years ago
|
||
Only caller of it is WillRemoveAbsolutePosition() and it always sets
*aHandled to true before calling it. Therefore, it does not need to take
it as an argument.
| Assignee | ||
Comment 191•6 years ago
|
||
| Assignee | ||
Comment 192•6 years ago
|
||
| Assignee | ||
Comment 193•6 years ago
|
||
There are only 3 callers and it does simple but different 2 things. One of
the callers is HTMLEditRules::DidDeleteSelection() so that if same things
are done by TextEditor::DeleteSelectionAsSubAction(), it does not need to
duplicate the code. Therefore, we need to duplicate the code into
TextEditor::DeleteSelectionAsSubAction() and TextEditRules::WillSetText().
Then, TextEditRules::WillSetText() can avoid accessing Selection since
it still grabs the modified text node.
Note that only when it's called by TextEditRules::DidDoAction(),
AutoTransactionsConserveSelection has been set. However, neither
DeleteNodeWithTransaction() nor DeleteNodeTransaction::DoTransaction()
changes Selection. Therefore, it hasn't do anything. So, we can remove
it right now.
| Assignee | ||
Comment 194•6 years ago
|
||
| Assignee | ||
Comment 195•6 years ago
|
||
| Assignee | ||
Comment 196•6 years ago
|
||
| Assignee | ||
Comment 197•6 years ago
|
||
And also this patch moves TextEditRules::HandleNewLines() and
TextEditRules::DontEchoPassword() to TextEditor.
| Assignee | ||
Comment 198•6 years ago
|
||
Oddly, they are used only by HTMLEditor, but implemented by TextEditRules.
They cancels when the editor is in plaintext mode. So, actual things are
implemented by each caller. This patch cleans them up too.
| Assignee | ||
Comment 199•6 years ago
|
||
TextEditor::DeleteSelectionAsSubAction() starts to handle all
"delete selection" sub-actions (i.e., even if the instance is HTMLEditor).
Therefore, TextEditRules::WillDeleteSelection() should be renamed to
TextEditor::HandleDeleteSelection() and we need to make it virtual.
| Assignee | ||
Comment 200•6 years ago
|
||
In TextEditor::HandleDeleteSelection(), we have only one path of returning
EditActionIgnored(). Therefore, it should call
DeleteSelectionWithTransaction() directly.
On the other hand, it's not clear in HTMLEditor::HandleDeleteSelection()
since it may be called recursively by its helper methods. Therefore,
this patch creates HTMLEditor::HandleDeleteSelectionInternal() for the
recursive calls and makes HTMLEditor::HandleDeleteSelection() call
DeleteSelectionWithTransaction() if nobody handled it and to the
HTMLEditor specific post-process in it.
Comment 201•6 years ago
|
||
Comment 202•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/220c2d3cd5e0
https://hg.mozilla.org/mozilla-central/rev/a25bf7589eb6
https://hg.mozilla.org/mozilla-central/rev/8edfd974fc63
https://hg.mozilla.org/mozilla-central/rev/95684e6acbd3
https://hg.mozilla.org/mozilla-central/rev/735f520eadfa
https://hg.mozilla.org/mozilla-central/rev/99edaf54b89f
Comment 203•6 years ago
|
||
| bugherder | ||
Comment 204•6 years ago
|
||
| Assignee | ||
Comment 205•6 years ago
|
||
| Assignee | ||
Comment 206•6 years ago
|
||
| Assignee | ||
Comment 207•6 years ago
|
||
And also renaming EditorBase::SetTextImpl().
| Assignee | ||
Comment 208•6 years ago
|
||
It does 4 different things so that it looks like a black-box from the
callers.
First, only HTMLEditRules::WillDoAction() refers aCancel out argument.
Therefore, it should check whether it's cancelled or not directly.
Next, EnsureNoPaddingBRElementForEmptyEditor() should be called by each
caller directly.
Then, the renaming part can be split to 2 methods. One is adjusting
caret position and the other preparing inline style for new content.
Unfortunately, this patch makes each caller messy. I think that for the
3rd job (i.e., adjusting caret position), each caller should retrieve the
adjusted caret position and use it directly instead of handling with
Selection in the future.
| Assignee | ||
Comment 209•6 years ago
|
||
Unfortunately, EditSubAction::eInsertElement is used by 4 methods and one
of them is too big method. But we should move what old WillInsert() does
into them for stop making anybody use HTMLEditRules.
| Assignee | ||
Comment 210•6 years ago
|
||
It requires different preparation in TextEditor and HTMLEditor but it's
not split. Therefore, we should make it virtual and override it to use
different preparation code. Fortunately, its code is enough simple to
duplicate.
Additionally, this removes unnecessary code from TextEditRules and
HTMLEditRules including WillDoAction() and DidDoAction()!
| Assignee | ||
Comment 211•6 years ago
|
||
| Assignee | ||
Comment 212•6 years ago
|
||
That's all!
Unfortunately, HTMLEditRules::WillInsert() related part makes the callers messy even though making them easier to understand. I'll try to think how we should do between "making sure everybody does all things at preparation" vs. "avoiding too generic method name".
Comment 213•6 years ago
|
||
| bugherder | ||
Comment 214•6 years ago
|
||
Comment 215•6 years ago
|
||
| bugherder | ||
Comment 216•6 years ago
|
||
Comment 217•6 years ago
|
||
Comment 218•6 years ago
|
||
Comment 219•6 years ago
|
||
| bugherder | ||
Comment 220•6 years ago
|
||
Comment 221•6 years ago
|
||
| bugherder | ||
Comment 222•6 years ago
|
||
| bugherder | ||
Comment 223•6 years ago
|
||
Comment 224•6 years ago
|
||
Comment 225•6 years ago
|
||
| bugherder | ||
Comment 226•6 years ago
|
||
| bugherder | ||
Comment 227•6 years ago
|
||
Comment 228•6 years ago
|
||
Backed out 2 changesets (bug 1574852) for assertion failures at TextEditRules.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/aa6d5d26e1d2ceb03b066e33e22b4b4059ff5102
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=266721422&resultStatus=testfailed%2Cbusted%2Cexception&revision=f54f6af6359dc358b2b91f6870f418462cc31e88
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=266721422&repo=autoland&lineNumber=4082
Log snippet:
[task 2019-09-14T23:20:11.700Z] 23:20:11 INFO - TEST-START | browser/extensions/formautofill/test/mochitest/test_basic_autocomplete_form.html
[task 2019-09-14T23:20:11.761Z] 23:20:11 INFO - GECKO(2372) | ++DOMWINDOW == 13 (0x7f2b0641a800) [pid = 2445] [serial = 20] [outer = 0x7f2b035fa3e0]
[task 2019-09-14T23:20:12.123Z] 23:20:12 INFO - GECKO(2372) | --DOMWINDOW == 12 (0x7f2b07036000) [pid = 2445] [serial = 15] [outer = (nil)] [url = http://mochi.test:8888/tests/SimpleTest/iframe-between-tests.html]
[task 2019-09-14T23:20:12.124Z] 23:20:12 INFO - GECKO(2372) | --DOMWINDOW == 11 (0x7f2b02d70000) [pid = 2445] [serial = 11] [outer = (nil)] [url = http://mochi.test:8888/tests/browser/extensions/formautofill/test/mochitest/test_address_level_1_submission.html]
[task 2019-09-14T23:20:12.124Z] 23:20:12 INFO - GECKO(2372) | --DOMWINDOW == 10 (0x7f2b038e4000) [pid = 2445] [serial = 14] [outer = (nil)] [url = http://mochi.test:8888/]
[task 2019-09-14T23:20:13.106Z] 23:20:13 INFO - GECKO(2372) | --DOMWINDOW == 11 (0x7f70a3b24000) [pid = 2422] [serial = 2] [outer = (nil)] [url = about:blank]
[task 2019-09-14T23:20:13.106Z] 23:20:13 INFO - GECKO(2372) | --DOMWINDOW == 10 (0x7f70a3c8b400) [pid = 2422] [serial = 4] [outer = (nil)] [url = about:blank]
[task 2019-09-14T23:20:13.107Z] 23:20:13 INFO - GECKO(2372) | --DOMWINDOW == 9 (0x7f70a3c8d800) [pid = 2422] [serial = 6] [outer = (nil)] [url = about:blank]
[task 2019-09-14T23:20:13.107Z] 23:20:13 INFO - GECKO(2372) | --DOMWINDOW == 8 (0x7f70a3c90000) [pid = 2422] [serial = 8] [outer = (nil)] [url = about:blank]
[task 2019-09-14T23:20:13.155Z] 23:20:13 INFO - GECKO(2372) | --DOMWINDOW == 7 (0x7f70a4b835c0) [pid = 2422] [serial = 7] [outer = (nil)] [url = moz-extension://cc12f14d-a078-467f-925e-f03435f1d5fb/_generated_background_page.html]
[task 2019-09-14T23:20:14.639Z] 23:20:14 INFO - GECKO(2372) | Assertion failure: !AsTextEditor(), at /builds/worker/workspace/build/src/editor/libeditor/TextEditRules.cpp:684
[task 2019-09-14T23:20:35.543Z] 23:20:35 INFO - GECKO(2372) | #01: mozilla::TextEditor::SetTextAsSubAction(nsTSubstring<char16_t> const&) [editor/libeditor/TextEditor.cpp:1067]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #02: mozilla::TextEditor::SetTextAsAction(nsTSubstring<char16_t> const&, nsIPrincipal*) [editor/libeditor/TextEditor.cpp:993]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #03: nsTextEditorState::SetValue(nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const*, unsigned int) [dom/html/nsTextEditorState.cpp:2394]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #04: mozilla::dom::HTMLInputElement::SetValueInternal(nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const*, unsigned int) [dom/html/HTMLInputElement.cpp:2644]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #05: mozilla::dom::HTMLInputElement::SetValue(nsTSubstring<char16_t> const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [dom/html/HTMLInputElement.cpp:1607]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #06: mozilla::dom::HTMLInputElement_Binding::set_value(JSContext*, JS::Handle<JSObject*>, mozilla::dom::HTMLInputElement*, JSJitSetterCallArgs) [s3:gecko-generated-sources:574d6ddfcd438d58aabc0df938153eb30193fcbbd96ac311a4e58c0b296f81393cb4bbe3106b0cb067e7e404c199c04df78d41e0c5eafdadbbb0750db214ede6/dom/bindings/HTMLInputElementBinding.cpp::3091]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #07: bool mozilla::dom::binding_detail::GenericSetter<mozilla::dom::binding_detail::NormalThisPolicy>(JSContext*, unsigned int, JS::Value*) [dom/bindings/BindingUtils.cpp:3121]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #08: CallJSNative(JSContext*, bool ()(JSContext, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) [js/src/vm/Interpreter.cpp:458]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #09: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [js/src/vm/Interpreter.cpp:551]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #10: js::CallSetter(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::Handle<JS::Value>) [js/src/vm/Interpreter.cpp:775]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO - GECKO(2372) | #11: SetExistingProperty(JSContext*, JS::Handle<JS::PropertyKey>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::Handle<js::NativeObject*>, JS::Handle<JS::PropertyResult>, JS::ObjectOpResult&) [js/src/vm/NativeObject.cpp:2932]
[task 2019-09-14T23:20:35.544Z] 23:20:35 INFO -
| Assignee | ||
Comment 229•6 years ago
|
||
Oh, I must have fixed the wrong assertion in a wrong patch....
Comment 230•6 years ago
|
||
Comment 231•6 years ago
|
||
Comment 232•6 years ago
|
||
| bugherder | ||
| Assignee | ||
Updated•6 years ago
|
Comment 233•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/c4b35bfd9276
https://hg.mozilla.org/mozilla-central/rev/a6c31b6a60e0
https://hg.mozilla.org/mozilla-central/rev/a4bfd6e22c41
Description
•