We'd like the [reply] links to behave differently if other
CommentControllers are already active, but each CommentController
doesn't know anything about others; only the main controller.js does.
Change-Id: Ic21b2d40d213a325509822f703709f52aa8dc8d7
If the module is loaded on a page where DiscussionTools is
not supposed to be enabled, wgDiscussionToolsFeaturesEnabled
will be undefined, and the code will crash before it can set
the cookie that enables it for future page views.
Bug: T272850
Change-Id: Ia1c40cfc3cbee62823f1806bd20229883905677a
Add yet another tree walking utility: CommentUtils::linearWalk().
Unlike TreeWalker, it allows handling the beginnings and ends of nodes
separately – kind of like parsing a XML token stream, or kind of like
VisualEditor's linear model.
(Add unit tests for this utility. The simple.html test case is copied
from [VisualEditor/VisualEditor]/demos/ve/pages/simple.html.)
Use this utility to stop skipping when we reach either a closing or
opening block node tag. Previously we'd skip over such tags inside
nested "transparent" nodes (like <a>, <del>, or apparently <font>).
Bug: T271385
Change-Id: I201a942eb3a56335e84d94e150ec2c33f8b4f4e0
Remove unused error codes, update the ones that changed, and sort in
the order in which the types are listed on the schema page.
Bug: T272162
Change-Id: Ib16f7e11ff81d43443b08cf704ce5196420671e4
Don't assume a feature is available because the code has
loaded and the user option is set. Export the logic from
Hooks.php to the client.
Change-Id: Ica0e58de7ed0d59e3b09645193eb2b691ae41c39
If DiscussionToolsABTest is enabled (set to `all` or a feature), logged
in users who have never used the tool before will be assigned to an a/b
test bucket. If they're in the test bucket, they get the feature
enabled.
If they manually set their beta feature preference, we don't override
that but do maintain their bucket for logging purposes.
Bug: T268191
Change-Id: I9c4d60e9f9aaef11afa7f8661b9c49130dde3ffa
1. Extend the JS modifier to allow adding top-level comments
(that is, replies to headings). PHP modifier doesn't do this
because we'll save the changes using paction=addtopic instead.
2. Subclass CommentController to allow adding a new heading and a
top-level comment underneath it at the same time.
3. A lot of ugly code in ReplyWidget to customize the interface
for this case. Much of it should probably be moved to
CommentController/NewTopicController.
Bug: T267595
Change-Id: I9c707bb7f7aae1b92c72fb4dee436490f8c8409b
As a result of 0fc71f60cd, "empty" text
nodes (containing only whitespace) at the end of the comment may be
inside the comment's range, and trying to ignore them caused the
ranges not to match and the frame not to be detected.
Now the code works whether they're inside the comment's range or not.
Add a test case for wrapped discussion comments with HTML comments and
with whitespace.
Bug: T250126
Bug: T268407
Change-Id: I2217ff5a635fd1c9c9e803f46795b1bfb3d17535
Follow-up to d5a1b7bc2b.
The rule hiding the scrollbar was applied to the wrong element.
Bug: T267609
Change-Id: I596f29ba191032a82c579c63e9aa526eb4e887aa
The problem was fixed in 15cb419f56,
then the comment restored in 633cc9a7b3
(looks like a rebase mistake).
Change-Id: Ic31ea0bf88480cff02f40701f1317f35c1c6e891
While working on T270009, I noticed that <style> and <link> nodes
are treated differently, which seemed weird. Rewrite this again,
hopefully this is the last time.
The changed test cases also involve <area> and <input> nodes,
and the new results make more sense to me.
Bug: T264116
Change-Id: I3af90c84768a4b3dc53446927f4dba6f72175a2f
* Use a slightly different color
* Use 'mix-blend-mode: multiply' when available to avoid fading
the text color
* Add fade-in animation and make fade-out animation slower
Bug: T268994
Change-Id: I210ed4fd55c3dc184d13daf915fa93bee3699ad5
We've recently decided that we want to "extend" comments until
the end of the paragraph (e36dc8e78a,
d0ae6c4e44).
However, we still had this special case that did the opposite: it
ensured that if a comment ended in the middle of a text node, the
comment would not be extended to the end of the node. Remove it.
Note the change in the test file signatures-funny-formattedreply.html,
which actually covered this case specifically.
Change-Id: Id1384bb0c6e1a5f0c70f55efcb4caa240f230f07
The end marker is skipped forward until an open or close
block tag is reached. In tree traversal terms this means
moving either to the next sibling, or the parent (to skip
over close tags).
Bug: T256033
Change-Id: Iaa2c588698790d576ac4f9ecc126f58a082ef6b3
The general rule is that comments start after their preceding
thread item, but when that is a heading we should skip past
the entire <h[1-6]> node to avoid making section edit links
part of the first comment.
Bug: T267988
Change-Id: Ia7f1b27e0a69a9aab7c7da743bf8549479304096
Even though the field is supposed to resize itself to match the text
inside, vertical scrollbar would sometimes appear when the user has
zoomed in. Some calculation probably handles fractions of pixels
incorrectly (might be a bug in OOUI or a browser bug).
Since this field has no limit on max rows, we can just hide the
scrollbar. This can't be fixed in OOUI itself, since its autosize text
fields usually have a limit to how tall they are allowed to grow
before a scrollbar is used.
Bug: T267609
Change-Id: Id36ed417c4678e469a6c05715404e330064c2017
Matches what we end up posting. Leave context-aware code
commented out as this issue is not settled yet.
Change-Id: I7360e53d5d7823b2b52318005459212a21a6edc2
Ideally the edit autosummary would be generated in the same
way as in the old wikitext editor: from the wikitext of the
heading. But on the JS side, we don't have access to the
wikitext, or to the PHP method that generates autosummaries.
This might seem crazy at first, but ultimately the point of
the autosummaries is to link to the section heading by its
'id' attribute, so it is perfectly reliable.
Doing it this way depends on $wgFragmentMode being set to
[ 'html5', 'legacy' ] or [ 'html5' ], otherwise the escaped IDs
are super garbled (particularly in non-Latin-alphabet languages)
and can't be unescaped reliably. Conveniently, we already
require that since 9ee0fd69f5.
Bug: T264561
Bug: T266725
Change-Id: I7d35098d672d0edb50d49e22de1686d5cc83b60e
After recent changes allowing ThreadItems to have IDs, they can now
also have warnings about duplicate IDs.
Bug: T267035
Change-Id: If3edfe34e6e29741e29fac8946a3c88badc4ab7f
Also, stop the dialog-prevent-show event from switching editor_interface
just because it's tied to the `editor-switch` feature.
Bug: T259673
Change-Id: I2acf9d79add281ed0f62f022e44bb18948ceafc8
Use the same logic for marking ranges in the document, and ensure
that the heading range does not include section edit links or
section numberings.
Change-Id: I782caafc34fee2a822b0a17b24dd6b9528202eca
Skipping them could result in incorrect handling when RESTBase HTML is
outdated.
When a result for a given comment is not found, display an error
instead of assuming it is not transcluded.
Bug: T262065
Change-Id: I14a7a0a25d5181b5c49bd5677f0c002dce5a3cb9
We depended on the oldid (wgCurRevisionId) changing after a reply is
posted, but it will not change if we posted to a transcluded page.
Bug: T266275
Change-Id: I1baa1f2227134b73fd663de2fee3ea96a2f9b183
We avoided fixing these because it causes changes in just about all of
the test data, which is annoying when reviewing or blaming changes.
But the previous several commits also caused changes in just about all
of the test data, so we might as well do this too.
Change-Id: I83b64d83b6f12c04dc06c0cadff7cdd89417e137
To avoid old threads re-appearing on popular pages when someone
uses a vague title (e.g. dozens of threads titled "question" on
[[Wikipedia:Help desk]]: https://w.wiki/fbN), include the oldest
timestamp in the thread (i.e. date the thread was started) in the
heading ID.
Bug: T264478
Change-Id: If918bfd5e025248923d1939bc86916697ead95a0
Sequential numbers aren't great because they change when an earlier
comment is archived. Parent comment/heading IDs should change less
often.
This also makes much more sense for disambiguating subsections,
e.g. a dozen identical ===Votes=== sections for a dozen proposals.
Bug: T264478
Change-Id: I466454984fd919ebef35f2b37ddb5d86dc842996
Our threads now also contain all replies to their sub-threads.
This is similar to how sections work in MediaWiki, where the parent
section also contains the content of all the lower-level sections.
We're going to need this for notifications about replies in a thread.
Bug: T264478
Change-Id: I241fc58e2088a7555942824b0f184ed21e3a8b6f
Previously, only comments could have IDs, because we only needed IDs
for replying. But we might also use them for notifications soon.
Bug: T264478
Change-Id: I1bcad02bf17ab54bc5028a959543c10f0430836b
The output of CommentFormatter::addReplyLinks() and consequently
ThreadItem::jsonSerialize() can end up in the HTTP cache (Varnish) on
Wikimedia wikis. We need to consider that when changing that code.
Introduce a concept of legacy ID (generated by the older algorithm
after it changes), add some placeholder code that will generate them
in the future, and update some code to find comments by either normal
or legacy IDs.
Add dire comments in a bunch of places (as if that ever helps).
Bug: T264478
Change-Id: I4368f366800ab21b8b184b09378037614fdecd33
"This modifies the original objects…" – I feel like this is obvious
now, but maybe it wasn't so obvious when this code was structured
differently before a2431fe006. Also,
it refers to a variable that doesn't exist.
"FIXME this will clone the reply…" – No, actually, it will not.
It would if replies were associative arrays, but they are objects,
and have always been, ever since the PHP parser was merged in
7b7a2cd69c. Maybe they were arrays
once in Roan's mind before he pushed that for review.
Change-Id: I1348e111699fdbde99cd1f9ef45d8f465f7391b0
* Add the preference
* Only display it when the reply tool is enabled
* Use it when opening the reply tool
* Save it when the menu is toggled from the reply tool interface
Bug: T261539
Change-Id: Icb8fa6b3f1e9a3644669f21b08f34ea8c175f2f9
Always select the default reply if it looks unchanged, i.e.
we see '...*/ Reply' at the end of the summary.
Bug: T263062
Change-Id: I0a79d9e5072d9d9df16c93435502f67524e2d2bc
Through trial and error, I found that adding `display: inline-flex;`
avoids the issue, and does not seem to have any negative effects in
Chromium or other browsers.
Bug: T260072
Change-Id: I9a9ca1fdb57bb7dd6c1a0a70e330a2a503c8ec8e
When a timestamp directly followed a `<div>…</div>` tag (or perhaps
some other wrapper containing lots of content), we would detect the
username from the earliest links in the wrapper (furthest from the
timestamp), rather than the latest links (closest to the timestamp).
Bug: T262573
Change-Id: Id16449a86a731b13dc79846bb30ecf6554e26f1d
The wikitext parser outputs `<p><br></p>` for empty paragraphs, so we
need to ignore `<br>` tags when searching for an "interesting" node
that marks the beginning of a comment. Otherwise the empty paragraphs
mess up the detection of indentation levels.
Bug: T264116
Change-Id: I84a97ab577baa7336b78935ccdc48041ecfc231a
The same ReplyWidget instance can be re-used when the user cancels
replying and then starts replying again to the same comment.
Previously, the initial values passed to the constructor (when switching
modes) would still persist in this case, even if they were incorrect.
Bug: T263061
Change-Id: I3dff007456bfd4f3149c718ae72fbf373a2e2913
* Export parser data (date format, digits, timezone names, and
messages for weekday/month names) converted to language variants
* Update the parsers to try matching using every variant, in case
the page is displayed in non-default variant (and to avoid
problems with incomplete variant conversion)
Bug: T259818
Change-Id: I04d73992cd31ce06fa79f87df0c0a53d7efc3c58
Now consistently uses setReadOnly instead of setDisabled.
Slight styling regression was fixed in I01e11c2ed.
Change-Id: Ice7ce00929ff9a53d0fb533f1094e7324749f3a4
PHP was counting UTF-8 bytes, JS was counting UTF-16 bytes.
Both should have been counting codepoints (although it doesn't
really matter as long as they both count the same things).
I noticed the issue after adding some tests using the Cyrillic
script, when one case had different results in PHP and JS:
Id25b537fecd789640c209ff7f30e777455a3aece.
Change-Id: Ic31240678f71ba48e6ec202126bf490cea12bb66
Move the code so that we check for "?title=" query parameter first,
because we don't handle this right in the other code path.
Use parse_url() instead of wfParseUrl() because the latter doesn't
accept relative URLs, and we don't care about the other differences.
Bug: T261711
Depends-On: I4da952876e1c3d1a41d06b51f7e26015ff5e34d7
Change-Id: I70fac2b41befd782b0a47a4f726ae748dc0f775d
The PHP code incorrectly assumed that the digits are single-byte in
UTF-8, which is never the case (except for 0-9).
The JS code worked correctly because it uses UTF-16 strings, so the
bug would only affect non-BMP digits there. This was noted in a TODO
comment, but we overlooked it when reimplementing in PHP.
Instead of a string of 10 characters, use an array of 10
single-character strings.
Bug: T261706
Change-Id: Ic5421382474c88f003424799c53ff473d99cce92
Without this, the reply widget would be inserted before the reply button,
in the middle of the paragraph.
Follow-up to e36dc8e78a.
Change-Id: I5e22a0a0b70e8da395eb23dd6ae80af70840a2e2
This got lost when the watchlist updating code was refactored
out into controller.js, as it assumes that 'data' (the post data)
is still available.
Bug: T261362
Change-Id: Id274e7b8518b62dddbc3d4095d9f6cab17aa17cd
When a comment ended before the end of a paragraph, the next
comment would begin right there in the middle of the paragraph.
This could result in the detected indentation level of that
comment being incorrect, and replies being inserted in wrong
places, as seen in the 'signatures-funny' test case.
The code moved to the parser was previously repeated twice in
addListItem() and addReplyLink(), which should have been a hint
that something isn't quite right.
Also, fix the code guarding against overlapping signatures,
now that signatures may not be at the end of a comment.
Bug: T260855
Change-Id: Ic26a87642f8a15d5de2f7073d4d8176b299c7f94
We were accidentally resolving the promise with `undefined`, rather
than rejecting it. This later caused "TypeError: Cannot read property
'linterrors' of undefined" in controller#checkCommentOnPage.
Bug: T260294
Change-Id: I29418988023d86140cfa110c0c348059b293a716
Causes page corruption, in a new way we haven't seen before.
* Revert "Move page updating logic to controller.js"
This reverts commit 54fdc6de06.
* Revert "ReplyWidget: Move clear methods from #teardown to #clear"
This reverts commit 9b811a94e0.
* Revert "ApiDiscussionToolsEdit: Do not pass 'basetimestamp'"
This reverts commit 7de5938a6f.
* Revert "Use DOMCompat::getOuterHTML instead of doc->saveHTML()"
This reverts commit 7b2448d2f0.
* Revert "CommentController: Remove remains of client-side edit conflict handling"
This reverts commit 2d038af705.
* Revert "Restore error message for when comment is deleted while replying"
This reverts commit 655c0526d6.
* Revert "Use transcluded from API to avoid ever fetching Parsoid DOM in client"
This reverts commit 9d0fc184fe.
* Revert "Create a 'transcludedfrom' API endpoint"
This reverts commit 5d8f3b9051.
* Revert "Edit API for replies"
This reverts commit 8829a1a412.
Bug: T259855
Change-Id: I6419408c6194ec0afa6b8ee604b12c1a24c6ac7b
Previously, parser would output offsets that don't exist in their
containers, because we were pretending that entities are parts of
their neighboring text nodes.
Turns out it's much easier to do it right when going backwards.
Change-Id: I9bccca2d403f1a976ae517449989170cdd99721e
In commit 8829a1a412 we kept this code
when adding the reply API, but on second thought it doesn't actually
make sense.
The reply API should never fail with an edit conflict normally, since
it makes the edit on the latest version of the page. If it does fail,
I think it's better to just show the error message. Current behavior
is to retry, and if that doesn't actually solve the problem, this ends
up in an infinite loop.
Bug: T252558
Change-Id: I5e0dcb2c42e5de4f18e99b8a761ca048a430b31e
The footer was already laid out using flexbox and just required some
CSS tweaks to enable wrapping.
The header required some DOM changes, now also uses flexbox, and wraps
in a similar manner.
Bug: T259320
Change-Id: I6f6a86932a108037bf1d70f077c372654318be26
This reverts commit 96953647c3.
* Re-apply "Edit API for replies"
This applies commit 8829a1a412.
* Re-apply "Create a 'transcludedfrom' API endpoint"
This applies commit 5d8f3b9051.
* Re-apply "Use transcluded from API to avoid ever fetching Parsoid DOM in client"
This applies commit 9d0fc184fe.
* Re-apply "Restore error message for when comment is deleted while replying"
This applies commit 655c0526d6.
Change-Id: Id20d21899f87464636022aa0683f8c03e0060117
Causes page corruption.
* Revert "Restore error message for when comment is deleted while replying"
This reverts commit 655c0526d6.
* Revert "Use transcluded from API to avoid ever fetching Parsoid DOM in client"
This reverts commit 9d0fc184fe.
* Revert "Create a 'transcludedfrom' API endpoint"
This reverts commit 5d8f3b9051.
* Revert "Edit API for replies"
This reverts commit 8829a1a412.
Bug: T259855
Change-Id: I98036f14dd900b51f20e98696e31b9b618eceee1
When adding a reply, we take a node at the end of the previous comment,
compare that comment's indentation level to the expected indentation level
of the reply, and add (or remove) that number of wrapper lists.
The existing code did not consider that comments may have lists within
them, and so the indentation of that node may not match the indentation
of the comment.
Bug: T252702
Change-Id: Icc5ff19783d2b213bff99f283cb0599a8b5c1ab4
Previously we preferred that, but used '*' (<ul><li>) when the parent
comment or the previous reply also used it.
Bug: T252708
Change-Id: I3abf606da6693905764f1be745fad999fdf57fbe
* Remove the existing approach for detecting signatures that only
worked in source mode; remove autoSignWikitext()
* Use the same approach for auto-signing in source mode as we have
already used in visual
* In both modes, detect whether the user has already typed a signature
at the end of their comment in the modifier, and if so, don't add a
signature
* Add test cases for the detection
Bug: T255738
Change-Id: I791d3035cb1ffc33ce3966d4617a25d08700c35b
* 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 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
Separate out conversion to DOM nodes, and update
now that postReply doesn't need to return a promise.
Change-Id: Iab6192ba252244009d2374c9423d14279e8d1c4f
This is helpful when you ping the wrong person and need to correct your input.
Logically depends on I4c34e9368692b0ee4e7ca0f18ba2940406c62a9a
Change-Id: Iea89bdb5d93fe64902b692f04dd3a2e84e5517c3
* Run the 'wikipage.content' hook before our initialization.
This way collapsible elements and other changes to the page layout
are processed before we measure where the new reply is and try to
highlight and scroll it into view. (T252903)
* Remove the code dealing with 'mw-parser-output' and 'dt-init-done'.
This was needed to avoid initializing twice on the same element,
which can't happen now. (T254807)
This is much closer to the original approach Ed proposed in
I05a3c766668999f05cfe06473652429025595196 before I changed it:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/550693/7..8
Bug: T252903
Bug: T254807
Change-Id: Ibc3fcbd3c92c8eceda19b68cee9e69f6e92456f5
The automatic event from core didn't catch this, because it's not an action
method called "open".
Bug: T255638
Change-Id: Ifa456e850a8edb374df098e21b46bb872416ae55
Parsoid doesn't understand syntax expanded during pre-save transform,
e.g. [[User:Foo|]] or ~~~~, and it gets nowikied when switching back.
Change-Id: I791426d9d6c0a1399b1e95039b11e43a3e5bf79f
Current code breaks in other languages which don't use whitespace as a
word separator. The word-separator message is (for reasons) not reliably
set to something other than " " on wikis for those languages, so we
can't use it as a trigger for just not caring.
Bug: T255153
Change-Id: I1ff929811af59fd7a7bf7e8dfc1cd121a2c4db4e
This was removed upstream due to a regression.
We don't need it right now, but may need it in the future to
support editing, so replace with a TODO.
Change-Id: Ia73657080241319df309f3b6566ac0ac36a5909d
* Track editor mode switching between visual and source (plain)
* Track interactions with checkboxes
* Fix the tracking of firstChange when switching with content
Bug: T254291
Change-Id: I0e243e393b02952684f34dbbe1697633c0b2561a
Any template that outputs wikitext spanning more than one line
will break. As we can't enforce that in VE, we should just disable
all templates for now. The can still be inserted in source mode,
and will be eventually supported when we have multi-line syntax.
Bug: T253667
Change-Id: I72a7e4c09f83bcfc2a9cc7ab33a3d5303ced851d
* Move modifier#getFullyCoveredWrapper to utils
* Use that method to find the node where we start searching for
template wrappers, rather than using endContainer
Bug: T252058
Change-Id: I55de58102f3468fce01290bd413a7fdc96d322d6
I was wondering if the different approach to childIndexOf()
implemented in PHP in b8d7a75c34 would
be faster in JS as well, and yes, it is.
Our test suite now takes (on my machine):
* Chrome: 8337 ms → 7355 ms (average over 5 tries)
* Firefox: 5321 ms → 5044 ms (average over 5 tries)
Change-Id: I71963eeb92dcea9bfd59cbf01a7aa0b7de5d9cf1
When there is a wrapper element whose range matches the range of
a comment, any replies will now be added outside of that wrapper,
instead of directly after the comment (inside the wrapper).
Bug: T250126
Change-Id: I6b42c4db019ae998e91eebd324f9cbd2aa791b4f
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
Ensures that MW target sets the correct dir and lang on the document.
We should consider upstreaming this.
Bug: T253258
Change-Id: Ibc9ae7b4b105055291c941ce932f499bd6e13657
It was useful when I was debugging those parts of the code, but now
it's usually annoying.
The warnings can still sometimes be useful for understanding how the
tool parses some discussion, though. To keep that functionality, add
displaying warnings for each comment in the debug mode.
Change-Id: I2d218a8a394f179bcc0990ff988a0567c275ccf2
Follow-up to Ic1438d516e223db462cb227f6668e856672f538c.
Minor corrections and comment improvements in PHP parser,
and "backporting" some changes to JS parser that I like.
Change-Id: I5e54121914ec6b323e556dd133bcb71b3aefbb61
This method shouldn't be required on the server. Leave comments
relating to it in addListItem so JS & PHP can be kept in sync.
Change-Id: I849fac660faf6e750272c20776f96b9250f96b1b
It appears PHP's DOM library always uses CDATA nodes for the contents of
<style> tags, even if there is no such markup in the source HTML.
Change-Id: Id04b27086c5e7a0b016a3a440b2b4895d6b13c93
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
We used to rely on this happening in onInputChange but
that listener is now detached.
Bug: T252176
Change-Id: I6654d68dc6107cd78172c455db9cba6cb9eabddf
This allows the unload handler to trigger on these links.
Depends-On: If52aa9d619eac08456874fc75c0f6e1adff01246
Bug: T244942
Change-Id: I9904e8af4a60b0f5e9a6e263cd4fd8e1e3fd1f98
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
In the future, we should think about a better solution that also
handles other elements (T250126), but this is an easy fix for now.
Bug: T250512
Change-Id: I1321f0da523ddb4a999b8c453b9094a267b38ae2
When the user clicks a "Reply" link on a page that is affected by the
'fostered' lint error (indicating fostered content in the HTML
representation), display an error and refuse to edit it, as Parsoid's
transformations will damage the page content.
The error message includes a link to documentation about lint errors,
and a link to the editor that will highlight the error location.
Depends-On: I723ec766d1244d117f8d624440026fe5af0d3403
Bug: T246481
Change-Id: Ic60cb58f98d10dc9b113469e5d3bbfb2d2b0564f
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
3 or 5 tilde signatures will be assumed to be erroneous and fixed
to 4 tilde signatures. This will be visible in the preview so shouldn't
come as a suprise to users.
Bug: T245628
Change-Id: I741f0761a6fb10c99cf3239ac5c6c7e1a2b872c7
The section wrappers can be marked as template-affected when the
previous or next section is transcluded, causing comments to be
unnecessarily uneditable. The new test case demonstrates this.
Depends-On: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
Change-Id: I895a04990d79a3475d778b4fef054ea0bb076f0b
* 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
It's more convenient for display or comparing it with other things.
Depends-On: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
Change-Id: I88d7aa68977210b16860075ed52983a5e99ee0f7
The rejection handling callback was accidentally resolving the
promise, which resulted in an error like 'TypeError: Cannot read
property '$element' of undefined' when the resolution value was
used.
Fixing this reveals that we weren't removing the placeholder list
element correctly. This wasn't immediately visible because of the
.empty() call in the next resolution callback, but it would have
caused something similar to T245574.
Follow-up to 6964f0c965.
Change-Id: I3aeb9a86046c4ccaa6c39301edc7285d02b0320c
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
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
Sets the placeholder text to "Reply to <user>".
Bug: T245227
Depends-On: I7f3a58b7093d00aace9f9c6a95a121ba4e901ad8
Change-Id: Ie51f1848c17bb892e7f64adf6f7f19fc38e56202
