Commit graph

442 commits

Author SHA1 Message Date
Bartosz Dziewoński e5e6fdd3af Stop using native Range objects, they're too annoying
Native Range objects are automatically updated when the DOM elements
they refer to are affected (e.g. detached from the DOM, or their offset
changes because of siblings being added/removed).

This seemed harmless or maybe even slightly useful, but it turns out
it conflicts with VisualEditor, which has to wrap the entire page in a
new DOM node when it opens (and unwrap it when it closes), effectively
temporarily detaching it from the DOM, which destroys all our ranges.

Just use a plain object that stores the same data as a Range. And when
we need to use Range's API, we can simply construct a temporary one.

Bug: T241861
Change-Id: Iee64aa3d667877265ef8a59293c202e6478d7fb6
2020-02-05 19:42:03 +01:00
Translation updater bot b84bfec3d4 Localisation updates from https://translatewiki.net.
Change-Id: Id0ea210f9d755a0203e939c603d0b035e52b2c7f
2020-02-05 08:18:49 +01:00
Bartosz Dziewoński 44eb801844 Add config option and query parameter to control loading
By default, DiscussionTools loads on all talk pages when the extension
is installed. This can now be disabled by setting the configuration
option `$wgDiscussionToolsEnable=false`.

To test DiscussionTools, one can now use the query parameter
`?dtenable=1`, which allows it to be loaded on any wikitext page
(overriding the config option).

Bug: T243621
Change-Id: I3d5a9cc9a4183fb6951f05c557b1d42735a9df7c
2020-02-04 22:06:13 +01:00
David Lynch 664b2890d7 Tag DiscussionTools edits
This sets up the tags:
* discussiontools
* discussiontools-reply
* discussiontools-edit (not yet implemented)
* discussiontools-newsection (not yet implemented)

The tags are flagged as user-addable, because otherwise they can't be
passed through to the VE API (at least, not without editing it so that
it explicitly knows about them, which seems like a strange
interdependency). It's assumed that letting users who know about the
tags add them to random changes via action=editchangetags would be
(a) the pettiest and most inconsequential vandalism possible, and
(b) unlikely to happen.

This relies upon I2c1d0f8d69bc03e5c1877c790247e165f160e966 in
VisualEditor to not also tag the edits with `visualeditor`.

Bug: T242184
Change-Id: I4e5e26afdd52279df242e1912f073b415b812c3b
2020-02-04 11:15:18 -06:00
Translation updater bot e9e1e8d112 Localisation updates from https://translatewiki.net.
Change-Id: I56af1277158328b998f6c44d4e277dbf47a61008
2020-02-03 08:26:39 +01:00
jenkins-bot 601226199d Merge "Handle comments before first section heading" 2020-01-30 23:19:29 +00:00
Bartosz Dziewoński e29b8173bf Handle comments before first section heading
The loop in parser.js assumed that there was always a heading before
any comments (not counting the page title, only section headings).

Bug: T243869
Change-Id: I3a0bb06716e75d4a17e25c40748673a071ee5f30
2020-01-30 00:14:46 -08:00
jenkins-bot f735e47fdd Merge "Attach highlights to positioned container" 2020-01-30 00:07:04 +00:00
jenkins-bot 3b4ae40658 Merge "Don't use RangeFix for node rects" 2020-01-30 00:02:49 +00:00
Ed Sanders 4b3d92a5e9 Attach highlights to positioned container
Bug: T240639
Change-Id: I41a547acd3e5d7e9a49f99fc5ef35738d038007e
2020-01-29 15:22:20 -08:00
Ed Sanders 087d1eb428 Don't use RangeFix for node rects
Change-Id: I60e45ee9288fbdad26bb85997a7b4a24234fa8b4
2020-01-29 15:22:19 -08:00
jenkins-bot 95a663ff62 Merge "ReplyWidget: Handle save errors" 2020-01-29 20:51:50 +00:00
libraryupgrader ad39e6e9b7 build: Updating mediawiki/minus-x to 1.0.0
Change-Id: I8c174820508a97da3282fcb5d67be897af58cab9
2020-01-29 03:41:40 +00:00
Ed Sanders 7de6b4e04a Use simple targetSaver API call
Depends-On: Ida47968c995166b1dca36fc9fe28fac374010564
Change-Id: Id3decabb803a65d79cb09668bde4e0b498ad057c
2020-01-24 15:45:43 -08:00
Bartosz Dziewoński 890588f36a Pick reply insertion point based on parser tree, not DOM tree
I don't like that I had to special-case `<p>` tags (top-level
comments) in this code. I feel like it should be possible to handle
top-level comments and replies in a generic way, but I couldn't find
a way to do it that actually worked.

