* 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
This should avoid them showing up in unexpected contexts where parser
output is used (e.g. API T292345, search T294168, action=render).
Also rename some variables to be directionality-neutral.
Bug: T292345
Bug: T294168
Change-Id: Ibcac44ee10f0842e205d9dd9a7f3a935ce0c690b
A tag described as "Edit comment" doesn't make sense grammatically.
It should be in past tense, "Edited comment". (Another option could
be a noun, "Comment edit", but that seems less clear.)
Change-Id: I32cf6e533b4b98b5206dd3c74abdf5168f1f2e37
The markup has no effect in English, but it helps reassure translators
that it will work if they need to provide multiple grammatical forms
in their language (or remind them that they do).
It also lets us test this functionality even when testing in English.
Bug: T292636
Change-Id: I093e9a1e0e8e3e9a1808220ab12831fdf8dbc108
* Explode boundary point tuples passed to computePosition
* Note that we won't use previousSibling instead of array_reverse
* Simplify logic using xor
Change-Id: I927256e31b5e441aade91b4fd0d83d8f0d89afbe
