Commit graph

1015 commits

Author SHA1 Message Date
Ed Sanders 5f966e845b Remove vertical padding from VE visual target
Compensates for vertical padding on paragraphs.

Match source mode padding to that of a TextInputWidget.

Change-Id: Ia53d8d2a6b9eff464c6c61152d02250088049bf9
2020-02-18 15:53:45 +00:00
Ed Sanders 97cf4e8440 Blacklist/convert tables and headings in VE target
Change-Id: I5e58fb1da1cb793bad5fb9640ef2dbf14c96d082
2020-02-18 15:44:40 +00:00
Ed Sanders 1a93e420b3 Sig preview: Increase opacity
Closer matches disabled-grey which is more accessible.

Change-Id: Ieb98e88bb42fdec1f1089919cf2c0c5f72b21877
2020-02-18 15:43:06 +00:00
Translation updater bot 219da72031 Localisation updates from https://translatewiki.net.
Change-Id: Ied7ec18808ee655163d66c8411e26f33778a78e4
2020-02-18 08:25:04 +01:00
Translation updater bot b3c04bcc15 Localisation updates from https://translatewiki.net.
Change-Id: I66483327ab836ff31ed50f31379fcfe413ea69c5
2020-02-17 08:46:09 +01:00
Bartosz Dziewoński 7ea6cdf326 Try to resolve edit conflicts
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
2020-02-15 05:43:14 +01:00
Bartosz Dziewoński 6f404e5ce2 Rebuild Parsoid document before attempting to save
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
2020-02-15 05:09:34 +01:00
Bartosz Dziewoński 80cddf549c Use built-in mw.Api 'badtoken' handling, also 'assert'/'assertuser'
This ensures that expired tokens are refreshed and retried, while
invalid tokens caused by the user logging in/out cause an error. We
should think about displaying a better interface for the latter case.

Bug: T245327
Depends-On: I485f99e1f5f493262b0c9af22370da01adf1e09c
Change-Id: Ibc097ed68e3ae72223b0680ee8895f7884399958
2020-02-15 03:07:02 +01:00
Translation updater bot 390ab1972f Localisation updates from https://translatewiki.net.
Change-Id: I51441f5b823476f98e43995da73b5849d36de4dc
2020-02-14 08:25:36 +01:00
Translation updater bot e03345caa2 Localisation updates from https://translatewiki.net.
Change-Id: I95d74da7e75b964fced26f94a92309199700a39f
2020-02-13 08:54:42 +01:00
jenkins-bot f0fe7e68c2 Merge "Improve comment ruler drawing in debug mode when indentation is weird" 2020-02-12 23:57:24 +00:00
jenkins-bot 7d86d1b24a Merge "Rename the lines denoting child comments in debug mode to "rulers"" 2020-02-12 23:57:24 +00:00
Translation updater bot 74bab12a86 Localisation updates from https://translatewiki.net.
Change-Id: I26b87e073f138a80ecfe72e8e1bb8e0258ab5efd
2020-02-12 08:21:33 +01:00
Translation updater bot c32c84f241 Localisation updates from https://translatewiki.net.
Change-Id: I0219d242bfe6b0ec4f8536af241bee5483be34c0
2020-02-11 08:19:12 +01:00
Bartosz Dziewoński 3896babde3 Improve comment ruler drawing in debug mode when indentation is weird
Ignore the horizontal position of the comments' bounding boxes entirely.
It can be crazy because of de-indentation in the middle of the comment,
and even just text formatting with padding/margins (e.g. `<code>`) can
make it look weird. Just draw the rulers based on detected indentation.

Change-Id: Id4e5edf076d44bdedfb45958260d797daea29ed1
2020-02-11 02:32:32 +01:00
Bartosz Dziewoński a491e3aaac Rename the lines denoting child comments in debug mode to "rulers"
I got tired of typing "relationship".

Change-Id: I318bdd1c049d7ab7fdeb1512a083cf8f4121d598
2020-02-10 22:14:38 +01:00
Translation updater bot 76ff5d1114 Localisation updates from https://translatewiki.net.
Change-Id: Ia5da4fe99eb1b5f14d85ebab6dec00fe294d1e71
2020-02-10 08:33:30 +01:00
Ed Sanders c8564f6ccb Re-style preview
Bug: T238177
Change-Id: Iabc7cfa7595d60cbd0482340bd159002ee5a6b0e
2020-02-08 00:13:41 +00:00
jenkins-bot b80f7ee82e Merge "Change tags method so anon edits will get tagged" 2020-02-07 09:09:38 +00:00
Translation updater bot cbd6aad04f Localisation updates from https://translatewiki.net.
Change-Id: I317d5ace634002cd726550194363ccac34737254
2020-02-07 09:57:17 +01:00
David Lynch 16215bbea2 Change tags method so anon edits will get tagged
Bug: T242184
Change-Id: I38baddc0febe02f6d2321be616adc018c87b5a54
2020-02-07 01:19:11 -06:00
David Lynch 2fcc23ae61 Add editor-mode changetags
Bug: T242184
Change-Id: Ib307e44ec883b01e0705c889f97e16326519f4c2
2020-02-06 20:22:27 +01:00
Translation updater bot 0f67d1862e Localisation updates from https://translatewiki.net.
Change-Id: I98b7c1057bf956a55cc1faba0d964e0aec28af14
2020-02-06 08:19:13 +01:00
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