If we can't use the native closest() due to lack of browser support,
then I'd rather have a simple loop that implements the functionality
we need, instead of a fallback to another native method with limited
browser support and experimental implementations.
Change-Id: I0bf84aa25fc398e329b533afb28317d19716d57a
Currently not used for anything. May be used later for editing
comments (T245225) or reformatting timestamps (T240360).
Note that a comment may have multiple signatures+timestamps,
and we return them all so that you have to deal with that.
Fix some unrelated incorrect documentation comments.
Bug: T245220
Change-Id: I51b8bf4a3bb7968f35e32c7e44c95c2ab079d9ac
We disable the other reply links using 'pointer-events: none' in CSS,
but IE 11 doesn't support that.
I tried hiding them instead and using @supports rules in CSS to apply
'pointer-events: none', but the result was worse than this.
Change-Id: Iab2bfe9c623f3d32cce9776277f33483155a0c42
Now it also matches the font in the reply editor used when
$wgDiscussionToolsUseVisualEditor is true.
Depends-On: Ia866af0163b538596bfbb8c96a330186b667f85f
Bug: T246846
Change-Id: I21bdbe798949c0027eea16904ec6bc125c4746d8
We always pass the same arguments to the controller method and
two of those are global config values, so just pass the comment ID
each time it is used instead.
Change-Id: Ic68c70bdadb29310e930dd10fd6c6137d01ad22f
Previously they were added at the end of the text node containing the
timestamp, which was usually the end of the line, but not always.
And also fix the same problem for inserting the actual replies (or
reply widgets). This replaces an undocumented hack that prevented our
own reply links from triggering this bug (without it, the reply widget
would be inserted before the reply link rather than after).
While we're here, remove unintentional spacing that appeared before
some reply links, caused by trailing whitespace in text nodes.
Add tests for all of the above.
Bug: T245695
Change-Id: I354b63e2446bb996176a2e3d76abf944127f307e
This is the same as in VisualEditor. ve.parseXhtml has workarounds for
IE 11 bugs that would cause dirty diffs when saving.
Note that we must use ve.serializeXhtml to convert the document back
to a HTML string, but this is already the case (the conversion happens
in mw.libs.ve.targetSaver.saveDoc).
Change-Id: Ib6dec0002eaf33fc0d4a45331a6d38e5c5d7ab8c
On IE 11, the 'parentElement' property is only supported on element
nodes, not on text nodes.
https://developer.mozilla.org/en-US/docs/Web/API/Node/parentElement#Browser_compatibility
There's no reason to use it here, 'parentNode' is the same for the
nodes we're concerned with.
Also remove the use in code adapted from MDN to avoid repeating this
issue in the future.
Bug: T246565
Change-Id: I0120feb3737c462f2a64e4ec084249a0fd57d0f0
Sets the placeholder text to "Reply to <user>".
Bug: T245227
Depends-On: I7f3a58b7093d00aace9f9c6a95a121ba4e901ad8
Change-Id: Ie51f1848c17bb892e7f64adf6f7f19fc38e56202
They are not generated by MediaWiki, but they often appear when users
sign others' unsigned comments by copy-pasting the timestamp from the
history page.
Add test config data for nlwiki, exported by running this in the
browser console:
copy(
JSON.stringify( { wgArticlePath, wgNamespaceIds, wgFormattedNamespaces }, null, 2 ) + '\n' +
JSON.stringify( mw.loader.moduleRegistry['ext.discussionTools.parser'].packageExports['data.json'], null, 2 )
);
Bug: T245784
Change-Id: Icbcdc5a028e9ce2cb09173f87769e525ec3082fc
I think directories like this make more sense for adding more test cases.
Depends-On: I9153851fe162c012967fda00d3e1f81964a8dce9
Change-Id: Ibc72b747a75c72643c1fc04eae49bd15656e8104
* Hide the top-level discussiontools tag
* Change the wording of others to be more compact and consistent with the tense requested
Bug: T242184
Change-Id: Id7ba7fd7d0a387a3ca198fd546edf65fb663a9f8
