It turns out anonymous users can't apply change tags, so change
I2c1d0f8d69bc03e5c1877c790247e165f160e966 broke editing for them.
Bug: T242184
Change-Id: I7c27e4d9995428e213a980819810f235fdfe9435
New changes:
fb4f0a83b Completion framework
Local changes to wire in the completion framework
Bug: T232601
Depends-On: If6aee9df67e7a1234d47c0ba0c2f05ef47e5bd51
Change-Id: I075cac9aa195574c3d416a40bbdc5ec2d64424e2
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
New changes:
06ad0c769 git-build: Fix name of grunt.log.error
6bed6aaa5 CommentAnnotation: Replace 'reply' with 'comment'
Change-Id: If7e298eaafdd7cf9ab07b6314cb9c214a2072229
It is possible, but very rare to have more than a single hook handler
per hook in a single extension. The value can be an array or string in
both version 1 and 2 of extension.json.
Change-Id: Idab5bb1ee606fe07c0886c8f6ae180bad1f9a4e3
ve.track.js was being loaded twice, once early on as part of the
ext.visualEditor.track module, and again later on as part of the
ext.visualEditor.core.utils module (which it was added to by b676b22).
This caused ve.trackSubscribe()'s buffer to be reset. Recording the
first init event relies on this buffer, because it's logged with
ve.track() before the logger subscribes with ve.trackSubscribe().
Subsequent init events did get logged. Some performance logging during
initialization was also dropped, but the 'ready' event and subsequent
events were logged correctly.
Fix this by loading ve.track.js only once, as part of the
ext.visualEditor.track module. Make ext.visualEditor.core.utils depend
on ext.visualEditor.track, rather than also adding ve.track.js to it.
Change-Id: I781595d27edb2dc0ad662fcc8e3c7cb0ddae78f1
Requires unregistering MWLinkAnnotationInspector
Bonus: Remove unnecessary list of unregsiters as
teardownOverrides is run on init.
Change-Id: I3e36ab7736cc8479ab53f40d2eb24c0fa15d3dc0
New changes:
8cbedc3c8 build: Update linters
a211e9fd8 TargetWidget: Use surface view focus/blur events
57aeb8b38 Separate utilities required for DOM parsing into separate file
Local changes:
* Setup modules for new parsing utils files
Change-Id: Ie4e59650fdb869e7e4148c97cd03d79ce35187dc
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
Follows-up 35eead0f3. This caused an extra stylesheet and HTTP
request to be added to all page views, because
'ext.visualEditor.desktopArticleTarget.noscript' is a styles
module, which should be allowed to join the regular batch.
Also remove it from other styles-only modules known to be loaded
with addModuleStyles().
Bug: T233095
Change-Id: Iea1f33199ec8dc83a42ac7102595a033300e33e6
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
When saving fails for a reason we don't handle explicitly, the error
message will have HTML formatting and will respect any on-wiki
overridden messages, rather than being plain text generic message.
Extensions providing custom SaveErrorHandlers may need to be updated.
The only one in Gerrit that requires a fix is TitleBlacklist:
Ibeae79c95557a7af699716c9d921f34c310bee6d.
* Remove handling for errors returned in .visualeditoredit.edit.info
rather than .errors (.error in old format). AFAIK this is only used
by some extensions, it is probably incorrect to do (T229539) and all
extensions I know of that do this (AbuseFilter, SpamBlacklist,
ConfirmEdit) have custom SaveErrorHandlers.
* Remove custom error messages for 'readonly' (identical to API
response) and for 'hookaborted' (very unhelpful and there is a
chance that the API response is better, if the extension causing
this error generates any error message).
* Add a silly shim for MobileFrontend integration, because we allow it
to handle error responses, and it expects them in the old format.
This is probably subtly wrong in many ways, but MobileFrontend code
only uses this for logging, so it shouldn't explode. In the future
we will hopefully change it to use errorformat=html (T228897#5366960).
Bug: T229532
Change-Id: I3b9c4fefc0869ef7999c21cef754434febd852ec
New changes:
28aea2e4d Edit cards v2 design
739017973 Track usage of the new "close context" button
Local changes:
* Edit cards v2 pull through
Bug: T222396
Change-Id: I1ca885e8d8127e7827a059755315ed789a7b9210
New changes:
a06204317 Fix TableNode unit test getOffsetFromCoords failure on Firefox
dfe0eb025 Refactor mobile context logic into ve.ui.MobileContext
Local changes:
* Pull through for edit cards refactor
Bug: T227532
Bug: T228767
Change-Id: I6c043e039fbef62a56f475b0dc365e171ab7bf59
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
We also show this dialog on the old wikitext editor, where
ve.init.target is not set, because the relevant code is not loaded.
Follow-up to 478b0bcbb9.
Similar to e88cd81f94, which fixed the
same issue in a different file.
I checked all uses of ve.init.target in files under ve-mw/init/ and I
think this was the only remaining mistake.
Bug: T228684
Change-Id: I15551870cdb01d570e24ba9668e67330b8072e01