The following values for configuration variables are supported:
$wgDiscussionToolsReplyIndentation = 'invisible'; (default)
$wgDiscussionToolsReplyIndentation = 'bullet';
Bug: T259864
Change-Id: Icefad79630adc6ed35687498614e6a03ede1451b
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
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
To better support adding more links to the buttons group:
* Only disable the 'reply' link when the reply tool is open,
not all links in the button group. If future links need
to be disabled (e.g. 'edit') they can be done on a per-case
basis.
* Add a 'separator' class for adding more links.
* Don't hide 'reply' link when in use. This feature was added
very early on (I03a98495) and a long time before we started
greying-out all reply links when the tool was open (I3bb5ad8e7).
It would also lead to a strange display if there were
other links in the button group. Instead change the link to
black to indicate it is in use.
Change-Id: I23cc8d305d1d1c323cb69081749443f6e19de6a4
Set `overflow: hidden;` on the heading element to establish a new
block formatting context, which will contain floating elements.
Most skins already do this, but not Timeless.
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Block_formatting_context
Bug: T298069
Change-Id: Ic7afd82095b7440cf8b61b3f3fd0085e755a773e
This matches the PHP implementation and was only used in
one place (when fetching authors in new topic tool).
Change-Id: I9d9e774616112e8dc6ab4919846e3abecc24553d
We're probably not going to use it again, and I don't want to make the
effort of rewriting it in Id867b3005ebc46906d6df852a525fcaec9e6b19b.
Change-Id: I0b02533f7c9b8c1b0df271e03a74063f123d0dff
Follow-up to bfe6a36514.
We should only check the transclusion data for `comment.name` when
the data for `comment.id` is undefined, not when it's false.
Bug: T297850
Change-Id: Ia47462a7727edd551db88ec18b5b07017f669d2b
This was a logical merge conflict between 4912a1bf5c and 9ded06a655
that I didn't notice when rebasing the latter. Waiting for the
'mobile.init' module to load changes the order of operations if we're
highlighting the new comment after reloading a page, which we also do
after creating new talk page with the new topic tool.
Bug: T295945
Change-Id: Ief4810cc67c1bda9256585da1e2140b3a222dc5e
When our interface initialized on a page that the current user
recently edited (using the reply tool, the full-page source editor,
or any other way), check if any new automatic topic subscriptions
were added and update the interface to reflect that.
This requires doing some API requests after the page is loaded,
because adding auto-subscriptions happens asynchronously in a
DeferredUpdate (potentially after the user is already viewing
the page with their comment saved), and depends on the contents
of the edit.
(When using the reply tool, we could avoid this API request and
replicate the logic, but that's not implemented in this commit
to keep it simple.)
Bug: T284836
Change-Id: Ic0fabda0de4ebbc5e424f49641e6b03ebb4b7e6a
Usually this isn't a problem, because the comments are marked as
template-generated and we don't allow replying to them. But we had a
special case where we were trying to skip over some invisible
elements, which was causing us to skip into the middle of the
about-group in some cases. When Parsoid sees that, it serializes the
contents twice.
Bug: T290940
Change-Id: I9fe0b8d43ab874ccef371990799f77bfc46bc954
This is the minimal fix, they still look out of place, but they don't
break layout of the whole page.
Bug: T292241
Change-Id: I1538962dd266fb455051e4dfe2680e47c4d1bb4c
* Use featuresEnabled.newtopictool to decide when new topic
links might exist on the page, instead of relying on
`#ca-addsection` existing. Change the logic of that feature
flag to check if __NONEWSECTIONLINK__ is on the page.
* Render the add-topic button locally in a hook to replace
the one suppressed by onMinervaNeueTalkPageOverlay. Do so
whenever the newtopictool feature is enabled (see above).
Bug: T270537
Change-Id: I3e3f7403b3b86bb84fcb75a8833919512519b70f
When this code was added in 5feb69612f,
it was inside the `if ( this.modeTabSelect ) { … }`, because switching
was an experimental option and could have been unavailable.
Switching is always available now, but the `modeTabSelect` widget
doesn't exist in the mobile version (because switching interface is a
part of the toolbar there), so this line should be outside the `if`.
Bug: T270536
Change-Id: I7c5959281e77558bfe82bd39d38ba4dda36d590c
MobileFrontend does not use the 'wikipage.content' hook, and its
interface will not re-initialize properly after we update the page
contents with the new comment. Reload the whole page instead.
Bug: T270536
Change-Id: I3f81e4d77faed367606e47678b8896051982359d
When an exception is thrown by our code elsewhere, and caught by the
promise mechanisms, it bubbles up here in the `code` variable, and
`data` is undefined.
Change-Id: I8a0ac49d22d254f353797fc8978871502ae8b9de
This causes the username to be selected on mobile, when
we want to place the cursor after it.
Bug: T294616
Change-Id: I29012ecd04cd553bf78ffff477babafacfeabb31
`this.limit` is never set, which mean the API default of 10
was used.
The client limit is actually `defaultLimit` which is set to 8.
Double this so we can filter blocked users and still probably
have some results.
Change-Id: I8184fa0ce1527280f4503bcf638372421287f51a
Such users will never be able to reply to you on most pages,
so we shouldn't suggest pinging them. The may be able to reply
on their own user talk page, but in that case they will be
included in localUsers.
In the best case they just clog up your search results, in the
worst case they are offensive names which haven't yet been hidden.
Bug: T294783
Change-Id: I2445ed6dc98c10f8580b2c36106dd3e98bb876d6
These types can be passed a parameters to any file without
creating a dependency, so it makes more sense to allow
the globally.
Change-Id: I5504465fd997b46547642e7046993b370b85586e
The current experience (implemented in T282789) is unobtrusive and
maybe even helpful.
This reverts commit 35e97c24fe.
Bug: T281009
Change-Id: I0514e8f8960600edf12b51fff6de305e46cf8c34
Normal link: `<a>reply</a>`
Google Translate: `<a><font><font>reply</font></font></a>`
Using jQuery's `closest` method to make sure we go up if the event
target isn't the data-mw-comment element should avoid problems.
Bug: T245563
Change-Id: I19ffb9a5b91617b98b0f00e4d185c01bcde093b0
Since Id9afb2dd0212e4b871bb6a7a9d8762e1bcb81d6a included in core since
MediaWiki 1.38 the uppercase of the first character of the parameter
auprefix is not needed anymore.
Bug: T291339
Depends-On: Id9afb2dd0212e4b871bb6a7a9d8762e1bcb81d6a
Change-Id: Ic14ca9c9c61d2a50bdbaff50b56302a60ed17a96
It was previously applied on the whole wrapper of the anon
warning, including the buttons. In some cases (on mobile, and
on some sites with weird customized site CSS), this causes the
buttons to lose some styling. Apply it only on the label.
Follow-up to 522b7932d7.
Bug: T270536
Bug: T291000
Change-Id: Ia4bc99fc219a80efbf46a7cc196ea29720a34de8
Currently the message appears too often when the user is not really
intending to interact with the widget.
Bug: T287901
Bug: T288316
Change-Id: I38b4c0b8817b9a9238fb6adc91ab2d1231650eff
Notifications are bundled by section, so instead of linking to the
comment, link to the section.
Additionally, add a parameter to the URL listing all the comment IDs
from the bundle, and highlight them all and scroll to the topmost one.
Having to handle both URL fragments and URL query parameters makes
this code kind of a mess :(
Also, some unexpected changes became necessary:
* EventDispatcher.php: Store the section title in events using
HeadingItem::getLinkableTitle() instead of ThreadItem::getText().
The result is mostly the same, except in case of wacky markup like
images or extension tags. We can more reliably use it to link to the
section on the page, and we already use getLinkableTitle() when
generating edit summaries in the reply tool for this reason.
* dt.init.less: Change the mix-blend-mode for the highlights from
'multiply' to 'darken', so that multiple overlapping highlights do
not look more opaque. This affects how the highlights look on
non-white backgrounds and images (they're less blue, and on darker
backgrounds entirely invisible), but it seems worth it.
Bug: T286620
Change-Id: I21bb5c003abc2747f0350d3f3af558dfb55693e9
This was copied from somewhere else (probably VisualEditor), but it is
not needed here.
Using the multipart/form-data encoding is beneficial when sending long
binary data (such as the compressed HTML VisualEditor sends), and is
also required when uploading files, but it is not helpful when sending
a short query like we do here.
Also rename a variable.
Change-Id: I9bcce2ce1ca7c218e4cd147960d1070dd23ea9fa
This will avoid a flash of the empty-state while we're reloading the
page to get new tabs.
Refactor out the new topic controller's clear behavior from its teardown
behavior, so we can still wipe out the storage when redirecting.
Bug: T288314
Bug: T288320
Change-Id: I6a5313b5e5b3bc9925e5cdaea04d8fbd3dc796af
This includes the dtrepliedto URL functionality from
I3f81e4d77faed367606e47678b8896051982359d.
Bug: T274831
Bug: T274832
Bug: T277329
Change-Id: I035d04f30c8312b0cb42902d3bf940df1482ffb3
This is the same method as used by VisualEditor
(ve.init.mw.DesktopArticleTarget.prototype.replacePageContent).
Bug: T275698
Change-Id: Idcf7c79b8d5565b0ae36c6e9d42b66662c1acc8d
* Move getTitleFromUrl() from parser to utils. It's a generic method,
the PHP equivalent is already in utils.
Bug: T277371
Change-Id: Id960e5f60af02bdeb0a3a68f43b7a695eb035139
I noticed that the NWE new section editor would open sometimes even
though we attempt to prevent it. This way seems to work more reliably.
Change-Id: I0ce1640b8c1dd098bf3f0d41dc4fdc276a0c5fd5
Problems with the current setup:
* Each CommentController must have exactly one link.
For T277371 we want multiple, and for T282205 we might want zero.
* CommentController objects must be constructed immediately.
They are implemented to make this pretty fast, but it's still
unnecessary work to do on page load.
* Only one link may be activated at a time, and activating one affects
the styling of others, so CommentController has to use global state
to check if it can set up and to update them.
Instead introduce ReplyLinksController, which knows about all reply
links and which one is active, and emits events that allow
CommentControllers to be constructed on demand.
Change-Id: Iabdeded2e71e598ae78703a6ff9410d0cfba397c
Considerations:
* Using the same edit notices as VisualEditor, except 'anoneditwarning'
* No extra frame/styling is added (on Wikimedia wikis, the notices
often already have them)
* 'talkpagetext' message is not shown (on Wikimedia wikis, they are
mostly about signing your posts with tildes, which is not necessary)
Bug: T269033
Change-Id: Idc5ff29f093c75a14c3a3479888295d5bf630f6d
The .ve-init-mw-target-surface class is no longer added since
Ic5320f6747907542285674d386c7a59c9e857f0a.
Also apply changes similar to I8d20a830dc48f6a098b0f9e9a7c7c1656de0fe56
to avoid potential styling issues with nested surfaces.
Bug: T284567
Change-Id: I58a49f0137e8804fbd73de20048eb2ffdbbfbe77
Previously, our highlights were placed in a node at the end of
the page, and positioned absolutely in relation to the whole
page. Now we insert the highlight in the DOM near the comment,
and position it in relation to that.
This way it remains positioned correctly when the page shifts
(e.g. collapsing the table of contents), and disappears when
the page content is hidden (e.g. opening visual editor).
Bug: T281471
Change-Id: I60afc4b94b2e23376105638542563e595a1811d9
The modifier crashes if endContainer is a <p>/<dd>/<li> node, and
it often is if we try to exclude the end marker from the range.
It doesn't matter for T281471, so let's just leave it that way.
(This is also more similar to the range produced by our parser.)
Follow-up to c4ba8e921a. No idea how
I missed this when testing that patch.
Also, improve comments.
Bug: T281471
Change-Id: If6aba34acf29c37d06fb0ca92547f78b58695597
This produces nicer results when we call Range#getBoundingClientRect
on them later, when drawing comment highlights (using Firefox).
I'm not sure how this will affect everything in modifier, but it
doesn't seem to be causing issues. If it does cause trouble, then we
should instead adjust the range this way in controller#highlight.
Bug: T281471
Change-Id: I6f204b858990023f42f564cca7a2d24d322f872e
Per Manuel Arostegui in T263817#7033384. The limit is 5000.
(I picked it arbitrarily, there's no real rationale for it.)
Also log a warning when any user reaches half of the limit,
so that we might make a decision about changing this mechanism
before it starts affecting users. Maybe at that time we'll
have data to show that it's safe to remove the limit.
Bug: T263817
Change-Id: I18a8ee0ad7383759229c5721d5253fb591457d4d
The issue occurred when replying to a comment consisting of multiple
list items, starting with a <dt> (instead of the expected <dd>), so
that the comment is considered to be unindented.
Modifier tried to add the reply directly inside the list (<dl>) rather
than inside the last list item (<dt>), which caused it to be confused
about indentation levels and try to un-indent more times than there
were indentations.
The simplest solution, given the existing code, is to add the reply
outside the list instead, in a new list. This results in a "list gap"
(<dl><dt>...</dt><dd>...</dd></dl><dl><dd>...</dd></dl>), but I think
it's acceptable for this rare case.
There are separate tests cases for old Parser and for Parsoid HTML,
because they parse the original wikitext differently (with the old
Parser producing HTML with a list gap too).
Bug: T279445
Change-Id: Ie0ee960e7090cf051ee547b480c980e9530eda51
If curLevel or desiredLevel are calculated incorrectly, this loop
could never end.
In JS, something would throw an exception before going infinite, but
PHP is happy to trot along despite accessing properties of null and
attaching multiple children to a document node.
Bug: T279445
Change-Id: I1784f550ec3a23dcded4f2b1def97e51cb414b7b
We added it because the initial designs for the subscribe action were
much easier to implement like this, and topic "containers" (T269950)
would have required it.
However, the latest design of the subscribe action will not need it
(T279149), and topic containers are still very far away, so let's
remove it for now.
Bug: T280433
Change-Id: I21a23e9bea43f24d265750926fbd62b99038d3f1
As of 7ad6328223, we also use this data
to check whether comments exist on the page, not only whether they're
transcluded.
Follow-up to 42ce942c86.
Bug: T275821
Bug: T273413
Change-Id: I95eb85354e7b84cc10ab703d28315d0667696f4c
The information is already included in the VisualEditor metadata request.
Bug: T276393
Bug: T270803
Change-Id: I45a232dcd23418da0711834bcc369a9a718006b0
The existing comment IDs can't be used to find the same comment on
a different revision or page (when it's transcluded), because they
depend on the comment's parent and its position on the page.
Comment names depend only on the author and timestamp. The trade-off
is that they can't distinguish comments posted within the same minute,
or in the same edit, so we will still need the IDs sometimes.
Prefer using comment names when replying, if they're not ambiguous.
This fixes T273413 and T275821.
Heading names depend on the author and timestamp of the oldest comment.
This way we don't have to detect changes to the heading text, but we
can't distinguish headings without any comments.
Bug: T274685
Bug: T273413
Bug: T275821
Change-Id: Id85c50ba38d1e532cec106708c077b908a3fcd49
Topic title field and old wikitext reply field had only placeholders,
but no labels.
Mode selector had labels on individual items, but not on the main
control.
Change-Id: I422e7e5baa8711340a1bb82255e788f2272c45c9
When there are just two modes, using arrow keys to switch between
them is not intuitive. The focus moving from the selector to the
body widget afterwards is even less intuitive.
Override default TabOptionWidget to allow options to be highlightable
(not just immediately selectable), and mark the current mode's tab as
disabled instead of selected (but make it look selected).
This results in intuitive keyboard interactions (tabbing to the widget
highlights the other tab rather than the current one, pressing enter
switches to it).
Bug: T274423
Change-Id: I9d358d5f301cbf081380ef5d34ccc8c4e146652e
In some situations we didn't pass the mode in the config.
Simplify some redundant code that got messed up when we
introduced the NWE source mode.
Change-Id: Ia838fc6752d411f70c8cc6a36d84d2a851fd68bd
Longer, but follows the style guide and less likely to conflict.
We need to account for init classes in the cache being around for
a while.
Change-Id: I738bc93393850db320fdbda2b003ca8ac40556da
When posting a new topic, if your comment ends with a template
that has trailing line breaks, the signature will be added as a
preformatted text (which is arguably a bug: T255741).
Preview, however, did not reflect this bug, because of the <span>
markup added to fade out the automatic signature.
Change-Id: I062b01a035e22edfca752a49c5e2433b3f7fb4f6
We have logic above to exclude mentioning yourself, but this
is overridden if you are commenting on your own talk page.
Change-Id: I2858c79bd9f1cb733f105825e17f9df75859e40a
There are no available tools that use this, but it
can be tested using:
ve.init.target.surface.executeCommand('specialCharacter')
Change-Id: I853e6a3b9bd3caff018b6fe22cea9b1c6a428dff
Now it detect signatures generated by en.wp's {{Undated}} template,
and signatures of people who do weird stuff to the timestamps.
Bug: T275938
Change-Id: I27b07f6786ca5433a3c02a5fe68e4716d41401bb
In some cases it would return the parent node, instead of the siblings
it should return.
It's a private method only called by getFullyCoveredSiblings(), and
that method had a bug that cancelled out this one, so everything
worked correctly. But I want to use it elsewhere now and ran into it.
Change-Id: Ic12f007d57a8502a1bea5f0af17b29e9d59093d6
The horrendous 11-line if() condition did not correctly handle
signatures wrapped in inline formatting markup, like <small>.
Instead, implement this logic in the code for skipping to the end
of a paragraph, which didn't exist yet when that condition was
added, but seems like a much better place to check this now.
Bug: T275934
Change-Id: I5cccff889b5e15b5f8fde0538bf4bccb22e762cf
Same pattern as is now used in VisualEditor. Generate an initial session
ID when the file loads, so if any VisualEditorFeatureUse events trigger
before the init there'll be a session ID for them to use.
Bug: T275051
Change-Id: I4f25e9e1e195c11129044868eb67fcc2f4494ffd
Yes, this is still needed, removing it causes failures in tests
(and the old outputs look better).
Change-Id: I5bcedb0295a1f0ac4f6e51eaa9a9e072d8236f3c
Top-level comments that start or end with a list (inconsistent
indentation) would not have triggered the logic for detecting
wrappers.
Bug: T273692
Change-Id: Idcb4eed73e391f5f86eca2eb05cb3cea0d86f30a
Since it's no longer tied to the "Reply" button, we can move the code
from ReplyWidget to NewTopicController, where it belongs.
Bug: T272543
Change-Id: I8c90ffb772573d22d26c608d45877ee948fd232d
* Ignore rendering-transparent nodes between discussion comments.
* Improve isRenderingTransparentNode() so that <link> nodes
representing TemplateStyles are not considered transparent,
otherwise this would undo ae920b831f.
Using a regexp from Parsoid.
Bug: T272746
Change-Id: I0b3c3251156ba6c4826abf5ba44ea93f80ebc01d
Several of the messages talk about clicking the reply links, which
seems unhelpful. Also, showing a fullscreen popup on page load seems
very unhelpful too. (Itoldyouso that we shouldn't use popups.)
Bug: T268069
Change-Id: Id1312cf06200fb45a28b39481a99cc2c96603fa4
If the user is clicking on a new topic link, and a reply widget is
open, attempt to close it instead of doing nothing.
Bug: T272545
Change-Id: I1903f5ae4c9e98c4b3a4703ad0e44d772894592a
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
