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
I'm trying to track down possible values of 'result' for client-side
error handling and this was confusing.
Change-Id: I325249f7c57936c9c11a1d3dc9166b1ca3737c39
* 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:
ce76e95d4 Allow config to be passed to mock surfaces
12e2d2686 tests: Put FragmentInspector test runner in shared util
Change-Id: I426ae2cb96ca8dd126656c018740ec122007c2ff
Requires unregistering MWLinkAnnotationInspector
Bonus: Remove unnecessary list of unregsiters as
teardownOverrides is run on init.
Change-Id: I3e36ab7736cc8479ab53f40d2eb24c0fa15d3dc0
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
New changes:
69fc4fdd7 Tweak alignment of frameless button in desktop context further
Bug: T237289
Change-Id: Ia315c96b22ac2ed8728dd2e90d02100655194df3
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
This means the multiple lines of html (e.g. '<p>a</p><p>b</p>') are
treated as plain text and only separated by one linebreak.
Bug: T201561
Change-Id: I83b98e41bfd92d1848557b58f961abdd0db26294
New changes:
18e32c6ed Simplify paste test runner
7d71154bd Properly support middle click paste
Local changes to use simplified paste tests runner
Bug: T157956
Depends-On: Id66bff4e41a36ed967a8cba2f6653bb26e7b4ea1
Change-Id: I0101e8bc079cd050bfbc65577a10e98213d5f00c
New changes:
fdc0d734f Localisation updates from https://translatewiki.net.
1ab9a6349 Fix DM jQuery linting
ed97c7d11 Localisation updates from https://translatewiki.net.
5f0d866a0 Fix alignment of frameless button in desktop context
3a1d641f7 Replace color with WikimediaUI color palette one
fac4d2e72 Remove toolbar borders from mobile
fbeb687c8 Reduce size of PopupToolGroup indicators on mobile
Bug: T231815
Bug: T237289
Change-Id: I4709f1cdc558e4aa4fd6674a5f3bde617cec4614
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
