Some of what happens when you click reply happens in
CommentController (in #save) and some error handling
happens in ReplyWidget (in #onReplyClick).
Move most of the logic to CommenController.
Change-Id: Ib6208c0b8d2ddbbcf08adfcca7875ab8b026f598
Leave rule off for now as manual fixes are required.
Also temporarily disable prefer-const rule as that
will also require some manual fixes.
Change-Id: I8c3478f26f51287acb943bd38c9c1020c06b9f39
When an arrow function body contains just a single `return` statement,
the braces can be omitted.
(Changes are mostly made by `grunt eslint --fix`, with only some line
breaks added by hand.)
Change-Id: I37f259f87085c8d20ed09cfa58a8456dd36cdc38
Similar reasoning for our existing filter on just `/`; it's only really
used in state routing.
Bug: T361322
Change-Id: Ibcf1a58a884b953003012640041471d3bb5c9450
Top is in the WHATWG spec as a magic value that always navigates to the
top of the document.
There used to be a #top element in pre-Vector2022 skins, and it's in
fairly wide use on some wikis in signatures and via gadgets, so many
links exist that point to it.
Bug: T360274
Change-Id: Ia12464239ab2cdc428c570d0cf5df1c0d1780b7a
We need to more carefully wait for mobile section toggling to happen.
Follow-up to 3957d7ac25.
Bug: T338920
Change-Id: I1bd31483c5be9428075f07494e89b06f19f8bf23
MediaWiki should never generate links like this, but users or 3rd
party tools probably create them accidentally quite regularly, and
we do a similar thing with Title normalisation.
Change-Id: Ia467f422578bcb9b4d3fb8feab0b85f4b6436f7e
Follow-up to 8a8c7270cf.
I think this wasn't working becase we were doing it in the wrong
order (reply tool initialization would disable toggling section
state before toggler toggled it open).
Bug: T338920
Change-Id: I7ed3d5c149ddb3d33cb67010f032c63e175687f2
* Keep the information about this in the API result, which we were
previously omitting
* Use it instead of duplicating the logic client-side
Bug: T356131
Change-Id: I7e7342e9d94a171b5ef56e646871c18c8c39c44c
`decodeURI( fragment )` can throw if the fragment isn't correctly
encoded – e.g. when it's just '#%'.
Use mw.util.percentDecodeFragment() instead, which uses a more
resilient algorithm.
Change-Id: I8447771ad2ae33da52b71d4127981dd8a2018a7d
Section titles containing non-ASCII characters were being passed through
URL-encoded, resulting in no results being found.
Bug: T356199
Change-Id: Iac56ee434a37baf3d170aec992d2f2d8679b6f1f
results[ 0 ] would be undefined, causing a later JS error before the
toast could be shown.
Bug: T355165
Change-Id: Ia591a1e4db0acfa377201c355938a32f680393ce
This prevents an exception being thrown if you open the
new topic tool when a reply widget is still loading.
Change-Id: I17da48ddf91394d05cc82613ce5517f1e176750b
We shouldn't assume callers of this method have waited
for the replyWidget to be built.
Bug: T354292
Change-Id: Ic66b4f04b8786b07f520e329adda37efcf498dad
* Looks for heading IDs matching "h-<heading text>-%" that once
existed on the target page.
* For such IDs, finds where those items currently exist,
presumably in an archive.
Pros:
* Doesn't need to know anything about the local wiki's archiving
conventions, so can be deployed universally.
Cons:
* ID conflicts will return matches in unrelated archives, e.g.
MassMessages.
Bug: T349653
Change-Id: Ie94efd0503e9f4689d3421babe445f9f4e2b4fb7
This requires something like an invalid timestamp, to produce a reply
link whose associated comment ID is going to not be findable.
Bug: T350633
Change-Id: Ib50c11096b9af9961b74309b60524a4b986e04aa
Only a fraction of a percentage of users are still using
ReplyWidgetPlain, and keeping these modules separate:
* Adds to code complexity
* Adds to ResourceLoader module bloat
* Causes bugs when we use VE dependencies in the
core ReplyWidget class
The disadvantage is that ReplyWidgetPlain will now be
loading all of the VE dependencies, but this will make
switching to visual mode faster.
Bug: T348834
Change-Id: Ifb0cfd43fdab761c3321ad01fa9fefca26473f86
Why:
- We'll reuse this functionality on desktop, so it makes sense to
extract it to a standalone file
What:
- Remove relevant code from mobile.js and place in overflowMenu.js
Bug: T342251
Change-Id: I98f1253e8d6db31c1f71203b50911b6f1b92778b
Why:
- We want to allow extensions to register interactive menu items in the
overflow menu.
What:
- Create a PHP hook to allow extensions to provide menu items
for rendering in the overflow menu
- The hook allows for registering resource loader modules required by
the menu item
- The hook passes in some contextual information, like the thread
item data, context source object, and if the page is editable
- Create a JS hook that fires when a user selects one of the menu items
- Example implementation: Ie9afbedb4f24cbd75eb48bb21dc9f6d8d732d853
Misc:
- Remove b/c code that existed to handle a transitional period where
JSON encoded overflow menu data did not necessarily exist in the
parser cache
- Rename code instances of ellipsis button / data / menu to refer to
"overflow menu"
- Some renames will have to wait until parser cache is updated; these
are noted with TODOs
Bug: T342251
Change-Id: I5f2a51791f8ba7619d1399a4b93111e9bb44e172
When the user clicks anywhere on the page after following a permalink
(e.g. from a notification), we would remove the comment highlight and
the hash from the URL. Don't do it if the click is on another link:
this avoids inserting extra history entries when clicking on several
permalinks in a row.
Change-Id: I5d77dae4608f74b2be09b9cb92e39a8662529a9f
Follow-up to c0f5a95504.
I missed that this code path can also be reached when
a temp user has not in fact been created.
Bug: T345569
Change-Id: Ia37760c674074b12baa17d842fa4f4d95ca20c5e
I think the issues in T329299 are caused by partially autosaved
comments. We store data in multiple localStorage keys, and if some of
them are stored but others are not (due to exceeding storage quota),
our code can't handle the inconsistent state.
We already have a wrapper around localStorage that tries to cover up
these issues. Change it so that all values specific to an instance of
a reply tool are stored under one localStorage key. This ensures that
all updates consistently succeed or fail, with no partially stored
state.
One of the reasons we haven't done this is because this requires the
whole data to be serialized to JSON every time, but our experience
with VE change 4355d697aa shows that this is fast enough.
Extra changes:
* Remove storagePrefix, now redundant
* Remove use of createConflictableStorage, now redundant
* Prefix the key with 'mw' as advised by mw.storage documentation
* Use ES6 syntax for the new code (just for fun)
* Use consistent expiry (T339042)
Bug: T329299
Change-Id: I347115f7187fd7d6afd9c6f368441e262154233b
