I'm trying to track down possible values of 'result' for client-side
error handling and this was confusing.
Change-Id: I325249f7c57936c9c11a1d3dc9166b1ca3737c39
Follow-up to 57ad605dc4.
Pass parameters like when switching from wikitext editor:
* bodyOnly=false
* stash=true
Bug: T233320
Change-Id: Ied2d9a48e884e033ef9d41b2da9cfa3599784ae0
Previously we were not returning it, so when saving the edit, wikitext
syntax would not be preserved. This was probably not a big problem,
but I noticed it coming up in the logs for T233320.
Now making an edit starting with preloaded content behaves like
switching from wikitext to visual mode, rather than like starting the
edit in visual mode.
Similar to 679e777cfa.
Bug: T233320
Change-Id: Id1ee6877b103fa4274deec11b1b3cacbdcdae606
The configuration of Wikimedia wikis should be fixed.
This reverts commit 04407e9eb1
and also makes similar changes to new logging code added in
5d1a67757a.
Bug: T234564
Change-Id: Ic999b050e68b71f5a1737366e16f133e5a557307
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
For consistency, I guess. Also I need this in I2ef0ca8725.
Previously, when querying the HTML content of an existing page, we did
not return the 'etag', on the assumption that anyone who needs it will
instead query RESTBase directly.
Bug: T233320
Change-Id: I463a84de631598243893946ad1d060a9aa0b180e
The 'eye' icon is in the 'accessibility' pack, not 'alerts'.
Compare to the dependencies of 'ext.visualEditor.diffPage.init'.
Change-Id: Ie14ab6be756fd9e0bef59475466674a41273046f
No longer needed after Id36aa6bdb8f873fe7deb8123a7fc774103721c01,
which teaches SpamBlacklist to return its own error messages.
Depends-On: Id36aa6bdb8f873fe7deb8123a7fc774103721c01
Bug: T211443
Change-Id: I462c2002f9b596cbdfd7ce3673d4e362e5bd1aaf
Unnecessary suppression causes build failures. Probably fixed by the
EditPage.php changes in e2e543f7c2a98f40c9b43ba3989d0f6689f4cb67.
Change-Id: I2ac7e95886ce6bef2ba08e1614728caae7d26442
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
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
* Change the query in ve.init.mw.ArticleTargetLoader#requestParsoidData
so that in non-RESTBase mode with wikitext it still returns the
metadata required to initialize the editor, using the backend API
code added in I1b35b28e428a1f86d2e34d90ddbe73361ce14818. This fixes
the exception from T222312.
* Introduce new configuration option $wgVisualEditorAllowLossySwitching
to control this feature. It is enabled by default, fixing T214542.
We allow it to be disabled because switching in non-RESTBase mode may
cause "dirty diffs" (non-semantic changes to the wikitext), which are
undesirable on wikis where users carefully review all changes.
Bug: T214542
Bug: T222312
Change-Id: I58879cba5612002c70c24731306214d2577c2c52
In general action=edit could be bound to a wikitext-specific
edit link, but in the case of redlinks we can use the
preferred editor instead.
Bug: T223793
Change-Id: Ib0851e9e2ce441ae93311153801e2c3de0a2063d
We don't currently support it in NWE. It has a very different design
for previews that wouldn't really do what users expect. Let the old
editor handle this.
Bug: T195914
Change-Id: If0c0312347c212447bd8da7336c80bd4a1cb246a
There are various circumstances where the wgIsProbablyEditable check
gives incorrect results (hence the 'probably'):
* User is blocked (T111217)
* Page is protected from creation (T173763)
* Page is transcluded on a cascade-protected page (T217217)
Bug: T111217
Bug: T173763
Bug: T217217
Change-Id: I7df8909c31f29d2e7521bef8612c27cb61146a4d
Prior to 80bfbfc54b this worked by
accident, and with a number of bugs depending on your settings (see
T219457). It turns out that Wikipedia users have invented various
workflows that depended on this bug (mostly involving sandbox pages in
namespaces where VE is not enabled). Restore it as a supported
feature, and in a way that avoids the problems it previously caused.
Bug: T221892
Change-Id: I62714b6f2905efd1d1b34c7a13b9917cb6c609fc
Use an API 'parse' call with a sectionid to trigger
a full document expansion using replaceSectionAtRev.
Then send this off the RESTBase to convert to HTML
and statsh.
Ensure the etag is passed back to the API response.
Bug: T117716
Bug: T223023
Change-Id: I1b35b28e428a1f86d2e34d90ddbe73361ce14818
This is necessary to allow the unmitigated removal of
ApiQueryUserInfo::getBlockInfo to be fixed. See discussion on
I84ed21641c44b2f65.
Change-Id: I9f40666a31bd4af50762c197c2ce5bf089a5e68c
The method ApiQueryUserInfo::getBlockInfo() was removed in unannounced
breaking change in MW core: I84ed21641c44b2f65ebe1980b0893d1846db3b34.
Apparently we're supposed to use the method from ApiBlockInfoTrait now.
Bug: T209599
Change-Id: I7ab5492310980b1527c7329faf65655330b8bef0
RESTBase is changing the way it is storing HTML/data-parsoid renders. In
order to still support VE (and other editors) with quick access to HTML
and matching data-parsoid (needed later for transforming the modified
HTML to wikitext), VE now needs to let RESTBase know it intends to
perform a transformation call later on. In that case, RESTBase will make
sure to keep the matching data-aprsoid around for long enough.
Bug: T222639
Change-Id: I02672e29bd0f331794fd77d9e56f9cc6822d9b9e
Is replaced by MediaWikiServices::getInstance()->getConfigFactory().
Also, did a few minor cleanups where necessary such as; objects are
passed as references by default etc.
Change-Id: I42cd242ebdbc0b091a99e771289020d498bf2bba
Mobile builds its own block message from the block information,
rather than using parseAsBlock.
Bug: T209599
Change-Id: I8b200f258b50f7048aded22ec7ab81a49937c5a9
This is a clean up after collecting the necessary data related to
blocks and how often users see the block notices
See: https://phabricator.wikimedia.org/T189724
Bug: T214214
Change-Id: I532a0cd95009109ba25caa8dd31badd5c1900da7
This check currently requires LCStore, MessageCache, and (sometimes)
Database to involved to check whether the message and/or local override
exist.
Using `useDatabase(false)` should take away most of this cost
by no longer performing the multiple Memcached/Database roundtrips,
and leaving only a cheap in-process check on LCStore.
Bug: T221294
Change-Id: I6bf47cd84cdf9bfdd63bee0a613425bb79595e4f
The latter is being deprecated as of I74a9535918e because it was
almost never used intentionally. When module objects are created,
the appropriate context object is injected via setConfig. That is
the one the modules should use.
The context object has a reference to the ResourceLoader object
(although unsure why actually), but shouldn't be used for this
purpose as there could be a 1 to many relationships further down
towards modules.
Change-Id: Icab0f12141a46476618f984d4548a82fdae33275
For a while now, the 'ResourceLoaderRegisterModules' hook is
the last oppertunity to register modules. Therefore, the
isModuleRegistered() check covers everything it needs to.
In addition, at this point modifications to ResourceModules would
be ignored even if it did contain additional entries.
Change-Id: I77714fca0f561f5817a45dd3be5fd8d3ba42f969
These do not vary by user or page, and can thus be loaded asynchronously
via the startup module, rather than blocking rendering and fetching
of modules on all pages.
In a future change, it might be better to go a step further and bundle
these with a module so that they only load as-needed instead of still
on all page views, but this should be an improvement nonetheless.
Change-Id: Icae3712ac5546a90bc7ffd787b0f3285dff6a26f
Remove overkill $VisualEditorSerializationCacheTimeout config setting
and just use a simple constant instead (convention over configuration).
Bug: T203786
Change-Id: I94424088a03a3262fcea30132883a612465c546e
When this code was written in 2013 (1a5bdd5bd2),
the langlinks API did not have a way to return the language names (autonyms).
This has been added in 2014 (4ba3a9aea96ee21c035c69999be23580e23f4e0a).
Change-Id: I70edb846d94b1108b079caf5915532234190da8f
Using DerivativeContext also makes the code easier to read.
getContext() returns an IContextSource, in this interface has no
setRequest() method and this can fail for some kinds of IContextSource.
$view is a ContextSource, which implements setContext().
This also allows us pass in a new context with the right request object,
and also to set the title so we don't have different titles
on $view and the main context.
Change-Id: Ia575cd6163defeb423a542e342034cac5eb6108c
Generating the templatesUsed list is relative slow, and is only
used in an obscure part of the editor, so only generate it when
needed.
Bug: T209078
Change-Id: I1cecdad65b80c4c9b1746e752ea4b41bc0fc0037
Red-link metadata was added to Parsoid 18 months ago.
On long pages evaluating this information is very slow
(hundreds of milliseconds) and completely redundant.
Bug: T64803
Bug: T209078
Change-Id: I5b6c6da588301ed59fb21e1ce930f5b72db48e67
The following sniffs are failing and were disabled:
* MediaWiki.Usage.DeprecatedGlobalVariables.Deprecated$wgParser
* MediaWiki.Usage.DeprecatedGlobalVariables.Deprecated$wgTitle
The following sniffs was renamed:
* MediaWiki.VariableAnalysis.ForbiddenGlobalVariables.ForbiddenGlobal$wgTitle
Change-Id: Iabe2a787bae7fe299bed548c0097613ff5493a0d
onDiffViewHeader() method returns a void per "return;" which is valid
from PHP 7.1 and above. This method doesn't return bool per it's definition.
Change-Id: Ifee65dfce3af104d89ba3c91602501da6bbbc20c
Show log extract if the user is sitewide blocked or is partially
blocked and not allowed to edit their user page or user talk page.
The check on the block type is being added to keep it in sync with
what it is currently being done on core.
Bug: T203171
Change-Id: I00ebb5cbcb1ec14e778c2936187cbcebc0829163
* Also make sure block notices have type 'block'.
* Remove old flag for tracking since we'll be using one
from core
Change-Id: I4b66e73c8a4c4dd7bffd7c0239b1d5ec06eed12f
Depends-On: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
When an edit notice is passed through from the API, allow
a type to be specified, and specify type 'block' if the
notice is a block notice.
If VisualEditorTrackBlockNotices config is true, track
when a message with type 'block' is shown.
Bug: T209633
Change-Id: If5fecc2c2c1c39f4b7245b9a215e1120c93b2b22
Tracking is behind $VisualEditorTrackBlockNotices config flag
which is set to false by default. Additional data will be logged
into a different bucket on the client and both metrics will be
considered with their known limitations.
The reason behind this is to get an idea on how frequently blocked
users attempt to edit a page. Similar tracking is being added to
MobileFrontend and mediawiki/core.
Bug: T201718
Change-Id: I51576276b97be0716c2c22348eaa756ffb04fe50
Our behavior is now closer to the core wikitext editor.
This results in two minor changes:
* `<li>` elements are now correctly wrapped in an `<ul>`.
* "View full log" link is now only shown if there are more entries.
Change-Id: I3f30446fca5cab83155ce26ee4e5ab213fc5847a
New changes:
a2dff3032 DesktopContext: Don't rely on selection#getDocument
4c1cc1640 Basic test for WindowAction open/close
0ab1e754c Update OOUI to v0.29.3
a8d96b850 Localisation updates from https://translatewiki.net.
b4fa3d230 ResizableNode: Add test for updateSizeLabel
caf188be0 TableNode: Test basic mouse events
Bug: T208228
Bug: T208382
Bug: T208515
Change-Id: I0db7b5e874ad6b23dad1f29bb1a58e126fea7a48
New changes:
0e923fe1b Use initClass in test class
900962720 Add ve.deepFreeze for detecting inadvertent data modification during testing
0761cd90c Localisation updates from https://translatewiki.net.
0e44545b7 Update .gitignore
82b6b80bb Use consistent method for finding nearest cursor offset
0b604de30 ve.ce.TableArrowKeyDownHandler.test: Remove eww gross FIXME
Bug: T202359
Change-Id: I73c46edfbf66a0c76bc719010c017ef71670931b
New changes:
7c9fe89b8 Simplify ve.test.utils.runSurfaceHandleSpecialKeyTest API
0e3c75e66 Add more tests to LinearArrowKeyDownHandler
058362830 LinearArrowKeyDownHandler: Test Selection#extend fallback
8c6617d90 Keydown test refactor
91a909d63 Assert defaultPrevented state in KeyDown tests
003dacf3b LinearDeleteKeyDownHandler: Test shift+delete
1872158c5 LinearDeleteKeyDownHandler: Test delete next to link
b2af2a2c3 LinearEnterKeyDownHandler: Add more tests
4e5efa956 KeyDownTests: Remove unused constructor calls for all static classes
1cafb7328 KeyDown tests: Add tests for missing cases to cover tab/escape/enter
58af8d497 Add tests for ve.ce.AnnotationFactory/NodeFactory
617bc24a4 Delete unused ve.ce.modelChangeFromContentChange
50704fa1c Keydown tests: run asynchronously
af9a01b97 Use native promises instead of jQuery promises
df212669a Localisation updates from https://translatewiki.net.
f6af901dc Fix test in Chrome 70
9cc6dae7e Remove broken checks for DM code coverage
ce3a9199a LinearEnterKeyDownHandler: Add test for edge case
0a9dd3636 Remove false coverage of TableNode/TableSelection code
16679a3c0 Remove setupToolbar from DummyTarget to avoid false code coverage
7ac88df77 Basic tests for getClientRects in ve.ce.Selection and FocusableNode
78f14ac1f ve.ce.Selection: Add getDirection tests
7ec7efff0 KeyDown tests: Remove unnecessary setTimeout
26e022d23 KeyDown tests: Un-nest functions
df1e0af6c KeyDown tests: rename defer -> then
f03a9f90b Allow ES6 in tests
0ee55022b ES6 eslint follow-up
6c288b44f ve.ce.Surface tests: Trim when asserting expected text
Local changes.
Bug: T207077
Bug: T207078
Bug: T207079
Bug: T207080
Bug: T207083
Bug: T207654
Change-Id: I2e1f664d6f657e2ac26a271f401dc790c2a8b193
Whenever wikitext content is inserted by the hook `EditFormPreloadText`,
it is always parsed to visual editor markup even when in wikitext mode.
Bug: T206838
Change-Id: I56f0fb9d4e1519af01155c35d4d0068076de4600
New changes:
3931cc33a Update OOUI to v0.29.1
5bcab0073 Move node-specific code into rebaser/
8aa80d88b Remove ES6 support for async/await
2536870f9 Separate files for protocol and transport server
b443b7a4f Update OOUI to v0.29.2
70b3ec210 Minor cleanup of ve.ui.MediaSizeWidget
Bug: T206236
Change-Id: Id3bbcd1a9ccb1563e4feb3572aa8f51932677693
New changes:
a273ba69c [BREAKING CHANGE] Implement a SourceConverter
Local changes:
* Use SourceConverter
* Handle `this.doc` being a string in source mode now
Bug: T203114
Bug: T203156
Change-Id: I7bce7b57668e0c1dd511803a54178ae69694a86d
New changes:
fa5d35054 Only re-use session token if docname matches
58d7cd280 Localisation updates from https://translatewiki.net.
d0716d8e7 Update files generated with new l10n language 'my'
2cc7a4423 Create unit tests for sequences
873fdd01e Upstream horizontalRule sequence and fix command
Local changes:
* Register unit test file for sequences
* Remove duplicate horizontal rule sequence
Change-Id: Ibc65cf5c086428bb0d13c8e2f2de5819e1e23d43
New changes:
cd6932096 Fix rebaser dependecies
bdcbf8f81 Rebaser: make the server synchronous again
52e6873b1 Cleanup rebaser
31ef4c5ec Handle authentication and reconnection
22d6feea3 Squash Changes to use fewer transactions
4d93f0819 Fix confusion between #getSetupProcess and #getReadyProcess
8d0ab0587 Localisation updates from https://translatewiki.net.
Bug: T185745
Bug: T185944
Bug: T188026
Change-Id: Ie33d3dd4746c9c91fe676f140f416af72ac218b0
Replicate the EditPage#showIntro segment which shows a warning and the
deletion log if attempting to recreate an already-deleted page.
Bug: T199087
Change-Id: I3c680e712c010dc614710b3aa9f41c8ec17999a7
I can't see where this would return a string, but users are reporting that
they're getting that at times…
Bug: T193718
Change-Id: I6b635bacdd59431568bc5c679e455f67cb764df0
New changes:
aa8b2d3da rebaser: Clarify document name is optional
eb4955b84 $.isEmptyObject -> ve.isEmptyObject
681fa50e1 Don't use $.isNumeric in DM
0c8483d8a Avoid more jQuery in DM
a9f6bef78 Replace $.extend with ve.extendObject
34eb4311d Initialise socketIO twice to avoid query cache
b70cb7520 Teardown synchronizer
8f829895f Use passive event listeners
f9e84fa8b Localisation updates from https://translatewiki.net.
db24bb81c ve.ce.FocusableNode: Fix minor code issues
ae981404e Rebaser: show connect/disconnect in the server console
0118e89c2 Show progress bar while connecting to rebase server
160bbe5fd Use new name for 'comment' icon, 'speechBubble'
fb549248a Remove unused APIResults* objects
5daa71d7e Remove IE9 support comment
Bug: T178371
Bug: T195111
Depends-On: I186ebd9d63299d828692a745b62fbc4314a4ed4e
Change-Id: Ie0fee3d4cc069383b8cb48e7d6c2ff520fedb590
"ORIGIN_USER_SITEWIDE" indicates "sitewide module generated from
user-editable files, like MediaWiki:Common.js". In this case the
JavaScript generated by this module is not directly editably by wiki
users. It includes localisation messages editable by users, but that
is considered safe because we correctly escape them when including
them in the JavaScript code.
Without this change, VisualEditor would no longer load in safe mode
(T185303) because this module would be missing.
Bug: T185303
Change-Id: I6d097ccbf1dc2462843219adcf96bf8313e30289
Wikis with a local link over-ride configured will need to do so here
for the new message `visualeditor-sourcefeedback-link`; wikis with a
remote link configured will need to update their configuration ahead
of this being deployed, setting $wgVisualEditorSourceFeedbackTitle.
Bug: T157953
Change-Id: Iea7ad8328b03f69e01d7c67ca1ddbb7ae7906288
