Our coding style has been upstreamed and first released
in node-jscs v1.5.0 (grunt-jscs-checker v0.6.0).
Change-Id: Ifc0cfc7177946b9d11407f60e38b0177883724c5
This reverts commit b7401f838b.
Didn't break everything, but we should probably avoid this getting deployed until I can work out wtf is going wrong with it.
Change-Id: I048143239e998b30aba79fa395a0af1cb06c6a9b
This reverts commit 5565ccca54.
I have no idea what is going wrong on deployment-prep to cause
the error in bug 66792. Let's try to find out.
Bug: 50341
Change-Id: I5041de838128bb55c57baddae01cdcb263626537
Causing HTTP 500 errors in ApiVisualEditorEdit.php (calling
getDisplayTitle() on a non-object).
This reverts commit dedc89b5ff.
Bug: 66792
Change-Id: Iaf438660f0623dc05f76294ad847b2fc5e25bed6
Use new setupToolbar and setupDebugbar methods in base target.
New changes:
7ff523d Localisation updates from https://translatewiki.net.
3815224 [BREAKING CHANGE] Debug bar refactor
155f4ab Edit HTML mode in demo
Change-Id: I554ce51eae872ab0f741a913bf10394c2a8c3e52
Replace instances of target.$document, which was removed
in VE core.
New changes:
8083623 [BREAKING CHANGE] Remove $document cache from target
9256158 Cleanup target properties
cc0d71f Multi-surface fixes
ba8872e Localisation updates from https://translatewiki.net.
Change-Id: Ibff83cae770c056ed64bcf438ed74b44d929cdc0
The API moans about it in a warning, but it works.
Along with edit page checkboxes, this also fixes edit notices.
Bug: 65455
Change-Id: I7c319d43fd06ab04ab4e4cc099ae49b11c31fabd
No need to set in mw.Target as it now exists in core Target.
Add config param to MobileViewTarget override.
Depends on I555935d2 in core.
Change-Id: I72be9098bd9d59272ca3d7a9a64dca4271ef3ee5
jshint:
* Update to grunt-contrib-jshint v0.10.0 (jshint v2.5.0).
* Remove coding style options covered by jscs.
* Enable new option "freeze" (prohibits changing native prototypes).
http://www.jshint.com/blog/new-in-jshint-oct-2013/#option-freeze
* Re-order to match http://www.jshint.com/docs/options/
jscs:
* Update to grunt-jscs-checker v0.4.4 (jscs v1.4.5).
* Format .jscsrc file in a more spacious way and order the
properties less arbitrarily (using the jscs's readme order).
* Enforce more details of our coding style
* Get rid of the unsable "sticky" operator rules which have been
deprecated in favour of using other rules instead that are able
to enforce this more accurately.
- disallowLeftStickedOperators: Remove deprecated rule.
* Ternary covered by requireSpacesInConditionalExpression.
* Rest covered by requireSpace{Before,After}BinaryOperators.
- requireLeftStickedOperators: Remove deprecated rule.
* Comma covered by disallowSpaceBeforeBinaryOperators.
- requireRightStickedOperators: Remove deprecated rule.
* Logical not (!) covered by disallowSpaceAfterPrefixUnaryOperators.
See also If46b94ce1, Ib731f11b1 and I0b0cadbc5 in oojs/core.
Also:
* Update grunt-contrib-watch to latest upstream version.
Change log at https://github.com/gruntjs/grunt-contrib-watch/blob/v0.6.1/CHANGELOG#L1-L17
Change-Id: I6c5a34afea8b05a3dca617897c192594df06ca90
Usually we can just send 0. Sending anything else makes PostEdit think we're restoring an old revision.
Bug: 65269
Change-Id: I60454a7a4ea3f6c7cef4c707da3016dd0ec29b88
There was a slideDown() call, but this didn't do anything since
toolbars are visible and in the DOM by default.
As a temporary hack, hide it synchronously after creation and
then do the slideDown still.
This could ever so briefly cause a flash, though that didn't
happen in my testing.
This makes the experience smoother when we initialise the surface.
In particular the moment where we swap #bodyContent for our Surface
(which should look visually almost identical), before this change
it was still a bit of a flash since the Surface version has a
toolbar on top, and thus instead of swapping smoothly, we hide
content and show a similar piece of content that has an incompatible
offset from the top.
Bug: 64751
Change-Id: Id94974ba71fd887ce494d7b2b16ec62d43b18575
Update VE core submodule to master (109a3cf):
* 109a3cf ve.ce.Surface: Remove font-size: 1em;
Follows-up I5818dce6265.
* When applied to ve-ui-surface, it applies to both of its children,
namely ve-ce-surface and ve-ui-surface-overlay. The latter
(containing things like context menu and inspectors) should not
inherit styles intended for rendering of wikipage content by
the skin.
* Move mw-content-{ltr,rtl} from an outer parent to a slightly
deeper parent of the actual content. It's now on documentNode.
Still high enough to apply to all content. This was to ensure
it remains a child of mw-body-content, like in MediaWiki core.
* Updated padding/margin hack again. Since now the font-size
applies on the surface, this once again means that now 1em
on the surface != 1em on the documentNode, so we need the
calculation again. Brought it back and this time documented
what it is based on.
Bug: 64599
Change-Id: I9ee4582a6a0ec9e128f5c36a6dbf2adbd0b216a1
Also get rid of checking for NS_MEDIAWIKI explictly and use
MWNamespace::getRestrictionLevels instead
Bug: 50783
Change-Id: I5986ddb9b6f17e4a2aca12dbb551cce4a6cfd663
* font-size and line-height differed between read mode and
edit mode. This makes them match by using the same css class
as MediaWiki core uses for the body content.
Depends on I66c56c57 in MediaWiki core.
* Document padding / margin hack on surface, and sync the values.
In edit mode, the text was being nudged to the right by a few
pixels.
* Bump the wfUseMw call as this is a symptom of how VisualEditor
now depends on MediaWiki 1.23.
Bug: 64599
Change-Id: I5818dce626545c4cbc8bd84fd551dc08baedbe32
MathCaptcha just extends SimpleCaptcha, so its output is fine to show as
text. Doing that because I'm not sure how to render TeX and this is a
reasonable fallback
Also tidy up the order of some message entries in my last commit.
Bug: 64328
Change-Id: I98312f61471667e7c4dcf715295f85642c31a688
When recovering from a badtoken error, mw.Target called saveDocument(),
but that method only exists in ViewPageTarget. Instead, call .save()
again.
Also pass the HTMLDocument and the save options around to the success
and error handlers, because we need them in order to be able to
call .save().
Bug: 64267
Change-Id: I4743f855dc77f4a9ac427d67d15fb96b7ad770f2
Update dialogs and inspectors for breaking change in VE core
New changes:
a553012 [BREAKING CHANGE] Merge dialog and inspector actions into window actions
f9a0419 Localisation updates from https://translatewiki.net.
cbe81a0 Fix path to spinner in ve.ui.SpecialCharacterInspector.css
Change-Id: Icf90ace6442364283b66b234e3c78fc65212f070
Move various bits of code from initialize to setup as required.
MWDialog is now useless so use ve.ui.Dialog directly.
New changes:
0b2d03f [BREAKING CHANGE] Pass fragments, not surfaces, to windows (reprise)
0101ac4 Update OOjs UI to v0.1.0-pre (ac6848398c)
Change-Id: I0fae3e5ff2bd0da5b74c244af226b07b1f5883bd
These were backwards which was triggering edit conflict detection for all users.
Fortunately for logged in users, if Revision::userWasLastToEdit was given a bad
timestamp (e.g. when we submitted here), it would just return true, suppressing
the conflict. It always showed a conflict for anonymous users however.
Bug: 56835
Change-Id: Ib07f965238ca96e17bf59b34da8a8e789954da61
Also update tools for changes in VE core.
New changes:
e4de14b Make tools use commands
e029817 Make getToolsForNode place primary commands first
Change-Id: I66575ee6d49e6b2f5a5f789978da98bb55e6dc5e
Protocol-relative <base> tags are fine when the iframe trick is used
because the iframe inherits a default base URL from the parent document,
so if the <base> is relative it can be resolved against that. However,
a document created with DOMParser (or document.implementation, oops!)
won't inherit anything, so anything other than a fully absolute <base>
will just break.
To make Parsoid's relative <base> work anyway, resolve it in the
context of the main document, then write the resolved version
back into the <base> tag.
Change-Id: I7261bd5dbe9ec1f4077a4e5a00bd2a03ac237ca0
Objectives:
* Allow users on-wiki to create tools and dialogs for citation templates
of their choosing
* Allow editing of citation templates directly, without having to go
through the reference dialog
* Provide citation template tools within reference editing that use the
same titles and icons as the citation tools do, but don't wrap the
inserted content in a ref tag
Changes:
* Reference list was cloning the DOM element it was inserting into its
view before the generated content node could finish rendering, so it
never ended up showing the finished rendering in the reference list
* Documenting hack about use of reference list node's destroy method,
and how we are depending on destroy not canceling generated content
rendering
* Introduced reference model
* Added saving/updating method to transclusion model
* Added getPartsList method to dm transclusion node, which caches the
result and invalidates the cache on update
* Added citation dialog, which extends transclusion dialog
* Added cite group to toolbars, cite-template in reference dialog toolbar
* Factored out getting the node to edit and saving changes procedures in
transclusion dialog so they could be extended in citation dialog
* Updated uses of autoAdd as per changes in oojs-ui (Ic353f91)
* Renamed MWDialogTool file since there was only one tool in it
* Expanded TransclusionDialogTool file out since there is now more logic
to it
* Switched to using ve.dm.MWReferenceModel instead of plain objects in
reference search widget
Configuration:
If you add to MediaWiki:Visualeditor-cite-tool-definition.json the
following code you will magically be presented with a delightful array
of citation options:
[
{ "name": "web", "icon": "ref-cite-web", "template": "Cite web" },
{ "name": "book", "icon": "ref-cite-book", "template": "Cite book" },
{ "name": "news", "icon": "ref-cite-news", "template": "Cite news" },
{ "name": "journal", "icon": "ref-cite-journal", "template": "Cite journal" }
]
...or...
[
{
"name": "any-name",
"icon": "any-ooui-icon",
"template": "Any template",
"title": "Any title text"
}
]
The title text is derived either from the title property or from the name
property by pre-pending the string 'visualeditor-cite-tool-name-' to
generate a message key. Titles for 'web', 'book', 'news' and 'journal' are
provided. The icon is a normal oo-ui-icon name, and more icons can be
added, as usual, by adding a class called .oo-ui-icon-{icon name} to
MediaWiki:Common.css. 'ref-cite-web', 'ref-cite-book', 'ref-cite-news'
and 'ref-cite-journal' are provided. The template name is simply the name
of the template without its namespace prefix.
Depends on Ic353f91 in oojs-ui
Bug: 50110
Bug: 50768
Change-Id: Id401d973b8d5fe2faec481cc777c17a24fd19dd4
* Add ve.init.mw.LinkCache to track page existence and
transparently query it
* Populate it with initial data from the parser cache
if available, obtained in the VE API module
* Use linkCache data in link annotation rendering
This doesn't yet integrate the LinkCache with other
components like the link inspector. That should be
done so we can deduplicate the existence checks.
Additionally, we should generalize LinkCache and use
it for the category existence/status checks as well.
Bug: 37901
Change-Id: I9fd43e8c3864dd375cf6dadfdeedd05e4fe9cf3b
New changes:
dd15f23 Split ve.ui.Surface into DesktopSurface and MobileSurface
16283f4 Add OOjs UI's sco.json i18n file
ef94038 Split ve.ui.Context into DesktopContext and MobileContext
Minor adjustments to point to desktop and mobile Surface or Context.
Change-Id: I7cf6f99a5a1216a28a7146afcd4deb68c7eac38e
Follows-up I260059802379 which removed got rid of
the "ve-init-mw-viewPageTarget-toolbar-editNotices-notice" class
from notices and didn't add something generic in its place.
(There is "ve-ui-mwNoticesPopupTool-item" but that's more an
internal class we don't want gadgets and wiki stylesheets to
rely on.)
Bug: 43013
Change-Id: I8e1e383c2cb3199fe78f45f4feaa24a44126cf0b
