For two given revisions, this API tells us which comments have
been added and which have been removed.
Can be used to highlight new comments, or check if the page
has been updated since we first loaded it.
Bug: T281624
Bug: T300504
Change-Id: Ia4d95ffe3b7cf2317cd8e7c0f034e09f64777ef3
This is now deployed on all wikis, and going forward I don't think
we need to make this configurable.
Change-Id: I231976267ba6cdfeec622efaa15983a84c330649
Goal: To be able to re-use or test the transformations we previously
performed in addWikitextReply() / addHtmlReply(), without requiring
a Comment object or adding the result as a reply.
Change-Id: I040c4be9b6b9bddba661f30fd0566f8850673074
* We don't need it anywhere in JS, since we're not sending that HTML
to Parsoid.
* We only need it on the nodes directly containing our reply lines in
PHP, not all over the place.
Change-Id: I0a04388225f32654dda2f599442cd27a303b5d0a
After switching from source mode to visual mode, there will be some
Parsoid-generated white space between block nodes, which remains when
the reply is posted in visual mode.
Follow-up to e064f43499.
Bug: T300439
Change-Id: Ia5d2c06f0a4125e9f148eddd3235f95138c9d37f
When we encounter a node that doesn't represent comment contents, e.g.:
* a [reply] link we inserted (T297034#7641334)
* an {{outdent}} template (see changed test case)
…we should ignore it together with its descendants (like in
Parser#nextInterestingLeafNode), instead of processing descendants
and possibly detecting comment contents in them.
Follow-up to 8de940b587,
72b9c2c6f5.
Bug: T297034
Change-Id: Ib2fa40c5fa389572b0e88ef558728fa06e3621b0
In PHP, use DOMCompat::getClassList(), provided by Parsoid.
In JS, use `.classList`, available in all supported browsers.
This may fix some bugs where we were incorrectly checking for exactly
one class. The change in isOurGeneratedNode() is needed for
Ib2fa40c5fa389572b0e88ef558728fa06e3621b0.
Change-Id: Ia28d31678fd3d617b69280c4b7857755300fa515
This code previously ensured that the fragment identifier linking
to a section was only included if all events had the same section.
It doesn't actually seem worth the effort, since we handle scrolling
to the highlighted comments client-side anyway.
And the links were not quite correct, because we didn't parse and
strip the section title as expected by built-in Echo events. Just
use Echo's code for this.
Depends-On: Idb3a87fd18330f90a8cdc1276994d54288e17b28
Change-Id: Icae0d3654dd02109337ff8737b16f55bbd514f43
The following values for configuration variables are supported:
$wgDiscussionToolsReplyIndentation = 'invisible'; (default)
$wgDiscussionToolsReplyIndentation = 'bullet';
Bug: T259864
Change-Id: Icefad79630adc6ed35687498614e6a03ede1451b
$user->saveSettings() happens in AuthManager after the LocalUserCreated
hook finishes running.
Bug: T199393
Change-Id: Ic661dbe1ffaa3a5438373a33c10ad3053662d932
Reimplement getFullyCoveredSiblings() using compareRanges(), which
checks basically the same thing, but works better and I like it more.
Bug: T297034
Change-Id: I33dc1d088bdee984064315290e378bfbfa830b10
Previously: 569db3603c (2020-06).
Unfortunately we've found cases where the previous implementation
doesn't work correctly, resulting in comments being added to the wrong
pages or page corruption.
Bug: T289873
Bug: T298051
Change-Id: Id867b3005ebc46906d6df852a525fcaec9e6b19b
Comment boundaries are stored as a DOM parent node plus a child index.
Because of that, inserting anything into the DOM before a comment –
such as another comment's start/end markers – would cause us to insert
subsequent comments' markers into the wrong places.
This issue didn't affect many pages, because usually any parent node
would have just one comment in it. Only pages with comment boundaries
outside of any wrappers (directly inside the root node) were broken.
Just process the list in reverse to fix this.
Bug: T298096
Change-Id: Iccffc36b71e9fcf3d72c4db2b9459d39042f7a2d
We realized that any change made to Special:Preferences will set the
beta preference even if they didn't visit the beta tab, so we can't
actually tell if manual intent was involved. As such, we'll enroll
people regardless of their beta setting -- they can disable the feature
through regular preferences if they want, and that'll be respected.
Bug: T291307
Change-Id: I8c1cbf51060012e8e68af252da84944dfcc681d8
For logged out users we store their test state and an anonymous
identifier in local storage. So long as the test is enabled, we include
these in any logging that occurs.
This is done entirely client-side, to avoid any cache issues caused by
state depending on cookies from PHP for logged out users.
Bug: T291307
Change-Id: Ib39e2f2146cdfdac9df5690ee3de75718f0f2731
The global function wfWikiID() is deprecated since 1.35 and it's usages
should be replaced with WikiMap::getCurrentWikiId().
Bug: T298059
Change-Id: Ie878a5479b7427e9ffab7d7f92ee2802997e3161
Better describes that we are checking the editor used to make
the edit, rather than descibing some virtual "location".
Change options to 'discussiontoolsapi' and 'any'.
Change-Id: I3024517e70ed61c738e4bf46a2ac7b58c975d98a
Trigger off the (absence of the) new preference for tracking topic tool
usage.
Change the name of the bucket preference so anyone who was enrolled in
the prior abtest won't find themselves re-enrolled.
Update the abtest enrollment code so it explicitly sets the preference
for the feature. This is a trade-off -- it does mean that we'll need to
special-case *unenrollment* once the abtest is disabled if we want to
just quietly revert people to the wiki's default, but it also means that
Special:Preferences will be accurate.
Bug: T291307
Change-Id: I659679e05b65fc7db05e249114e5a7de4cf55816
