When the preview loads, the "Reply" / "Cancel" buttons shift downwards,
which looks ugly. Try to wait for the preview before showing the source
editor interface.
Bug: T234403
Change-Id: I70989fb9fbcac17e1a0672eda8d34bf26003bb96
* Reset to content dir for preview.
* <textarea> gets dir from the `.sitedir-* textarea` rule.
* VE already sets the content dir in the editor.
Bug: T253255
Change-Id: I76df093490e86a730ccd5610c43c9b3fc7e07a54
Exceptions were being treated like API errors, resulting in the
incorrect message "Invalid response from server." being shown to the
user. Instead show the error message.
Bug: T252238
Change-Id: Idbaee7d2b710812673992d30a17a9b5fe856a5a6
This means we have an instance for each comment, which makes keeping
track of local variables much simpler, and will make switching out
the widgets easier.
Change-Id: I7584870225b1a14146852987d6a40ad05957387c
Extra lines currently render empty list items which are invisible.
Remove these as the user probably didn't intend from them to appear
in the wikiext.
Bug: T249867
Change-Id: I75c1192a94b918783d362d38cd91a508bb169d56
* When we discover the comment comes from a transcluded page, follow
the transclusion to find the source page. We follow transclusions
recursively, up to an arbitrary limit of 10.
* In the reply widget, display the title of the page where we will
save the reply, to avoid users confused why their edit won't show up
in the history. In the wikitext workflow this is done by redirecting
the user to the edited page at the end, but it seems less surprising
to stay on the current page.
* After saving the reply, we must purge the current page, otherwise
the new content will not be immediately visible on it.
Bug: T247535
Change-Id: I1c6631aa65a2fce6c1c2f0dd4a8c7aa6389caf94
This fixes a warning in the API: 'Property "modules" was set but not
"jsconfigvars" or "encodedjsconfigvars". Configuration variables are
necessary for proper module usage.'
We were already updating them when saving.
Change-Id: I3e16e3fd4b43a438c27645cca90517b6b4be7db7
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
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
Sets the placeholder text to "Reply to <user>".
Bug: T245227
Depends-On: I7f3a58b7093d00aace9f9c6a95a121ba4e901ad8
Change-Id: Ie51f1848c17bb892e7f64adf6f7f19fc38e56202
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