The mw:Placeholder attribute semantically means, "don't touch this,"
but french spacing should be freely editable. It's just a funny way
to write a plain wikitext space.
Bug: T254502
Depends-On: Ia164dd1318d45924aa965919e7939c6f817f5d0d
Change-Id: I56e0f0c6526649ea041e023698a48936176dec4b
We don't share much functionality, and we have to do a bunch
of hacks to disable functionality we don't want.
Change-Id: I9861123d8f1cbab1923f1aa5be713c2dadaed53d
This reverts commit e5c1ef651b.
This change caused an error where templates failed to be inserted
into wikitext in the 2017 wikitext editor.
Bug: T255785
Change-Id: Ie57c49e68e594be22af2b1b479840f29e46131db
<includeonly /> is not valid wikitext markup, which is distracting.
Let's use <includeonly>…</includeonly> instead.
Bug: T250937
Change-Id: I9eac8b265eca16118d390da2628e0da7ca409ed8
mw.Target doesn't know about revid and etag, so move that logic
to ArticleTarget, where the param can still just be a boolean.
Change-Id: Idf4632cd28554aaf5bbf5f2b44ded047c0c4b182
The difference is that metaitems are not visible on the editing
surface, and their exact position is not preserved when the paragraph
containing them is edited.
This behavior is desirable for e.g. categories, but not for
<noinclude> and related tags, which are intentionally placed in
specific places in the text.
Note that we don't really have any editing interface for these nodes
yet. But you can see them (and they come with descriptions and links
to documentation pages), and delete or copy-paste them.
Bug: T250937
Change-Id: I104e7abbd650567df0e59813653c46a66d955d58
Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
By removing this line, we fall back to the default behavior,
which is to copy the attribute from the original DOM element.
The gallery is supposed to have a class indicating the type (packed,
traditional, etc.). However, Parsoid doesn't care about that and
instead reads the type from 'data-mw'. Instead, changing the attribute
is causing dirty diffs.
Bug: T214649
Change-Id: I96b5a21777046b1caf07a3b1def9fad81bb15939
ve.dm.MWImageNode:
* Define sensible scalable properties for audio files. They are now
scalable to any width but have a fixed height. (Ideally they would
have no concept of height, but that would require many more changes.)
This prevents them from resetting to 0x0 when resized.
ve.ce.MWBlockImageNode:
* Remove override for #isResizable, audio files can be resized now.
* Move #updateMediaType to MWImageNode mixin so it applies to
MWInlineImageNode as well.
ve.ce.MWImageNode:
* Add #updateMediaType from MWBlockImageNode.
* Hide the real image 'src' using CSS rather than changing the
attribute. It seems the previous solution depended on the order in
which methods are called, because it stopped working when I moved
the code here. (This depends on VE/VE change If5b1b5b5d.)
audioPlayer.svg:
* Make the file nicely resizeable. The dimensions of the "play" icon
and time are fixed, the bar adjusts to the width of the container.
Bug: T206022
Change-Id: Ia0f38ca11e0d55a5b725fd9aeb6c79ec1345376d
The previous attempt to fix this didn't preserve any attributes
but removing data-parsoid can result in a loss of wikitext formatting.
This reverts commit bdfd4b6d8f.
Bug: T207325
Change-Id: I2a38e651d17262889eddb149c72c9e08b4e56ed0
When a template does not have user-provided TemplateData documentation,
the TemplateData API falls back to extracting possible parameters from the raw wikitext
to generate an API response with a list of potential parameters. However, it also
sets the "notemplatedata" field in the response, causing the VisualEditor to think
the response contains no useful information and ignore it. This appears to have been
an unintended side-effect of I97a1bfc9f9ead082a673a91b9d2053630a90309c.
This patch ensures that the VisualEditor will correctly consider such responses from
TemplateData by modifying ve.dm.MWTransclusionModel to check if the response contains
a parameter map. Some unit tests were added for the class to verify this behavior.
Bug: T243868
Change-Id: I72005880d9301a53224473900efe2917379e8708
It's supposed to be non-editable but deletable text, like mw:Entity.
We decided to handle them this way in 2015 but never implemented it
(T94509). Currently, accidentally editing text inside of
mw:DisplaySpace node causes the changes to be lost when saving.
Bug: T241906
Change-Id: I78a0cc7a75061a7eefb8b677898b5756326615d6
* In normal images, parse relative 'href' attributes instead of
expanding them to absolute, and parse 'resource' to keep it
identical to 'href' if they refer to the same page (including
same percent-encoding and space/underscore). This resolves Parsoid
generating |link= options for copy-pasted images (T193253).
* In gallery images stuff, prefix the 'resource' attribute with './',
same as normal images do. This causes no functional changes, but it
makes updating tests easier, and the consistency is probably good.
* Update test examples to also prefix 'resource' and relative 'href'
attributes with './', like the real Parsoid does.
Bug: T193253
Change-Id: If2d7f080d9d693568054f8311c1e1b15ca27ea5c
* Handle mw:MediaLinks pointing to to non-existent files, which come
with typeof="mw:Error" (similar to image nodes).
* Fix regression from c66f8e0547, which
caused all mw:MediaLinks to be treated as plain external links again.
* Add test cases.
Bug: T232754
Change-Id: I9ae5bcfc4e24e8c0d22ef77d6a4d03f817fc9768
A @method annotation is only necessary when the docblock is not
directly followed by a function declaration (in which case JSDuck
assumes it documents a property), e.g. when defining an abstract
function or referencing a function from another library.
I verified that JSDuck generates exactly the same output before and
after this change (docs/data-<hash>.js files are identical).
Change-Id: I7edf51a8560ab9978b42800ab1026f0b5555c3bf
As detailed in T95850#5078990, Parsoid incorrectly converts HTML to
wikitext when a link `href` refers to an interwiki page and contains
percent-encoded colon characters ':'. VisualEditor doesn't know
anything about interwiki pages (it treats those links as normal local
links, and expects MediaWiki and Parsoid to handle them specially),
so we can't easily special-case them. But since leaving the colon
unencoded is valid for all links anyway, we can just do that.
Bug: T103635
Change-Id: I87d7e6952983a72d90ea739b0bc8488d9f6a9be3
The likely case for this is: copying from within VE in one wiki, and pasting
into VE in another wiki. This change will notice this happening, and fall back
to treat it as an external link. (For the wiki-internal links, this will turn
them into interwiki links rather than raw external links.)
Bug: T223322
Change-Id: Ie0157fc3aee6e5fd9973a2889be7ebd287bc90a5
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
We could generate incorrect links to pages whose title contains a
colon ':' and therefore looks like a fully-qualified URL.
Bug: T206231
Bug: T206357
Change-Id: Ie34694d903a6d97589cc46417f70659559494619
This reverts commit be628a5b7e.
87b20f9b Revert "[BREAKING CHANGE] Do not cache document model data in DM selections"
Change-Id: I47bbf757a4ad227346d3734f6e50d928a2de1409
New changes:
ccb4de82c [BREAKING CHANGE] Do not cache document model data in DM selections
Bug: T208228
Change-Id: I564399ad864751d1690077b45a06e098b5509a93
I am surprised this was disabled. I investigated this after reviewing
some code by a new contributor which I was certain should have failed
the lint check, but passed.
Change-Id: I5b3c837b8ca3292f6e268b3922443bd9587eadbe
Split on regexp for whitespace instead of a single space. Avoids multiple-
spaces causing `'foo bar'` to become `['foo', '', 'bar']`.
See also: I1f467f51017e2deae30905163bf5e6b07048cecf
Change-Id: Id7a887a20fac99715b79045f01e861b4efe9f2c7
I ran Closure Compiler over the codebase just to see what would happen,
and it printed some useful warnings.
Change-Id: I56d40b11e6d1dd7ce68a5e59da511f66e928647f
While all of the following are valid in the model:
1. <mwBlockImage></mwBlockImage>
Image with no caption. Must use the media dialog to insert one.
2. <mwBlockImage><mwImageCaption></mwImageCaption></mwBlockImage>
Image with empty caption. There is a slug to insert a paragraph.
3. <mwBlockImage><mwImageCaption><paragraph></paragraph></mwImageCaption></mwBlockImage>
Image with caption with empty paragraph. Nice and intuitive!
(Same for <mwGalleryImage> / <mwGalleryImageCaption>.)
The third option is the most convenient for the user. We should always
generate that when converting documents from HTML and from the editing
tools (MWGalleryDialog, MWMediaDialog/MWImageModel).
Previously, the editing tools generated option 2 if no caption text
was entered, and the converter generated option 2 if there was no
caption node or if it was empty. Curiously, option 1 was never used.
Wikitext for manual testing:
```
[[File:Foo.png|thumb]]
[[File:Foo.png|thumb|]]
[[File:Foo.png|thumb|Caption]]
<gallery mode="packed">
File:Foo.png
File:Foo.png|
File:Foo.png|Caption
</gallery>
```
Bug: T200387
Change-Id: Ie82fb339f6bd8ae1b289235bf5402490722d9a7c
* When ve.ui.MWLinkAnnotationInspector is being initialized,
internal and external annotation inspectors are hardcoded to
new ve.ui.MWInternalLinkAnnotationWidget and
new ve.ui.MWExternalLinkAnnotationWidget. Make this creation
more flexible by creating these inspectors through a method,
which inheriting classes can override.
* In ve.ui.MWLinkAnnotationInspector.getAnnotationFromFragment,
factor out the creation of link annotations, so overriding
classes have the ability to provide different internal and
external annotations.
* In newFromTitle, static method of MWInternalLinkAnnotation,
creation of `element` isn't flexible for reusability with
slight changes to attributes passed to the constructor. By
factoring out the creation of attributes, inheriting classes
can reuse the existing structure and alter the attributes if
needed.
Bug: T195064
Change-Id: I2037464a7be77783837e9810691c8e372c8197c6
New changes:
71baf1c02 Create an 'htmlMsg' function for HTML messages with HTML or DOM arguments
9a7af223e Use ve.htmlMsg to highlight values in attribute changes
a1fd90540 DiffElement: Refactor describeChanges tests
Local changes:
Implement getHtmlMessage in mw.Platform and use for DiffElement
Bug: T195243
Depends-On: Ib4ad16858e4241d33d018830dbcfded63ff703af
Change-Id: Ib5fa39e4f2f529948354b03a141542e23d169fe0
It was failing to properly ignore the fragment if it contained a ?. This
resulted in such fragment-selflinks being considered a link to a wikipage with
a title of their full URL. As such, only consider the pre-# section for ?s.
Bug: T194463
Change-Id: I205f86d2b4abcf91dd6a84e3013e899e953a6842
Adds support for align=none.
Also don't show changes from class names.
Change-Id: Ia00a51dd52af73183e98c8a87f4c60ee5380d81f
Depends-On: Ic668454c4b4b069dab46a608530c85a5bb7e7ad8
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
