Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
Parsoid does not use relative links anywhere anymore (T72743). There
is no reason for us to support this. And previous code allowed
"hrefPrefix" to be empty '' sometimes, which is scary, as it could
lead to XSS vulnerabilities if titles starting with 'JavaScript:' are
not handled correctly elsewhere.
Bug: T206357
Depends-On: I8728f63084902c76d1c61193be4367939b069f1a
Change-Id: I99be18877aae2b505cf261bd7cdef6cf0d7a8670
Let's keep the ugly regexp and the comments about why we do this in a
single place.
This is mostly without behavior changes, with three exceptions:
* ve.dm.MWImageModel#attachScalable now passes a title with spaces
instead of underscores to the Scalable (this doesn't matter because
it's normalized to use spaces later anyway).
* ve.dm.MWImageNode#getFilename now returns a title with spaces
instead of underscores. This is used in some API queries and when
rendering thumbnails for missing files, and this format is actually
more correct for both of these.
* ve.dm.MWTemplateModel now URI-decodes the template title. This
actually fixes a bug where trying to edit a template transclusion
whose title contains a '?' would throw an exception about invalid
title.
Also, clarify that the return value of ve.dm.MWImageModel#getFilename
and ve.dm.MWImageNode#getFilename is different :(
Change-Id: I8e09015cea82308017ed925ec755b7231518126e
This replaces ve.safeDecodeURIComponent(...).replace( /_/g, ' ' ) . This action
is really specific to the quirks of mediawiki title processing.
Change-Id: Ia9e525c9340e6de9e485355899996c97867ccb48
We normalize underscores to spaces in sortkeys in toDataElement,
but when toDomElements recomputes the normalization to decide
if the sortkey really changed, it doesn't normalize underscores.
This is broken, both code paths need to use the same normalization;
we do this correctly for the category name.
This bug appears to date back to the introduction of category
support in March 2013 :(
Spotted in https://it.wikipedia.org/?diff=67220927
Change-Id: Ie3257fa335f3bd24a36c8654f3f5a24e89d7a9b9
The Parsoid team says the cache is clean of old language /
category types, and would like us to use the new types
for newly generates languages/categories.
This reverts commit d8dcafe25b.
Change-Id: I0cffd5d299624230f3805f9468b2497f392c12c0
The new form was implemented in Parsoid and deployed in October, so enough time
has passed that there is no longer any need for VisualEditor to support the old
type.
Bug: 56009
Change-Id: Ief2e584345ccdb0e7eb44ab16c4bc14f7c14f5ec
Parsoid changed these types from mw:WikiLink/{Category,Language}
to mw:PageProp/{Category,Language} in I0f0a826c. We had previously
added support for them in 4d91e4ed but code overwrote the new types
with the old ones on the way out, triggering the DOM corruption warning.
Change-Id: I768ec2ffd623e5a01f18959277786697603a97f0
Move all MW-specific files into the ve-mw directory, in preparation
for moving them out into a separate repo.
All MW-specific files were moved into a parallel directory structure
in modules/ve-mw . Files with both generic and MW-specific things were
split up. Files in ve/init/mw/ were moved to ve-mw/init/ rather than
ve-mw/init/mw ; they're still named ve.init.mw.* but we should change
that. Some of the test files for core classes had MW-specific test cases,
so those were split up and the test runner was duplicated; we should
refactor our tests to use data providers so we can add cases more easily.
Split files:
* ve.ce.Node.css
* ve.ce.ContentBranchNode.test.js (MWEntityNode)
* ve.ce.Document.test.js (some core test cases genericized)
* ve.dm.InternalList.test.js (uses mwReference test document)
* ve.dm.SurfaceFragment.test.js, ve.ui.FormatAction.test.js
** Made core tests use heading instead of mwHeading
** Updated core tests because normal headings don't break out of lists
** Moved test runners into ve.test.utils.js
* ve.ui.Icons-*.css
* ve.ui.Dialog.css (MW parts into ve.ui.MWDialog.css)
* ve.ui.Tool.css
* ve.ui.Widget.css (move ve-ui-rtl and ve-ui-ltr to ve.ui.css)
ve.dm.Converter.test.js: Moved runner functions into ve.test.utils.js
ve.dm.example.js:
* Refactored createExampleDocument so mwExample can use it
* Removed wgExtensionAssetsPath detection, moved into mw-preload.js
* Genericized withMeta example document (original version copied to mwExample)
* Moved references example document to mwExample
ve.dm.mwExample.js:
* Move withMeta and references example documents from ve.dm.example.js
* Add createExampleDocument function
ve-mw/test/index.php: Runner for MW-specific tests only
ve-mw/test/mw-preload.js: Sets VE_TESTDIR for Special:JavaScriptTest only
ve.ui.Window.js:
* Remove magic path interpolation in addLocalStyleSheets()
* Pass full(er) paths to addLocalStyleSheets(), here and in subclasses
ve.ui.MWDialog.js: Subclass of Dialog that adds MW versions of stylesheets
ve.ui.MW*Dialog.js:
* Subclass MWDialog rather than Dialog
* Load both core and MW versions of stylesheets that have both
ve.ui.PagedDialog.js: Converted to a mixin rather than an abstract base class
* Don't inherit ve.ui.Dialog
* Rather than overriding initialize(), provide initializePages() which the
host class is supposed to call from its initialize()
* Rename onOutlineSelect to onPageOutlineSelect
ve.ui.MWMetaDialog.js, ve.ui.MWTransclusionDialog.js:
* Use PagedDialog as a mixin rather than a base class, inherit MWDialog
bullet-icon.png: Unused, deleted
Stuff we should do later:
* Refactor tests to use data providers
* Write utility function for SVG compat check
* Separate omnibus CSS files such as ve.ui.Widget.css
* Separate omnibus RL modules
* Use icon classes in ViewPageTarget
Change-Id: I1b28f8ba7f2d2513e5c634927a854686fb9dd5a5
2013-07-02 20:51:38 -07:00
Renamed from modules/ve/dm/metaitems/ve.dm.MWCategoryMetaItem.js (Browse further)
