Original title will preserve the case of what the user entered
into the inspector. Noramlized title will remove any unwanted
leading colons from file/category links.
Bug: T118408
Bug: T124410
Bug: T160977
Change-Id: I92ffc19eab4eead0d124e84afc1e5a0a3e535867
After 79ccfb9372cb57afa569036ef39ead13abfba673, MediaWiki's `<pre>`
tags get rendered as `<pre typeof="mw:Extension/pre">` in Parsoid HTML.
MediaWiki's indent-pre syntax (block indented by a single space) is
still rendered as `<pre>` in Parsoid HTML, however.
Indent-pre is still handled by MWPreformattedNode (no changes).
Introducing MWPreNode, which will handle `<pre>` extension tags,
and MWPreDialog to change its contents (and allow converting
to MWPreformattedNode).
Pieces copied from MWGalleryNode, MWLinkNodeInspector, CommentInspector.
Possible future improvements:
* Add a specific icon for MWPreContextItem
* Avoid API roundtrips for rendering (but rendering wikitext <pre>
is not as simple as it looks)
* Consider a way to insert these other than '<pre' sequence
Bug: T159900
Change-Id: I5bc4ea6e5d893736f65ef0dd43b08c18cb1a1e85
Though neat, this hack to get the internal list doesn't seem to be used
and creates an invalid document (just an internal list with no content,
so the internal list is at the start and the default selection position
is inside it). Instead, use the ve.dm.Document.static.newBlankDocument()
utility function that was made for this use case.
Bug: T153509
Change-Id: Iba5931cb5e3f939a803c1d59fa0d8f30a0513f84
We request the generated content of a template to determine
if it will be block or inline. This is the same request as
the view makes later to show the rendering, so we should cache
this repsonse.
Bug: T156698
Change-Id: I0ffd36ccd0aa821aa44d99328f2e3a2abc23dc0f
We don't support editing <div>s right now (as they're BranchNodes) nor
<span>s (as they're annotations), but most of those are inside templates
and so not editable in VE anyway.
Bug: T157989
Change-Id: I647b2a544fd16952696d0de8d07cb72189b27ecb
The progress bar dialogs interfere with the life cycle
of the window you are trying to open. Just disable these
progress bars for now to avoid catastrophic behaviour.
Change-Id: I77c8ae67a2d502bbd189836deb320cd55c3cb11a
These are actually configurable via MediaWiki messages, so use those
instead of hardcoding the default URLs.
Change-Id: Ie66a1b53f9c011947fe9e8db198a5904373f3192
Logically depends on I575d92c4fa.
Should really use a registry, and also doesn't update when
format is changed by deleting text, but is an improvement
for now.
Bug: T147218
Change-Id: I0cb87dbad2ab4269c4f89bdff8a4ccd9b35c8635
Requires MediaWiki core change
Ic93d733cb9e1b1d7301f8975c68ab7ded778845a.
On wikis with CentralAuth installed, also requires
I24c2819ec2adcab468f961c5c46b31c331324567 and
I372e7bdff35400287b3d961da979d6f094d13bd9.
Bug: T143279
Change-Id: Id60bb3cde7e2032846da9606aefb00ea805f2ecd
The change was merged without the necessary dependencies.
This reverts commit 2b1c3914ec.
Bug: T143279
Bug: T146661
Change-Id: I5ce945f6167c9db5d5f03c824dee3d89cd0931a8
<a href="Foo%3F"> would dirty-diff to <a href="Foo?"> and also render
as such, pointing to the wrong page.
We also called decodeURIComponent() on the href twice, which can't
have been good.
Move URI decoding and underscore normalization into
getTargetDataFromHref(), and add rawTitle for callers that need it.
Put rawTitle in the origTitle attribute, so that equivalence
comparisons (decode(origTitle) === title) work as intended.
Bug: T145978
Change-Id: I29331a4ab0f8f7ef059c109f6813fa670a2c7390
New changes:
14b5fbc [BREAKING CHANGE] Move originalDomElements to the IV store and use MD5
c5d21f0 Provide methods to (de)serialize transactions
Local changes to move originalDomElements to IV store
Depends-On: I8a71c1a40ec35108d0a9a388da6f75632f8dc53c
Depends-On: I32c9b5f984fcf96e3354841ecfcd444149e8f159
Change-Id: I0fbb6324eede94558426178cbdad6b5daf0f8318
Pretty much fix everything on the insert menu... RB doesn't like it when you
try to specify both title and revision ID, but don't provide an ETag.
Change-Id: Ib25d023309d984ed8848f67b349b23231f27a957
TODO: Do we need to do anything special here to handle multiple hash symbols in a URL?
Bug: T112898
Change-Id: I4773cb04ae2533e8125bc55d9ebb606d63b3bf48
This replaces ve.safeDecodeURIComponent(...).replace( /_/g, ' ' ) . This action
is really specific to the quirks of mediawiki title processing.
Change-Id: Ia9e525c9340e6de9e485355899996c97867ccb48
