The "Reply" buttons were active when viewing an old revision of the
page (&oldid=1234). This was probably unintentional, and it would undo
all more recent comments if you saved yours.
However, I think it would be a useful feature. You often end up
viewing old revisions when reviewing changes to pages from your
watchlist or email notifications.
Now, when the reply widget is launched from an old revision, it will
try to find the relevant parent comment in the latest revision of the
page, and edit that revision when inserting the reply. If the parent
comment is gone, it shows a useful error message.
Bug: T235761
Change-Id: I8c5b631d3bfb62196fd219cbcd7d497408d187a7
The most common case of edit conflicts on talk pages is several people
responding to the same comment at the same time.[citation needed]
We can easily resolve this case by fetching the latest revision of the
page and re-running our code to insert a reply on it.
When we can't insert a reply, that probably means the parent comment
was deleted or moved, so display an error message indicating that
instead of the generic one.
Bug: T240643
Change-Id: Ic686acc747580d46779960211a02e9830a6ae86f
Previously, we only built the Parsoid document once (on page load) and
kept it around forever. Every time we tried to post a reply, it was
added to this document, even if it wasn't saved due to some error.
This resulted in duplicate replies when the user managed to actually
save.
Now we only keep around the HTML string and some metadata fetched from
the API, and rebuild the actual document every time before adding a
reply.
Bug: T245333
Change-Id: Ib1c344a7d613cdf67644aa243147c5e699c2c1e7
Sepatate #teardown and #tryTeardown methods to make it
obvious what they do. Have <escape> call #tryTeardown
like the cancel button.
Change-Id: Ica0f3295bfee378bcd15d0b6a3ccea3c7917ad9b
* Add config option $wgDiscussionToolsUseVisualEditor (default false).
* Add new modules ext.discussionTools.ReplyWidgetPlain and ...ReplyWidgetVisual,
replacing ...ReplyWidget. Load only one of them depending on the config.
TODO:
* Also add the visual mode of VisualEditor, this only uses NWE now.
There is already code to support saving from it, but no mode
switcher tool
Co-Authored-By: Ed Sanders <esanders@wikimedia.org>
Co-Authored-By: Bartosz Dziewoński <matma.rex@gmail.com>
Change-Id: I9b6db865d51baf400fb715dc7aa68ccd8cdd4905
I did this wrong in a6147ffac8, the
'dt-init-done' class was never cleared. Put it on another element.
Bug: T241861
Change-Id: I136bd9c12bcc80cff01f5d26a8a53524f0c533c6
Unfortunately mw.Api#parse doesn't provide us with that part of the
response, so we have to manually construct the parameters.
Bug: T241193
Change-Id: Ie91d5ebc2ef483a69524b838dd3cb852e7c85cd2
And actually discard the contents when they confirm.
For now this uses the generic editor message, but that can
be tweaked later.
Bug: T240271
Change-Id: I2dfa19b2cc7ac49d7efea37ac8c9429c75934a91
The packageFiles system makes it easier to export site config data
from PHP to JS, which we need a lot of, but it's awkward when mixing
it with defining and accessing classes via a namespace like mw.dt.
The only thing remaining in mw.dt is mw.dt.pageThreads, which is
described to be "for debugging", so we should keep it easy to type.
Also we still use the namespace for documenting classes.
Everything else can be reached by require()'ing a ResourceLoader
module, for example instead of `mw.dt.ui.ReplyWidget`
you'd do `require( 'ext.discussionTools.ReplyWidget' )`.
(When debugging from browser console, use `mw.loader.require` instead.)
Change-Id: I6496abcf58c21658d6fd0f3fc1db1f7380a89df7
Possible use cases:
* Matching comments between PHP and Parsoid HTML [implemented here]
* Finding the same comment in a different revision of a page
(e.g. while resolving an edit conflict, or to allow resuming
composition of autosaved comments) [implemented for highlighting
user's own posted comment only]
* Permanent links to comments [future]
The reasoning for this form of ID is:
* _Timestamp_ by itself is a nearly unique identifier, so it's a good
thing to start with
* Users may post multiple comments in one edit (or in many edits in
one minute), so we need the _sequential number_ to distinguish them
* _Username_ is probably not required, but it may reduce the need
for sequential numbers, and will help with human-readability if we
add permanent links
The ID remains stable when a new comment is added anywhere by anyone
(excepts comments within the same minute by the same user), or when a
section is renamed.
It's not always stable when a comment is moved or when an entire
section is moved or deleted (archived), but you can't have everything.
Change-Id: Idaae6427d659d12b82e37f1791bd03833632c7c0
