* Detect comment separators at the end of comments too
* Consider TemplateStyles associated with ignored templates
This unexpectedly improves a lot of cases other than T313097 too,
mostly where <br> or {{outdent}} was used within a paragraph:
splitting comments that were previously jumbled together, or restoring
content that was previously ignored for apps / notifications.
Bug: T313097
Change-Id: I9b2ef6b760f2ffd97141ad7000f70919aeab7803
ApiDiscussionToolsPageInfo and ApiDiscussionToolsCompare in direct parsoid
or VRS modes tries to fetch HTML using VisualEditor thus stashing the
HTML gotten which we don't want, we only need it for viewing in these cases.
This seems like something that was/is already happening in RESTBase. So for
APIs in DiscussionTools that need the HTML for viewing, just get it from
parser cache and not stash it.
Bug: T323357
Change-Id: I101c1e84739a2ac1f562f2f7bdc4b8f53d9f3b23
When a comment almost exactly matches the range of an
accidental complex transclusion consisting only of
pages from the 'Template' namespace and wikitext fragments,
I think we can safely allow replying to the comment.
Even if this turns out to be incorrect in some cases,
the failure will be more graceful after the changes in T313100:
instead of potentially duplicating contents from a template,
the worst case now is that the reply will appear in the wrong
place (at the end of the transclusion).
Bug: T313093
Change-Id: Ie8da09d74a652d893fd8c3e2435ef6cb70fad64a
We wrap a `<div>` tag around the `<h2>`, and move some elements there.
The markup is inspired by and compatible with my proposal for T13555.
The "ext-discussiontools-init-section" class is moved to the `<div>`.
A small patch is needed in MobileFrontend to preserve the section
collapsing functionality: I11bff21e81046898ca63f3f432797129fa70ad88.
The following elements are now outside of `<h2>`:
* Metadata bar
* Subscribe button
* Ellipsis menu (only shown on mobile)
The following elements are sadly still inside of `<h2>`:
* Subscribe links (only shown on desktop)
* Section edit links from MediaWiki core
Trying to move them mucks up the CSS too much. I hope we can resolve
this later as a part of the work on T13555.
Depends-On: I11bff21e81046898ca63f3f432797129fa70ad88
Bug: T314714
Change-Id: I0bbdcfa02c334858737855349d7a35746de1d8f2
This is a better way than a loop in the test code.
When using DISCUSSIONTOOLS_OVERWRITE_TESTS, if both desktop and mobile
cases fail, both will be updated now. Previously the first failed
assertion would stop the test after only updating one file.
Change-Id: I4ce6f45b047e02c9f00024a9e5057adcb0e28047
Just to confirm that this works correctly, because I broke it a few
times in different ways while working on T321121.
In this scenario, discussiontools_item_revisions contains rows for
the oldest and newest revisions of pages containing each comment
distinguishable by name, as well as extra rows for the newest
revisions of comments indistinguishable by name, so that they can
be looked up by ID.
Change-Id: Ic8450a6b082ed343dd633d3a43c50696b5d6d2bb
Use revision IDs to break the tie, consistently with MediaWiki (see
RevisionStore::getRelativeRevision) instead of assuming that the
revision we're processing now is somehow both older *and* newer than
the other one (the mind boggles how that ever made sense to me).
Change-Id: I9f1a07124301a36be68578d908353b72f0442c00
discussiontools_item_pages row itp_id=5 has incorrect
itp_oldest_revision_id. It should point to the older of the two
revisions with the same time, but it points to the newer one.
discussiontools_item_revisions row is missing.
Depends-On: I56f0e161e5438d5f77b7d53d4db7411f90f97d05
Change-Id: I61ed42515891a84729455a7a32c98276c7cacd40
The changes from I39f9b994ce5636d70fea2e935a7c87c7d56dcb26 also make
most of the broken tests pass again.
Change-Id: I165f36235b47dee4bcef115e518bc1e81d2f83a5
We originally used 'templates' because it seemed like an obvious
choice for HTML files, and because 'packageFiles' requires extra code
to include anything that isn't a .js or .json file.
However, the templates are expected to be HTML fragments rather than
whole documents, and they are parsed in a particular way that takes a
lot of code to clean up (which we needed to do, because we use the
same test files for testing PHP code).
I tried doing it in the 'packageFiles' way, and the extra code doesn't
seem that bad in comparison after all. Moreover, the 'templates'
mechanism (when used the intended way) feels vaguely deprecated in
favor of Vue.js, and I'd rather move away from it.
This makes the tests faster too (probably mostly thanks to the removal
of the clean up code) – on my machine they go from 1800ms to 1500ms.
(Simplify linearWalk tests, as we no longer need to do weird things
with document fragments to get consistent outputs in PHP and JS.)
Change-Id: I39f9b994ce5636d70fea2e935a7c87c7d56dcb26
This fixes tests in modifier.test.js. The old parser tests
in parser.test.js are currently skipped.
Change-Id: If1fa8055b3cb6c6b43420ab40dd51af79fa083d9
