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
This matches the PHP implementation and was only used in
one place (when fetching authors in new topic tool).
Change-Id: I9d9e774616112e8dc6ab4919846e3abecc24553d
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
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
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
