This patch follows the audit made on the extensions to check the usage
of the "rel" attribute and check that it's compatible with multi-values.
Bug: T315209
Change-Id: Ib323736d93ea96c86f9d56599e515c9e6d72a76e
This does not fix the rendering of new
or modified interwiki links, which will
require an API request.
Bug: T185083
Change-Id: Icb72291e8662456e1a233392bf22d786c7eed1e5
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
Parsoid doesn't apply these prefixes any more, so this hack is
now doing more harm than good.
Bug: T96643
Change-Id: I73ecea6a87f32437d29dfdca791be3f64c7c40a4
Only template nodes for now. Not sure what we can do about generated content nodes in general...
Bug: 65353
Change-Id: I848f36764b446ed30c74c0e641d0973008f6880b
Also cleanup redundant overrides, documentation and
unused messages.
Depends on If22a5197 in core.
Change-Id: I533235f4eb5d703783a8fb45dff5e7be465f4ebb
New changes:
a53f101 Update OOjs UI to v0.1.0
1fa518b Update OOjs UI to v0.1.0-pre (15f4156bac)
257af53 Use ContextWidget instead of toolbar inside context menu
5f10e73 Follow-up Ia2076a42: Mark getDescription() as @inheritable for Annotation, Node
Local changes to adjust for the ContextWidget changes.
Change-Id: I47f68f5cf1b9583dab9bd0109fa6504481bdfc67
If we render new links with a plain target, then if you're on a
subpage like Foo/Bar, [[Baz]] will point to Foo/Baz. In order to
avoid this, we fake the link target to be ../Baz and resolve that,
which produces the correct result.
This hack is only needed until Parsoid stops producing ../-prefixed
links. This hack is only applied in view mode, because applying
it to our DOM output back to Parsoid would confuse Parsoid and
cause bugs.
Bug: 58314
Change-Id: Ifb4b63a26235a04e6362fc3e3e57d8773831eb38
* 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
Objectives:
* Rename this.$ to this.$element
* Rename this.$$ to this.$
* Get rid of the need to use this.frame.$$
* Rename OO.ui.Element.get$$ to OO.ui.Element.getJQuery
Changes: (using Sublime Text regex patterns)
* Replace "get$$" with "getJQuery"
* Replace "\.(\$)([^\$a-zA-Z])" with ".$element$2"
* Replace "\.(\$\$)" with ".$"
* Replace "'$$'" with "'$'"
* Set this.$ to null in constructor of OO.ui.Window
* Set this.$ to this.frame.$ in initialize method of OO.ui.Window
* Replace "\.(frame.\$)([^\$a-zA-Z])" with ".\$$2"
Bonus:
* Use this.$() in a bunch of places where $() was erroneously used
Change-Id: If3d870124ab8d10f8223532cda95c2b2b075db94
Centralize href computation in getHref(). Because getHref() is provided
by the generic LinkAnnotation class, the subclass implementation is
now simpler.
Bug: 51487
Change-Id: Ia6ca85bc84b4f4453b572285836adb631e8d0683
URLs are resolved according to the <base> URL from the Parsoid DOM.
For instance, a link can have its href set to '../Foo' in the DM, and
the target will show up as '../Foo' in the link inspector, but the CE
rendering will be <a href="http://localhost/Foo"> (assuming Parsoid sent
<base href="http://localhost/wiki/Bar">).
Bug: 48915
Change-Id: I919135eb758c82361525078f276ca193dc4c4820
This gives them a way to reach the dm.Document, which is needed
for ce.Annotations to do URL resolution.
Change-Id: Ia18bd8fc3510ad1b627644cd2c6ebcf148254e05
This is done by using the computed property value rather than the
literal attribute value when rendering href and src attributes.
Helpfully, this provides perfect URL resolution natively in the browser,
which means the document's <base> is respected and all that good stuff.
For GeneratedContentNodes, we also need to find all DOM elements inside
the rendered DOM that have href or src attributes and resolve those.
This is done in the new getRenderedDomElements() function, which the
existing cleanup steps (remove <link>/<meta>/<style>, clone for
correct document) were moved into.
In order to make sure that the computed values are always computed
correctly, we need to make sure that in cases where HTML strings
in data-mw are parsed, they're parsed in the context of the correct
document so the correct <base> is applied.
We still need to solve this problem for models that actually store and
edit an href or src as an attribute. I'll post more about that on
bug 48915.
Bug: 48915
Change-Id: Iaccb9e3fc05cd151a0f5e632c8d3bd3568735309
These represent <nowiki> tags. If the user doesn't edit the text inside
the nowiki, we round-trip the <span typeof="mw:Nowiki"> wrapper cleanly,
but if they do edit it, we unwrap it. This then triggers re-escaping
in Parsoid, and prevents cases where the user edits the text to no
longer need escaping but Parsoid still wraps it in <nowiki> because
of the <span typeof="mw:Nowiki"> wrapper.
In order to detect whether the contents have changed, the nowiki
annotation stores a copy of its contents. To avoid infinite recursion,
we have to exclude this attribute for hash generation.
Bug: 47678
Change-Id: I2edc46b6d87d2f91e952efcb09c0edae5166958f
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
