* Pass rootNode to the constructor
* Rename getters to match CommentItem/HeadingItem/ThreadItem
value classes.
* Always build the thread tree so CommentItem's always have
and ID and replies/parent.
Change-Id: I508be9534de59016ff806e3d84edcbb1c76cb0c6
Load 'ext.visualEditor.mwsignature' (which implements VE's existing
handling for signatures), then subclass and override a bunch of things
in order to:
* Replace the context menu with a note that you don't need to type the
signature when commenting using the reply widget
* Override the sequence/command to insert signature so that it selects
it afterwards and thus displays the context menu
* Treat signatures as signature nodes when switching from wikitext,
instead of the normal pre-save transform turning them into regular
links and text
Bug: T255738
Change-Id: Icb542451c2307ab51e56bd627804096c7b5552c8
Instead of doing a separate tree walk and finding all timestamps
separately, make it part of the getComments tree walk, and find
timestamps one at a time.
Change-Id: I47f466eaf228504faa189fd99e07493bc7f022cd
This is similar to what the JS version does.
The TreeWalker and NodeFilter classes are adapted from
https://github.com/Krinkle/dom-TreeWalker-polyfill
(MIT license).
This makes #getComments twice as fast on en-big-oldparser.html
Change-Id: I2441f33e6e7bad753ac830d277e6a2e81ee8c93d
Rather than the <body> node, we were passing <body>'s first child.
Current implementation of CommentParser::getComments() doesn't fail
the tests in spite of this because the XPath query incorrectly returns
results relative to the document's real root node, but these tests
would start failing after I2441f33e6e7bad753ac830d277e6a2e81ee8c93d.
Follow-up to 3e6ab2c4d2.
Change-Id: Ic26e0a1ee4443987e215c5f26ef1f084ccd0b40b
This is a regression from when we added a wikitext parameter to
preparePreview. Calling getValue in visual mode converts the whole
DM to HTML, which is fairly expensive, especially as there are
no previews in visual mode.
Change-Id: Ieed61b0d7741e7204a942a7181923da0502981cd
We can update the local filtered list before then, but then we would
have to do two updates for each keystroke, one to do an instant local
filter and another to back-fill the list when the remote results
become available. Currently CompletionAction is not set up for this,
and this might be confusing behaviour.
Bug: T256974
Change-Id: I6194cdcd6459be17fb142e644d73c9ec4036ba08
