Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
HTMLEditRules::WillInsertBreak() started to use HTMLEditRules::MakeBasicBlock()
to wrap existing inline elements with default paragraph separator if inline
elements are children of editing host. However,
HTMLEditRules::ApplyBlockStyle() called by HTMLEditRules::MakeBasicBlock() sets
mNewNode to last new block node. So, if it wraps inline elements after caret
position, mNewNode becomes after expected caret position and
HTMLEditRules::AfterEditInner() will move caret into it.
This patch make HTMLEditRules::WillInsertBreak() reset mNewNode with
caret position after calling HTMLEditRules::MakeBasicBlock().
Additionally, this patch fixes a bug of HTMLEditor::IsVisibleBRElement().
That is, it uses only editable nodes to check if given <br> element is
visible. However, editable state is not related to this check. If <br>
element is followed by non-editable inline node (except invisible data
nodes), it always visible. This bug caused getting wrong nodes with
HTMLEditRules::GetNodesFromSelection() which is used by
HTMLEditRules::MakeBasicBlock(). Therefore, this patch also adds lots of
EditorBase::Get(Next|Previous)ElementOrText*() and
HTMLEditor::Get(Next|Previous)HTMLElementOrText*() to ignore only invisible
data nodes.
Note that even with this fix, the range of nodes computed by
HTMLEditRules::GetNodesFromSelection() is still odd if only non-editable
elements follow a <br> node which is first <br> element after the caret
position. However, what is expected by the execCommand spec is unclear.
So, automated test added by this patch checks current inconsistent behavior
for now.
MozReview-Commit-ID: 2m52StwoEEH
--HG--
extra : rebase_source : 6b9b2338e35c4d2e89a405fd8e1ffc7b0873ca1e
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
--HG--
extra : rebase_source : 856ef3715c924ca16e993ea57d92d1243b5cc6be
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
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
* The number is no longer selected on number input focus
MozReview-Commit-ID: AmR5c6YKTCP
--HG--
extra : rebase_source : fdaab23fca57f361c9185191d9c30e047375cbe8
* The number is no longer selected on number input focus
MozReview-Commit-ID: EoXNqhXwK95
--HG--
extra : rebase_source : b5a522e11796ec42c87019f6c3955e6c40eb21d0
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
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : 6cab2e6e7b4ba8cfb56d8320be24ca4afcbe55fb
extra : amend_source : 1d8c59086a9158a49dd270b64ecf8341ed4002ce
Before bug 1425091, we called RangeUpdater::SelAdjCreateNode() with point of
new node in EditorBase::CreateElement(). However, it was accidentally changed
to point *in* new element. Therefore, setting such DOM point causes warnings
in debug build and call of RangeUpdater::SelAdjCreateNode() must be failed
since the point stores wrong container node.
Additionally, this patch stops using another EditorRawDOMPoint instance which
is just redundant and renames |ret| to |newElement| for making its meaning
clearer.
MozReview-Commit-ID: Gc0YgaNLYcx
--HG--
extra : rebase_source : c2fbe2669ca8a5993e26b357f53dc38341fd6bf6
Since We can use EditorBase/TextEditor/HTMLEditor directly, we can
movei noscript methods in nsIEditor to each class.
Also, Init is unnecessary to use nsIDOMDocument and nsIContent since method
isn't in IDL. And some methods are unused now.
MozReview-Commit-ID: D3B6oSlcT0L
--HG--
extra : rebase_source : b89698f4ab56fdd97a4cd8c515a8b33f6a74a7af
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <