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
When a template does not have user-provided TemplateData documentation,
the TemplateData API falls back to extracting possible parameters from the raw wikitext
to generate an API response with a list of potential parameters. However, it also
sets the "notemplatedata" field in the response, causing the VisualEditor to think
the response contains no useful information and ignore it. This appears to have been
an unintended side-effect of I97a1bfc9f9ead082a673a91b9d2053630a90309c.
This patch ensures that the VisualEditor will correctly consider such responses from
TemplateData by modifying ve.dm.MWTransclusionModel to check if the response contains
a parameter map. Some unit tests were added for the class to verify this behavior.
Bug: T243868
Change-Id: I72005880d9301a53224473900efe2917379e8708
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 mw.libs.ve.diffLoader#fetchRevision was calling this method, we
were accidentally making no query at all if RESTBase wasn't in use.
Change-Id: Ia98343aa1ba7f4f3be0c1a8ee5864653c429fb82
In many places we check whether VE is available before doing things
(init.isVisualAvailable). This variable includes checks for whether
the page is wikitext, etc. Now it will also include checking whether
VE is enabled in user preferences.
In almost all places where init.isVisualAvailable is used, we were
already also checking if VE is enabled, so this doesn't affect the
behavior. But notably, we didn't do it when showing the option to
switch to VE in the welcome dialog and in the toolbar, causing T243723.
Changing init.isVisualAvailable this way makes it consistent with
init.isWikitextAvailable, which has always included a checking whether
NWE is enabled in user preferences.
Bug: T243723
Change-Id: Ie174bc3f16bceb29cb155b9223e0acef70167fd6
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
It's supposed to be non-editable but deletable text, like mw:Entity.
We decided to handle them this way in 2015 but never implemented it
(T94509). Currently, accidentally editing text inside of
mw:DisplaySpace node causes the changes to be lost when saving.
Bug: T241906
Change-Id: I78a0cc7a75061a7eefb8b677898b5756326615d6
New changes:
479b50059 Localisation updates from https://translatewiki.net.
c595d8ab0 Metion task related to Firefox hack
0a160fac2 Don't trust selections from the server
d796f3db5 rebaser: Update dependencies
b097dfaad ve.dm.Transaction: Don't translate offsets inside annotate-only replacements
eadee0343 FragmentWindow: Replace previousSelection with initialFragment
561e88158 Use ve.dm.example.imgSrc everywhere
d1dceab31 DesktopContext: Remove onModelSelect event
85947ac55 Pause synchronizer while staging
9a4dd169d Catch various out-of-bounds exceptions
341114afc Remove CE HTML from DM html test fixture
5d3a673e0 ve.ce.Document test: Add src to test image
182ac338e Evalutate fragment selection after staging
e032fa161 rebaser: Drop document opacity while paused
Change-Id: Id551ee2e6510610b8f2e12cf77ce3c8429700872
New changes:
d4a21a7e7 Localisation updates from https://translatewiki.net.
0e99d907a Update OOUI to v0.36.0
c422b8313 Localisation updates from https://translatewiki.net.
b1617fdca Update OOUI to v0.36.1
Local changes:
* Rename onLookupMenuItemChoose → onLookupMenuChoose
(deprecated in OOUI v0.36.0)
Change-Id: If66f3f16c0e882e99b0d768a3cf4170d24e7093e
TypeError: Cannot read property 'onCacheKeyFail' of undefined
(found when working on Ice92fafb1f546510dab28e3f8aa7d2280668965a)
Change-Id: I2a731cb273401074e65f9283c1f629dbdb272002
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
Cancelling the loading of the editor should stop the network requests.
Broken in 0498c03191. Forwarding the
'abort' function manually is the worst.
(found when working on I5146b726c5ce213992febb23f24c5937db0b9bfe)
Change-Id: Ifa7c11a433cb5ed3545fa2f3d9fae2800bcae7d7
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
Similar to WikiEditor, allow the editing_session_id value to be
overriden through the editingStatsId query parameter. Also allow
server-side code to override the session ID by setting
wgWMESchemaEditAttemptStepSessionId in mw.config.
Only apply the override to the first session. Once a second init event
happens, discard the overridden editing_session_id and generate a fresh
one.
Bug: T238249
Change-Id: I4ede70f310a35c95b6eb9cc34cfcf2baa77e69ee
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
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
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
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
Something is causing the 'ETag' headers produced by the "public"
RESTBase (queried directly from the client) to be mangled or lost.
My theory is that some proxy or browser extension is doing that.
When we detect a bad etag when fetching the page contents, discard
the result and try querying the "private" RESTBase via the MediaWiki
API (similar to what we do on private wikis, except there we talk
directly to Parsoid instead of RESTBase). After I463a84de63, that
returns the etag as part of the payload rather than HTTP headers,
and should pass unharmed through whatever is mangling the data.
Also compare and log the two etags.
Bug: T233320
Change-Id: I2ef0ca872597566f74b650aea71bf3f15747a6d7
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 ...target.wt property contains the wikitext used to generate
the template name. It can contain trailing newlines (T234817) and
all kinds of funny wikitext syntax. Instead, use ...target.href,
which is the title of the page that is actually transcluded. Compare
the new code to ve.dm.MWTransclusionNode.prototype.getPartsList.
Additionally, fix some confusion about namespaces (treating template
names as titles in the main namespace). The template names in the
configuration page (visualeditor-template-tools-definition.json)
now support overriding namespaces in the same way as in wikitext.
Bug: T234817
Change-Id: I7c557d28e961d0b9117fc0380c65cdd42035ae96
If you had an image thumbnail for a file 'Foo?.png' on the page,
ve.ui.MWMediaContextItem and ve.ui.MWMediaDialog did not escape
the '?' when linking to it, which resulted in incorrect links.
Similarly, if you had an internal link to the page 'Foo?',
ve.ui.MWInternalLinkContextItem did not escape it.
Additionally, the links were always generated as if the wiki was
using short URLs, even when it is not (T233628).
The approach using mw.Title is copied from ve.ui.MWGalleryDialog.
Bug: T233628
Change-Id: I10256ed6883dae0ea216de4c0719f03d7fd19ae4
* In normal images, parse relative 'href' attributes instead of
expanding them to absolute, and parse 'resource' to keep it
identical to 'href' if they refer to the same page (including
same percent-encoding and space/underscore). This resolves Parsoid
generating |link= options for copy-pasted images (T193253).
* In gallery images stuff, prefix the 'resource' attribute with './',
same as normal images do. This causes no functional changes, but it
makes updating tests easier, and the consistency is probably good.
* Update test examples to also prefix 'resource' and relative 'href'
attributes with './', like the real Parsoid does.
Bug: T193253
Change-Id: If2d7f080d9d693568054f8311c1e1b15ca27ea5c
* Handle mw:MediaLinks pointing to to non-existent files, which come
with typeof="mw:Error" (similar to image nodes).
* Fix regression from c66f8e0547, which
caused all mw:MediaLinks to be treated as plain external links again.
* Add test cases.
Bug: T232754
Change-Id: I9ae5bcfc4e24e8c0d22ef77d6a4d03f817fc9768
In order to get the desired padding, the `em` values were pre-multiplied
by the parent font-size, which was assumed to be `0.875em` for normal
surfaces and `(13.3333/16)em` for wikitext surfaces. (That should have
been `(13/16em)`, by the way, but that's a negligible difference.)
Unfortunately, the font-size for wikitext surfaces is actually `13px`.
Unlike `em`, `px` values are not affected by custom browser font-size,
so when one was set, the final padding was all out of whack.
Use `rem` units instead to respect the custom browser font-size,
without getting problems due to the parent element font-size.
We don't need separate rules for .ve-ui-mwWikitextSurface now.
Bug: T222217
Change-Id: Ib7ffbf09d5aa23fddb894aa3b081ec993ddcee2d
This meant we were returning invalid documents with bare content outside
content branch nodes. Instead let ve.ce.Surface in VE core do the unwrapping.
Bug: T232944
Depends-On: I8799d51958b966c99307f4c70546ea326e67385c
Change-Id: I0479116b51cc3135a992fdf36b8edfb2c44916ba
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
As of I2f2495ab6c10116a6660f4361e49272cb95b988a in MobileFrontend,
the overlay never uses the default spinner.
Change-Id: Ie0aa624e33a5bd21fc20459697cca175d9de5606
New changes:
d4cb2f03e Update OOUI to v0.34.0
b0b481693 jsduck: Stop listing OOjs in upstream, it's using JSDoc now
0b17a137b Update OOjs to v3.0.0
Change-Id: If29a97ce689523763431face5a13929a461735b4
The good thing is that every time our CSS overrides get less crazy.
See 75ff121b29 for the last time.
Change-Id: I9d81aff6a24ec28850563e00206e21c4a6593d2e
Context items can be created for specific template titles. Titles
are mapped to context items using an on-wiki message.
Bug: T211243
Change-Id: Icfc39e350452da238d0e0c17cb2305c60d9ca16a
Tapping the toolbar save button while the save dialog is open triggers a save
because of the accesskey. It shouldn't save on a double-tap, because that's
easy to accidentally do / trigger on a slow device.
Bug: T230816
Depends-On: I4c3afce9d57c9bca737272b40b9a4862b5794bac
Change-Id: I1925b1b97de6a811f73196b616ec09a2c30c336f
Depends on MediaWiki change I48d4bb3f, which adds the 'arrayParams'
option to handle explicitly indexed array parameters like
`&preloadparams[0]=a&preloadparams[1]=b`. Previously we only handled
implicit indexes like `&preloadparams[]=a&preloadparams[]=b`.
Bug: T231382
Depends-On: I48d4bb3fdf0ea7f5eb133c59bf63651ba356fc42
Change-Id: I8c899bce1b19fa286bd385f89e102a4b87db4db3
The double result creates more confusion that it clears up,
and now that the query input is always used for text insertion
it is less of an issue that we don't have a case-exact match
in the results list.
Bug: T230819
Change-Id: I58cbe740fa7d0327aadd5dd111161bb7087a4ddb
New changes:
77076f828 LinkAnnotationInspector: add a "label" field on mobile
Local changes:
* Updates for mobile link label editing
Bug: T229431
Change-Id: Ib0489f6f59b228ebc4a20f7a0a515be938a8f6d3
