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
Various checks didn't think a rel attribute could contain multiple values.
Mostly they don't, but to play it safe let's adjust the checks.
Change-Id: I29823b7c8c65ef6b2ff41ce9a801840000972e9c
Depends-On: I33a456351ab025d0c81cfb1a1577d5a2ae9df51a
New changes:
7551f6c66 [BREAKING CHANGE] Rename class ve.dm.IndexValueStore->ve.dm.HashValueStore
Local changes:
Follow-through rename of IndexValueStore->HashValueStore
Bug: T188900
Change-Id: If60d0c637fe92f0e7afe916c064fafb17980d063
Parsoid now handles empty headings for us in
scrub_wikitext mode (which we use).
This reverts commit 884f301aa0.
Bug: T187913
Change-Id: I8690bbced64be76622929f78f9c9e0d8f85d4be8
This lets copy-paste between documents retain the numbered status rather than
falling back on pasting "<a>[3]</a>".
Update the part of LinkCache which selects on mw:ExtLink, so it will handle
possible multiple values in the link rel.
Bug: T188429
Change-Id: Ia5e4c9fa45e94da9cbfcd2a42d017d0fda1c511f
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
The latter was introduced for this very purpose: defining
which attributes affect the rendering (in this case the
thumbnail URL). getHashObject should be reserved for making
full semantic comparisons.
Bonus: Don't distinguish between block/inline images
for URL caching purposes.
Change-Id: I6e6d2547a0d110f07c4d18b8179c168d8c251059
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
Resolving attributes means turning 'href' and 'src' URLs from possibly
relative to absolute, so that they don't depend on the base URI of the
document.
This is necessary when rendering for clipboard (and in some other
cases), but at the point when toDomElements() is called, the document
these elements are in does not necessary have a sane base URI set,
giving us hrefs pointing to nonexistent pages.
Don't do it here; it will happen later when we know what the right
document (and right base URI) is, e.g. in ve.ce.Surface#onCopy or
ve.ui.PreviewElement#replaceWithModelDom.
Bug: T169675
Bug: T175157
Change-Id: Ie0a5d6e1c57b8efdbbfba0c24f31ca91d156e200
This prevents the image jumping into another paragraph,
e.g. in a different table cell.
Move the logic for removing the old image out of MWMediaDialog
and into MWImageModel#insertImageNode.
Bug: T121449
Change-Id: Ibd7c92f3f90c382ceffd3e0defb12ba36a3786d2
Avoid confusion by using `twoway` instead of `bidir`, which could be
confused with the Unicode bidirectional layout algorithm.
Depends-On: Ib59dff22e64f235e30778a5a5b3e525e4fc7fdd3
Change-Id: I7efb35245d48125b167dc0f0ef8f12aa0fff94e5
We used (\.+\/)* instead of (\.\.?\/)* in some places,
but that doesn't make much sense since we won't and shouldn't
ever see stuff like '.../'
Change-Id: I9efcff2d2a34499ca57321dfbae29392ecb422d7
As type is always 'mwTransclusionInline/Block'.
Bug: T166801
Change-Id: I76cdf0add780d556206c439797cfcca19133d94d
Depends-On: I0f24d9d81b5491a8f09bc59e5f544f99751fd506
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
A missing image should return some data to say the
image is missing, not just reject the promise.
Bug: T169337
Change-Id: Ib41a64a783c1baca88f428417c98e7fb913d14a1
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
Sub-classes want to dynamically change type, e.g. inlineFoo/blockFoo,
but doing this after storeGeneratedContents invalidates the cache,
so ensure this is done as soon as the element is generated.
Bug: T151130
Change-Id: I80e2f2587cff8e9d9fe6ded5d8581263268deaa8
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
We're getting rid of meta item grouping, so we need to prepare.
Merged:
* ve.dm.MWIndexMetaItem
from ve.dm.MWIndexDisableMetaItem and ve.dm.MWIndexForceMetaItem
* ve.dm.MWNewSectionEditMetaItem
from ve.dm.MWNewSectionEditDisableMetaItem and ve.dm.MWNewSectionEditForceMetaItem
* ve.dm.MWTOCMetaItem
from ve.dm.MWTOCDisableMetaItem and ve.dm.MWTOCForceMetaItem
These three now inherit from ve.dm.MWFlaggedMetaItem to avoid code duplication.
Change-Id: Ic8a9cdb1226dccac2c27e7f4b965c1590a7387c0
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
