The code for setting 'watchlist' in the EditAPI request
was completely broken as it always evaluated to 'unwatch'.
Instead pass through 'watchlist' directly from the client
where it must be set to 'watch' or 'unwatch'.
Bug: T245579
Change-Id: Ia5a2bb76ef35a685b39bcc0c4727796acd0f510d
When using TwoColConflict with VisualEditor, the autosave buffer wouldn't
be cleared after saving the successful merge. This would cause a user to
see a "restore changes?" prompt the next time they entered the editor,
with the potential to confuse them and cause them to do extra work,
repeating the conflict resolution unnecessarily.
This change purges the autosave buffer before submitting a merge.
Note that it is not transactional, so there is a chance we're losing the
autosaved content even if the submit will fail.
Bug: T245119
Change-Id: I150023f548c5565412769d644a828176f907bc25
Things I noticed while writing I37f8e89b6d92c419d1b6569891612256342f8139,
but which felt too messy to include in that commit.
* Use promise chaining
* Update documentation
* Remove redundant code
* Split a method that now handles two different errors
* Grumble about localisation messages
Change-Id: I81e28a03af4f6c3452679ef6bbcaa89bb1235122
When the user is saving their edit, we want to ensure that they
understand how it will be attributed. If the user gets logged out or
logs in in another tab, we want to display a message about it before
saving.
Instead of manually managing tokens and handling the 'badtoken' error
to detect this, use the 'assert'/'assertuser' parameters for the API
to detect it for us. Thanks to this we can rely on automatic retrying
for 'badtoken' errors in mw.Api#postWithToken.
It will be possible to share some of this code with other extensions
that already use ArticleTargetSaver, namely DiscussionTools, now that
it doesn't need to manage tokens for VisualEditor.
Bug: T245327
Depends-On: I485f99e1f5f493262b0c9af22370da01adf1e09c
Change-Id: I37f8e89b6d92c419d1b6569891612256342f8139
It was broken on desktop and on mobile, but for different reasons:
Desktop: In change 5f1c68945d,
I removed some code from DesktopArticleTarget that was checking for
`typeof errorDetails === 'string'`. I thought it was unused, but it
was actually needed for this code.
Mobile: overlay.reportError() doesn't work here: that method displays
the error inside the save panel, which is not visible at this point.
This is now solved by treating those errors as if they were API errors,
which is something we were already doing in ArticleTargetSaver.
Change-Id: I5207836f56d65171b1240cef02fc17b9956036ef
It turns out anonymous users can't apply change tags, so change
I2c1d0f8d69bc03e5c1877c790247e165f160e966 broke editing for them.
Bug: T242184
Change-Id: I7c27e4d9995428e213a980819810f235fdfe9435
Explanation of what this code was for: T227628#5339392
As noted on that task, our behavior is actually unintuitive and
distracting, and iOS Safari limitations prevent us from doing it
better.
This reverts commit 600e369347.
Bug: T227628
Change-Id: Id1a5eebd06e4218e3e102165c60791999293d273
This opens up the API so that other tools can use it without being
forced to tag those edits as being from VE.
Also, document that tags is a working parameter that can be passed
through to the edit API.
Bug: T242184
Change-Id: I2c1d0f8d69bc03e5c1877c790247e165f160e966
When NWE is enabled but VE is supposed to be unavailable on the page
(e.g. in talk namespaces), do not show the option to switch to VE in
the welcome dialog.
This is relevant if new users use NWE, due to config like below
(we use this on WMF Office wiki):
$wgDefaultUserOptions['visualeditor-newwikitext'] = true;
Change-Id: Iee8c3d3604a13dcd20efa713e49461ba9b885749
This code works perfectly on mobile now, I believe change
4fb17205b6 fixed that.
Note that the dialog is currently never shown due to the override
in MobileArticleTarget, but I tested after removing it.
Change-Id: I305a01fc78366a3d2d13662e6d71711864e0dffc
The .statusText and .status properties belong to the XMLHttpRequest
object, and are not present on the API response data object. I think
these checks were left over "just in case" when this code was ported
to use mw.Api instead of XMLHttpRequest directly.
MediaWiki API should never return just 'error' as the error code.
Change-Id: Iac6f721881b9405919d3397df6606e54f182bc59
We've just displayed an error message in it, so don't close it.
I'm not sure if this code matters at all though. Usually when
there's an error during loading, code in MobileFrontend will close
the overlay and display an error message in a different way, so our
message won't be visible to the user. But maybe there's some case
I'm missing, and it's harmless. Closing the overlay was messing with
the MobileFrontend code though.
(found when working on I5146b726c5ce213992febb23f24c5937db0b9bfe)
Change-Id: Id1ea44d7bf6ef0f4fc0285e9e606dd415ed0a947
The comment here seems to be wrong, as far as I can tell, this
case can only happen when viewing a diff with no changes
(`data.result === 'nochanges'`) or saving an edit and getting
a captcha (`data.result === 'error'`).
The handling here, added in the recent refactor
b0f4b4c94e, causes both of these
cases to behave wrong (displaying the error message, instead of
empty diff / captcha form).
Change-Id: I305e8ca9ff769c229a93d5fb3307e545a0227f2f
loadFail can result in a retry, in which case it isn't
approraite to reject this promise. Also many of the code
paths call 'tryTeardown' which itself will reject the promise.
Bug: T238332
Change-Id: I366662847304d8ecf79d5899b2804dded67ee999
* Add a postWikitext method and split out postContent
from postHtml
* Move saveSuccess handling into postContent promise
* Connect promise directly to saveComplete instead
* Pass whole response.visualeditoredit object, instead
of splitting into variadic arguments for saveComplete.
* [DEPRECATION] Make serialize return the postHtml promise
and deprecate passing a callback.
Change-Id: I905737515578000b2b87214c92e8b9fe9e82f6b7
New changes:
be8235e82 Localisation updates from https://translatewiki.net.
6f43a6c8d Remove MW-specific code for setting up section editing
Local changes:
* Bring in section editing logic from VE core
Sets attachedRoot iff there is only one SectionNode in the whole document.
Change-Id: I15b5ebf3848482ef6df6d19114d26a1b1d4a3b13
If the paction=serializeforcache request fails, we were erroneously
converting it to a successful result with no value, which later causes
an exception, because since 381b58585c
other code expects the result to an an object.
The bug was introduced in 2015 in 07001001be,
but until that recent change it would only cause a 'badcachekey'
error, which was handled correctly later.
Change-Id: Ie1ffc8c3e616a7d296f2186fb17eaf039971a44f
With this patch, the toolbar slides into place place nicely after
scrolling again, but it still occasionally flickers during the scroll.
* window.innerHeight is now smaller or something, and we have to
twiddle the scroll position by a larger value.
* document.body.scrollTop no longer works for setting or getting the
scroll position, so use different methods.
* requestAnimationFrame() now generates an insufficient delay to make
scrolling happen, so use setTimeout() instead. We actually have to
add a nonzero delay there, otherwise the toolbar sometimes doesn't
animate like it should or flashes in random places on the screen.
This delay is bad because the user can't start scrolling again
during that time, but I think we can live with that.
Bug: T233470
Change-Id: I6c40ee8ce5994e12eadb085bbffd120ef160d4ee
New changes:
4af3f84f7 Mark surface as "showAsDeactivated" when opening a window
79eb0e4e5 ve.ce.Surface: Guard against focusing a un-initialized surface
4124c275e [BREAKING CHANGE] ve.ui.TargetWidget: Construct a real target inside the widget
Local changes:
* Use new target widget
* Remove calls to deprecated methods
* 'surfaceReady' event was upstreamed
Bug: T236400
Change-Id: I765d657c172d96c3b2e2ae5998083e4926a31f15
As of commit c65ed0e7a8ac5f32a3a6e4cb2760dae03e4fca22 in MobileFrontend,
it uses errorformat=html queries (the same as we do), so we no longer
need to massage the responses to make it happy. The same commit also
turned parseSaveError() into a no-op, so we can remove that as well.
Change-Id: I4f0109ce120ebf94e5709d47d775a8178ce216fa
Previously, the ve-mw/init/ directory contained two kinds of files:
those that were used when initializing VE, and those that may be
loaded even if VE is not going to be initialized at all. The latter
kind must not use the `ve` global variable.
After moving those files to ve-mw/preinit/ we can enforce this with
.eslintrc.json in that directory. This would have prevented T228684.
(Technically they merely must not use `ve.init`, and may use `ve`,
but that's harder to enforce. We should instead move the few non-init
methods out of `ve`: now, track, trackSubscribe, trackSubscribeAll).
Also, group some files under ve-mw/init/: targets/ now (only)
contains ve.init.mw.Target and its subclasses, apiresponsecache/
now contains ve.init.mw.ApiResponseCache and its subclasses.
Bug: T228684
Change-Id: I945249a27f6a0fa10a432d5c5dc57bc7e0461fd8
The call to selectFirstContentOffset() below would re-activate the
surface and (attempt to) show the keyboard if the surface was
deactivated, but not shown as deactivated.
This might have worked correctly by accident before
I39fe44eee8eab7129340bcff796b6b9b3a59a398 in VE core.
Change-Id: I500309cc0aa8cd794175ae683a17c2614fd58cc9
Some post-save scrolling would try to access the view before the
handlers were cleaned up.
Bug: T232347
Change-Id: I30433ef027c52d541351972f8ebb09fe6d45e436
As of I6c043e039fbef62a56f475b0dc365e171ab7bf59, this method is never
called. It was previously used to update the size of the toolbar when
context menus were displayed inside it, but they are now displayed
elsewhere.
Change-Id: I53030de1203a7f0d75780ae796bbb10082d5ef7a