Notes about changes to the behavior, based on the test cases:

* Given a top-level comment A, if there was a "list gap" in the
  replies to it: previously new replies would be incorrectly added at
  the location of the gap; now they are added after the last reply.
  (T242822)

  Example: "pl", comment at "08:23, 29 wrz 2018 (CEST)"

* Given a top-level comment A and a reply to it B that skips an
  indentation level: previously new replies to A would be added with
  the same indentation level as B; now they are added with the
  indentation level of A plus one. (The old behavior wasn't a bug, and
  this is an accidental effect of other changes, but it seems okay.)

  Example: "pl", comment at "03:22, 30 wrz 2018 (CEST)"
    and reply at "09:43, 30 wrz 2018 (CEST)"

* Given a top-level comment A, a reply to it B, and a following
  top-level comment C that starts at the same indentation level as B:
  previously new replies to A would be incorrectly added in the middle
  of the comment C, due to the DOM list structure; now they are added
  before C. (T241391)

  (It seems that comment C was supposed to be a multi-line reply that
  was wrongly indented. Unfortunately we have no way to distinguish
  this case from a top-level multi-line comment that just happens to
  start with a bullet list.)

  Example: "pl", comments at "03:36, 24 paź 2018 (CEST)",
    "08:35, 24 paź 2018 (CEST)", "17:14, 24 paź 2018 (CEST)"

* In the "en" example, there are some other changes where funnily
  nested tags result in slightly different results with the new code.
  They don't look important.

