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
Also rename CommentController#teardown to onReplyWidgetTeardown,
and NewTopicController#clear(Storage) to onReplyWidgetClear(Storage).
Change-Id: Ib1dd50ca69aac6f1836674d1a6aefa2402844c57
Saying that ctrl-enter would submit the post at a moment when it
wouldn't may be confusing to users.
Bug: T326500
Change-Id: Ib513c8a6c36a0f607cc2034fc830dbfcdf10f554
When rendering a preview of the comment in order to check whether it's
signed, use the previously acquired temporary user username for the
signature.
Depends-On: Iec8a15dadd595bed0f7e54f907fbb8e192b45cf3
Bug: T331397
Change-Id: I7aeb1cc4c107ed752dc805405780a7609a6d4d3c
TODO comments suggested using the VE helper util, but
that is no longer necessary since all our browsers
support passive events.
Change-Id: I7026d4c5013857f25f4474b3bec840af6fbf9fb6
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
PHP logging code is not moved.
* Use the new mw.track() handlers from WikimediaEvents
* Ensure that 'integration' and 'editor_interface' are set on init
events, since they're not hard-coded in the handler any more
* Remove the setting of 'editingStatsId' tracking parameter,
now happens in WikimediaEvents (by way of VE ArticleTargetSaver)
* Remove code connecting ve.track to mw.track, now happens in VE
This must be merged together with WikimediaEvents change
Iace4d53a972396ca5b8713000570cc47c9986034 (but we can't use
Depends-On, because CI requires code here to be removed first).
Bug: T332438
Change-Id: I0ef0a96aafdf89a4ebe32131a85b18c25744bb2c
Previously, we would restore the title and the summary generated from
it, but we wouldn't restore `prevTitleText`, so we would lose track of
the fact that it was automatically generated, and stop updating it
because of that.
Instead of adding it to the stored data, let's instead stop storing
automatically generated summaries, and tweak the code to support
generating them when restoring.
Bug: T315730
Change-Id: I96420bc0a3e34373190d2c2c0db2e2175ad3156d
This allows it to be re-used for other features, such as the
upcoming floating "Add topic" button.
Add some support for Android, although not used in this patch.
Change-Id: Ibd1e1ee087ac607c88a7402d0422c633700d1992
Add brackets around the existing shortcut key labels, so that they
don't look quite so out-of-place next to the automatically added
accesskey label.
Bug: T278249
Change-Id: Icc0df5ba036080807ea0eb215f5526c93da78ef1
When using ReplyWidgetVisual, this would just crashes in #getValue.
When using ReplyWidgetPlain, if the timing is right, this might update
our auto-save after the value was cleared in the teardown code,
breaking the way we restore the reply after showing new comments.
Bug: T316074
Change-Id: I23c5f17a6ff9a6ec9c73a176e4cc60e3ad96e7f1
mw.util.getUrl() already encodes the values, encodeURIComponent()
isn't needed.
Also, slice off the leading '?' – while MediaWiki seems to accept it,
it looks like it is never present in any other place using this
parameter (this is fine even if there are no query parameters).
Bug: T308198
Change-Id: Iee3747ab53e3b0a5a0b43a7701205ac0c7f07e7f
`tagName` is only defined on Element, and it returns its tag name.
`nodeName` is defined on Node, and it returns the tag name for Elements,
and a string like '#text' or '#document-fragment' for other types.
We were using both, which made it harder to reason about what types
we're dealing with.
Change-Id: I8e621e5872bdf78c84ec553cfbfcdbf0192f0589
We were rendering the preview in a completely different way from how
we would add the real reply, and the results would be different
sometimes, particularly for multi-line comments with messed-up markup.
Render it server-side instead, in a very similar way to real replies
(generating a DOM list node and transforming it through Parsoid),
although without the whole context of the page to improve performance.
We can remove a lot of client-side code that was used solely for this.
This will allow the preview to accurately display the signatures when
we change how they are added (T278442), without us having to implement
those changes again from scratch for the preview.
Change-Id: I53341f4d4075c25b67ec3b3032bff9b8a880dcd3
* Document all methods
* Rename comment to threadItem
* Use this.threadItem instead of passing in identical
threadItem in various methods.
* Don't pass threadItem to ReplyWidget as we already
pass the whole CommentController.
Change-Id: If9aad0bcf9f0e4ebf3342b75631ddac8b57f7d87
The following values for configuration variables are supported:
$wgDiscussionToolsReplyIndentation = 'invisible'; (default)
$wgDiscussionToolsReplyIndentation = 'bullet';
Bug: T259864
Change-Id: Icefad79630adc6ed35687498614e6a03ede1451b
