MWTransclusionNode will preserve TemplateData <style> in its generated content.
Disable TemplateStyles stylesheets in the original page content, and reenable
them when the surface deactivates.
Remaining TODO: if multiple copies of a template with deduplicated styles are
on the page, and the one containing the actual <style> is removed, all will
lose their styling.
Bug: T197563
Change-Id: Ibd8939eef7d8eb532719f4ee0ce200600449ef81
Depends-On: Ia9f2afcdba5456238e3ef444c202c9b0c78838bf
It contains some rare options that we don't currently make editable,
and we don't set it when creating new image nodes.
We could change our code to always set it, and consider it required,
but that would theoretically be a break in backwards-compatibility.
Bug: T198660
Change-Id: I6e77cce257f733f0f8f6e896b967177ff01658c6
jQuery.makeCollapsible styles now display "fake" expand/collapse
toggles. This is nice, but some bits and pieces clashed with our
styles, this fixes it.
Also ensure that the styles are loaded if the page previously had no
collapsible elements on it.
Bug: T194323
Change-Id: If8f0869e6677811147f272337da7d96286792fe0
Pass through the current document when available, otherwise
assume the current surface's document.
Also add a getter for getPageName, so that can vary based
on the target document.
Bug: T193856
Change-Id: Ifdc951fdc6a43b924d102e3fcd7e59e52023757b
The bug is easiest to reproduce with `[[File:Example.jpg|link=]]`,
but it also affected video embeds.
jQuery appendTo() method returns the set of inserted elements.
Because `this.$element` is undefined at this point, the `<img>`
was not actually being inserted anywhere, and an empty set was
returned, causing MWInlineImageNode to have no CE rendering.
This was not an issue prior to c4f93b14, because `this.$element`
was being defined by the parent constructor (OO.ui.Element)
We don't actually want to insert it anywhere, this appendTo()
call was a remnant of wrapping code removed in a22aeafc.
Bug: T191406
Change-Id: If1dbf9fef0e0ac9debfdb3049ebcccac70948515
Overriding ve.ce.BranchNode#onSplice seems pretty scary, some bug
could cause two captions to be inserted and it wouldn't even be
visible in the editor.
Instead, allow normal splice handling to happen when the caption is
added/removed, and only override the position where it is inserted
(to account for the image node this.$a).
The caption node is already removed from DM/CE if the image type is
changed to one that doesn't have captions, and even if that failed it
is also hidden in CSS, so we don't need to handle this.
Change-Id: I54f52b288118d692708311512dd674cc85d5d9e3
After change 89aecd54ba (2014),
there is no 'border' value for the 'type' attribute, instead
there is a 'borderImage' attribute only present when 'type'
is 'none' or 'frameless'.
Change-Id: Id87ba09b647f5f69b1c9350209e66acdea2c9d69
MWBlockImageNode already can't have any slugs:
* It can't have inline slugs, because it can't directly contain
content (`this.canHaveChildrenNotContent()` is true)
* It can't have block slugs, because it can't contain paragraphs
(`this.isAllowedChildNodeType( 'paragraph' )` is false).
(The only thing it can contain is a mwImageCaption.)
Change-Id: Ice6505da2356f004ef048ed0b1a9e03d08af02d1
For galleries with 0 items, this would previously return an empty
jQuery collection, which caused funny rendering issues later.
Bug: T75230
Change-Id: Ia68e4f1b74b5ec494fa3d86f0b792f69eadb02fb
We emit <span id="..." typeof="mw:FallbackId"></span> inside headings
when necessary to provide backward compatibility with pre-HTML5
section ids. These are mostly harmless inside VE --- they become hidden
alienated nodes, which are then safely ignored by Parsoid during html2wt
even if they manage to migrate outside of a heading --- but it's a
little safer to strip them.
Change-Id: I07d0fcf54427ab02d4930cff183d3e5579a99306
* Look inside first child for autoGenerated (as reflists can be wrapped)
* Unwrap Parsoid sections
* Discard leading and trailing whitespace
Bug: T179618
Change-Id: Ib9ead28173360f0f1d5a4dc66c33a75d70ef34b3
Override ve.ce.FocusableNode#hasRendering with a model-based test to
improve efficiency and avoid some unnecessary DOM measurements.
Change-Id: Ice7aebcc2f30dc73ef049a6ed0d4a0cffe86d8e2
Also:
* Disconnect change event on this.input, which doesn't
get destroyed on teardown
* Add padding between attributes and this.input
* Assume the alien extensions can have a rendering when
their body is empty.
Bug: T177181
Bug: T177183
Change-Id: I2e59f8195b255f33f91901213c92ea14793635b4
The default value of target#pageName is wgRelevantPageName
but other targets my override this, or change it dynamically
(e.g. ContentTranslation).
Also remove duplicate setter of pageName in mw.ArticleTarget,
already set in mw.Target.
Change-Id: Iebd1def1d4142978a673afec584a0b663644d176
Avoid confusion by using `twoway` instead of `bidir`, which could be
confused with the Unicode bidirectional layout algorithm.
Depends-On: Ib59dff22e64f235e30778a5a5b3e525e4fc7fdd3
Change-Id: I7efb35245d48125b167dc0f0ef8f12aa0fff94e5
Implement special node types for language variant markup, so that they
display appropriately based on the currently-selected variant.
(Parsoid uses empty elements to represent this markup, so without this
patch anything in -{ ... }- is alienated and disappears.)
A follow-up patch will implement context items and inspectors to
allow editing these nodes. This patch is basic "read-only" support.
Depends on I4fcdebc2290ec35ba188f4c2e69d578791fbcd67 in Parsoid to
generate the appropriate markup, but this patch is safe to merge
independently.
Bug: T49411
Change-Id: Ie11e9301d2513bfe4a36036481cee9a047f46d37
This icon is now added by Parsoid content CSS.
Bug: T160960
Depends-On: Id66f09c54103854ccbaa54a03e7c62890b67cba9
Change-Id: I8d76d759641b091c1821ff658b1201ca625fd146
We were incorrectly handling transclusions with trailing
newlines after the template name.
This also improves handling of non-template transclusions,
e.g. parser functions like `{{int:mainpage}}`, which are
no longer mangled as if they were page names.
ve.dm.MWTransclusionNode#isSingleTemplate will now match
a template even if it's name is itself template-generated.
Logic for turning Parsoid's hrefs into page names stolen
from ve.dm.MWImageNode.prototype.getFilename.
Bug: T167613
Change-Id: Ibecf71338eb37bb3da81a7372e4ed41140a9af57
Back in de98382a55, references to MWTransclusionTableCell were introduced,
but weren't followed through on. So, actually add it. Have cellable
Transclusions use it as their type.
Bug: T144122
Depends-On: I054f12f4218102a12d7a9ea843f9c61e8825c52c
Change-Id: I367f878bfd1c58e20b62368cb78120604b48d791
Provide a utility funcition in ve.init.mw.LinkCache to do this.
Also use this in ve.ce.MWTransclusionNode/ve.ui.MWPreviewElement, and
introduce to ve.ce.MWExtenionNode
Bug: T73900
Bug: T153535
Change-Id: Ieb9a0274b8c5ae1932c431546f09d18000fa6dd9
Pretty sure this event does nothing for block images, but
if we are going to bind, bind the the ce caption node, not
the ce image node.
Change-Id: I02b5500f381e932efba87d61ccdf668cda377757
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
Algorithm for deciding which cells handle sorting is exactly
the same as in the real jQuery Tablesorter.
Depends on changes in VE core:
* I50426e173c68af7df49e47fe3bec0465a9a55c26
* Iabb372dfe7bf5feef314315ac74a788c6c58dc20
Bug: T139072
Change-Id: I4446be2ad459b05590754da9bb6c3dd8f796be42
This became a special case when decodeURIComponentIntoArticleTitle()
was introduced, presumably because we skipped underscore transformation
out of laziness here. It doesn't matter whether we do underscore normalization
because we do title normalization right after, so make this code
less exceptional by using the fully decoded title.
Change-Id: I036cc7f1e08895d36224c94b8edc3ad700af1947
<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
This replaces ve.safeDecodeURIComponent(...).replace( /_/g, ' ' ) . This action
is really specific to the quirks of mediawiki title processing.
Change-Id: Ia9e525c9340e6de9e485355899996c97867ccb48
Make some of the methods we currently use to render the node
static so we can re-use them before inserting. We do the evaluation
without inserting the node so as not to dirty the document and
transcation history.
In the unlikely case the request fails, just fallback to inline.
This only handles insertions for now as type changes on edit will be
very rare.
This changes the signature of insertTransclusionNode, which is used
in Cite and Citoid extensions.
Bug: T51784
Change-Id: Ibc2fc66e6866084b0a4deeb082c8a1ca412febb2
New changes:
0b7e689 FindAndReplaceDialog: don't use tabindex
17b10a5 Localisation updates from https://translatewiki.net.
a4133e4 [BREAKING CHANGE] Make whitespaceHtmlCharacters a real static property
Local changes:
* MWEntityNode: Fix lookup of whitespaceHtmlCharacters
Property is now in 'static', and use registry to look up
TextNode by symbolic name.
Change-Id: Ied8c0c6feb69141c7c53fc4cc790774dee2cb63c
Depends-On: I7537b46a9fd58dfb2bd18dc4ed469aa221b96e86