* In rare cases, we must split an existing list to add a reply in the
  right place. (Basically add `</ul>` before the reply and `<ul>`
  after, but it's a bit awkward in DOM terms.)

  Example: split-list.html, comment "aaa"; also split-list2.html
    (which is the result of saving the previous reply), comment "aaa"

* The modifier can no longer generate DOM that is invalid HTML, fixing
  a FIXME in modifier.test.js (or at least, it doesn't happen in these
  test cases any more).

Bug: T241391
Bug: T242822
Change-Id: I2a70db01e9a8916c5636bc59ea8490166966d5ec
2020-01-23 21:13:12 +01:00
Bartosz Dziewoński 30fcfec1fd parser: Merge multiple comments on one line
Even when you have multiple signatures by multiple users in one
paragraph (or list item), it's still basically a single comment.
We don't want to offer multiple buttons to reply to it.

The changed parser test cases are illustrative:
* All affected comments in the "pl" example are comments with a
  "post-scriptum", which is now more intuitively treated as part of
  the main comment.
* The first comment in the "en" example would probably have been
  better if it wasn't merged, but a weird use of the outdent template
  causes us to not be able to distinguish that the two parts of the
  comment display on separate lines.
* The last comment in the "en" example (isn't that neat?) was previously
  incorrectly treated as two comments, because there's a timestamp in
  the middle of it (the user is referring to another comment).
* Remaining affected comments in the "en" example are also comments
  with a "post-scriptum" and their treatment is clearly better now.

It also accidentally fixes some problems with modifier tests (but not
all), where previously <dl> nodes would be inserted in the middle of
<p> nodes, to reply to the comments which are now merged.

Bug: T240640
Change-Id: I0f2d9238aff75d78286250affd323cd145661a11
2020-01-22 02:21:43 +01:00
Bartosz Dziewoński da732843f3 Integration tests for the modifier
Document the current behavior of the modifier (which inserts the
replies into the DOM tree), so that we can more easily see the effect
of changes in I2a70db01e9a8916c5636bc59ea8490166966d5ec.

Basically, add a reply to every comment, and dump the resulting HTML,
comparing it to previously generated expected HTML (which can be
checked visually). Have a look at the new HTML files.

Notably, the very first section in the "pl" example demonstrates a
case of wrong reply location due to list gap :) (T242822).

Change-Id: I4aed0f0b112f53d98e3fe1da4d40db8687c7e537
2020-01-22 00:58:06 +01:00
Bartosz Dziewoński 6d243ed74a ReplyWidget: Handle save errors
Bug: T240519
Depends-On: Ie18666b41f4aff1ab4bcf93f9df6e3000ac7b500
Depends-On: I2a731cb273401074e65f9283c1f629dbdb272002
Change-Id: Ice92fafb1f546510dab28e3f8aa7d2280668965a
2020-01-21 22:21:57 +01:00
Ed Sanders e83af3a4e9 Allow plain reply widget to grow without limit
Matches the behaviour of the VE widget.

Change-Id: If6540c4e91566da878c95b40e98ebe5f996125ce
2020-01-21 19:30:34 +00:00
Translation updater bot 0a88c0fbba Localisation updates from https://translatewiki.net.
Change-Id: I0b8b0376edccbfd3878b8283a737504ccfdb8c76
2020-01-21 08:16:04 +01:00
Umherirrender 328e97ac11 build: Add phan-taint-check-plugin version
job is already set up

Change-Id: I5bcafa72323e952223bb54d7f99bb2775342412e
2020-01-17 18:13:25 +01:00
Ed Sanders fe48688a76 Teardown the widget as soon as possible
Bug: T241393
Change-Id: I5978133637844fcad81af426465b6f16829ee9b3
2020-01-15 16:21:59 +00:00
jenkins-bot 59bfd520f6 Merge "Call Maintenance::requireExtension" 2020-01-15 09:01:23 +00:00
jenkins-bot d6874dcbab Merge "Fix <escape> handler again" 2020-01-14 15:42:17 +00:00
Ed Sanders cc5976e8db Fix <escape> handler again
Sepatate #teardown and #tryTeardown methods to make it
obvious what they do. Have <escape> call #tryTeardown
like the cancel button.

Change-Id: Ica0f3295bfee378bcd15d0b6a3ccea3c7917ad9b
2020-01-14 15:01:49 +00:00
libraryupgrader 7bb23482bd build: Updating mediawiki/mediawiki-codesniffer to 29.0.0
Additional changes:
* Use json file extension for the stylelint config file.

Change-Id: Idca900cd65b88692ad43d34af7a9af4c4cfb9fcc
2020-01-14 04:55:38 +00:00
Umherirrender fdd52762ee Call Maintenance::requireExtension
This avoids that the script is executed without the extension is
installed.
This avoids than an error when class is missing

Change-Id: I064d2be5dbaa3b43c8134e19694511398decba88
2020-01-13 22:15:43 +01:00
Umherirrender 1c05fa9049 build: Add missing .phpcs.xml and make pass
Add .phpcs.xml to run codesniffer against the extension.
The entry in composer.json is already there

Change-Id: If9de7e9b1b9439dc4d5fa2ba521883d13deaa739
2020-01-13 20:48:11 +01:00
Umherirrender f08c1ebc29 build: Add MinusX
MinusX will test for executable bits

Also add php-console-highlighter

Change-Id: I26929198357e032d70b4801c5e548278e7376fa9
2020-01-11 22:27:35 +01:00
jenkins-bot ad48d8d2f9 Merge "Option to integrate VisualEditor instead of textarea" 2020-01-09 18:08:18 +00:00
libraryupgrader 2919c2b613 build: Updating npm dependencies
* stylelint-config-wikimedia: 0.7.0 → 0.8.0
* grunt-stylelint: 0.12.0 → 0.13.0

Additional changes:
* And updating CoC link to use Special:MyLanguage (T202047).
* Set `private: true` in package.json.
* Set `root: true` in .eslintrc.json (T206485).
* Added .eslintcache to .gitignore.
* Removing manual reportUnusedDisableDirectives for eslint.

Change-Id: I18a1f384d62d71ed40be67f20000a03cb741a7d0
2020-01-09 06:43:15 +00:00
jenkins-bot 719bfee1b3 Merge "ReplyWidget: Load modules required by the content when previewing" 2020-01-08 23:28:21 +00:00
jenkins-bot 45e811a688 Merge "ReplyWidget: Pass 'title' when previewing" 2020-01-08 23:28:20 +00:00
jenkins-bot 88a467ec16 Merge "Fix re-initialization after page is updated" 2020-01-08 23:28:19 +00:00
jenkins-bot 8282cefb68 Merge "Fix crash when opening VisualEditor NWE while DiscussionTools enabled" 2020-01-08 23:28:18 +00:00
Ed Sanders 2f1cf65233 Option to integrate VisualEditor instead of textarea
* 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
2020-01-07 22:15:03 +00:00
Ed Sanders c03cfde566 Fix 'escape' to teardown
Change-Id: Icc35ed83a1fa46ed592f617d0ff5dd60361c412d
2020-01-07 22:13:50 +00:00
Bartosz Dziewoński 25eb55000f Fix re-initialization after page is updated
I did this wrong in a6147ffac8, the
'dt-init-done' class was never cleared. Put it on another element.

Bug: T241861
Change-Id: I136bd9c12bcc80cff01f5d26a8a53524f0c533c6
2020-01-04 18:49:55 +01:00
Bartosz Dziewoński 0de5591889 ReplyWidget: Load modules required by the content when previewing
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
2020-01-02 16:00:03 +01:00
Bartosz Dziewoński d7aded339c Fix crash when opening VisualEditor NWE while DiscussionTools enabled
The hook 'wikipage.content' fires whenever new "page content" is added
dynamically (e.g. after a VisualEditor edit). It's used by the code
for sortable tables, collapsible content, etc., to ensure they behave
correctly after the page content is changed without reloading the page.

We use this hook to add our "Reply" links. However, VisualEditor (and
NWE) also fires this hook for the contents of the edit notices box (to
support collapsible boxes there: T179315). Our code was crashing
because it could not find talk page content inside of that, and this
crashed VisualEditor as well.

Use .each() to handle any number of results (0, 1 or more), instead of
assuming there is always 1.

Bug: T241396
Change-Id: I877b1ae06bf1d7cd585ec6f9c1fb596cc3b86e7e
2020-01-02 14:44:18 +00:00
Translation updater bot 69f440c6bf Localisation updates from https://translatewiki.net.
Change-Id: If4101754bf23bd0ed0898957c1ddc00fcf57e611
2019-12-29 20:40:26 +01:00
Bartosz Dziewoński e9b1037ec6 ReplyWidget: Pass 'title' when previewing
Bug: T241221
Change-Id: Ibabc32c9e5aeec6acec3bab9ad67d6ba3c4f27e8
2019-12-27 19:30:24 +01:00
Translation updater bot ed553b2917 Localisation updates from https://translatewiki.net.
Change-Id: I23c559d5a336c5614eb147230c9d713d7d5d6eba
2019-12-24 10:01:51 +01:00
Translation updater bot 3537be6e83 Localisation updates from https://translatewiki.net.
Change-Id: Ia8158b4ef5ba15053af8436464e9dfe84ea80f67
2019-12-22 17:40:33 +01:00
Translation updater bot 1d9b67e63c Localisation updates from https://translatewiki.net.
Change-Id: I935e574fa939b11ce05f47dafbe96157aeb1ac7c
2019-12-19 09:14:33 +01:00
Translation updater bot f5e6310e5f Localisation updates from https://translatewiki.net.
Change-Id: I6dc2baca2ebb92b1d4f4d18be4639af78f8cab40
2019-12-18 09:25:15 +01:00
Translation updater bot 910031601d Localisation updates from https://translatewiki.net.
Change-Id: Id271111ffb53ff14d08937159096b72e1f56ff87
2019-12-17 10:07:12 +01:00
Translation updater bot d015132fd4 Localisation updates from https://translatewiki.net.
Change-Id: Ie19dcbe56608a7a0dbb609e352db5d2c3d7c45fe
2019-12-16 12:13:10 +01:00
David Lynch 5eea2d42fb ReplyWidget: calling undefined clear method
Caused by 49edbb82ab.

Bug: T240729
Change-Id: I23bf7fcb7e0265f9770629590702a07a3dbed2b1
2019-12-13 16:49:10 -06:00
jenkins-bot 2680307b37 Merge "Prompt users when pressing 'cancel' with content in the widget" 2019-12-13 19:00:41 +00:00