Like transclusions, extensions can contain nodes of other types. This
hasn't been an issue because the legacy parser doesn't generate content
with these annotations. But, moving forward, as Parsoid becoming
responsible for more extensions. This is the case for the new ImageMap
implementation.
Matches I95767e466803f0744b6626204a0a3a1514fff174
Change-Id: I6ff81a01207e2734090c626b177e5f4d10bb6d61
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
<includeonly /> is not valid wikitext markup, which is distracting.
Let's use <includeonly>…</includeonly> instead.
Bug: T250937
Change-Id: I9eac8b265eca16118d390da2628e0da7ca409ed8
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
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
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
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
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
Adds support for align=none.
Also don't show changes from class names.
Change-Id: Ia00a51dd52af73183e98c8a87f4c60ee5380d81f
Depends-On: Ic668454c4b4b069dab46a608530c85a5bb7e7ad8
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
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
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
