Previously you'd only learn about the issue when saving failed.
Now a modal alert dialog with the error message appears.
This means that we have to wait for the loading to finish before we
can display the ReplyWidget now... this should not be noticeable,
since we preload in #init.
Bug: T247533
Change-Id: I5468e67c449d530a0d15f69bff954d37a5b6a14c
This has two benefits:
* Allows detecting a conflict if two edits are saved in the same second
* Doesn't ignore conflicts with yourself (T246726)
Depends-On: Id7565018f66860b5c2ba688777508db1b88700ae
Bug: T246726
Change-Id: I22eaa1af5692854870d31e08b171a070a2fda0de
This is a problem we can detect at the loading stage, rather than at
the saving stage, so move it from #postReply to #getParsoidCommentData.
Follow-up to e3e4ef9de4.
Change-Id: I19362399f9ff2fdc487ea4900654bc61d990575f
When trying to reply to a comment that is inside a transclusion,
detect if it's transcluded from a subpage or simply wrapped in a
template, and show appropriate error messages.
References:
* VisualEditor ve.dm.Converter#getAboutGroup()
* VisualEditor ve.dm.ModelRegistry#matchElement()
* Parsoid Linter#findEnclosingTemplateName()
Bug: T245694
Change-Id: If3dd1ebbf1d02ee4379c200019bfc3a8ec02325b
If two signatures for a single comment were near each other,
we would sometimes treat them as one huge signature.
Change-Id: Ied4b3aa535a9ca6bebef8a004ae48b7d5a8f2f9b
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
