This is obviously necessary, but wasn't done, so calling update()
with a config object was broken.
Change-Id: I30d67bcb117885c792c0f08ea55d60cb294de18b
If you changed the contents of an alien tag extension, then tried to
use undo, the change wouldn't be undone, but the undo state would
toggle.
This was because we only kept one copy of the data-mw object for these
nodes and modified that one copy. Instead, create a new copy every time
we modify it, so we can actually go back to previous states.
Change-Id: Ib4d5d460a6fdda9c3b0968f269585d620b47fdd8
When you press delete inside an empty node (e.g. Heading) that
node should be removed, instead of the paragraph beneath it being
merged into and effectively converted. If the heading is non-empty
then merging is still the correct behaviour.
Also add in test case.
Bug: 50254
Change-Id: If9cee79feb4b4ee9d7c367e392b00fee5e8c0669
When the document starts with a focusable node, and we try to initialise
the selection to [1,1], the current logic does not detect that as being
on the focusable node and tries to do a native selection.
Bug: 54446
Change-Id: Ib515c435314c35c4e9b3802da117b963b3ef4169
this.$ on a GC node is just a wrapper, so shouldn't take the
HTML attributes from the model, otherwise you may end up with
double borders and padding.
Change-Id: I5641df341c9b118461e7e8fb89266dd300e09755
In various places in the UI code, certain properties of config objects
were overridden and in some cases the configurations were documented as
private as a strange hack to prevent them from being advertised in the
docs.
I, Trevor, have been convinced of the error of my ways, and gladly
reverse this situation, allowing all configurations to always be
overridden when desired, while still allowing default values.
Change-Id: I242e3b1902dec8e09eeea38fa64381e69ee04215
In this instance, MW(Extension|Reference|Transclusion)Nodes.
In general anything that is focusable should probably be relocatable
by default. We should considered this when we sorting out the
focusable/protected/relocatable mess in the near future.
Change-Id: Ifc55e251cba3e875798d5103540d02ad651399ad
Fixing a couple of mishaps in the language annotation, including adding a
getComparableObject in the ve.dm.LanguageAnnotation class.
Change-Id: Ia28900df55969f60576cfd716c70ffc1ba5f4c27
Some browsers normalise attributes (e.g. Firefox makes
URLs absolute) so we have to remove them from the clipboard
hash to make the comparable.
Bug: 54377
Change-Id: Iadc4d886a5345b28370cbfa31eb665661e577eeb
Conversions usually end in a close tag so this hasn't been a problem
before, but the mini-conversion we do in onCopy may not be balanced.
Change-Id: Ia2db29f116ca84ee886b4c5cafd4ac45cd926b79
Simply generating ':3' as the "unique" name for the 4th reference
doesn't work. Even if getUniqueListKey() had been used, that only
checks for conflicts with names that have already been encountered
(i.e. occur in <ref> tags that precede the current one), not for
conflicts with names that first occur further down in the document.
The solution is to generate names at serialization time, when we
have full knowledge of which names are in use. Internally, we use
'literal/<name>' for names that literally appeared in the source,
and 'auto/<number>' for unnamed references. Then at serialization
time, we translate 'auto/<number>' to 'literal/:<number>' if needed
(i.e. if the reference was reused).
ve.dm.MWReferenceNode.js:
* toDataElement()
** Prefix listKey with literal/ or auto/ as appropriate
* toDomElements()
** Map auto/ listKeys to unique names
** Don't try to unset the name if not present (was unsetting a property
that didn't exist anyway)
ve.dm.InternalList.js:
* Remove now-unused isUniqueListKey()
* Rewrite getUniqueListKey()
** Make prefix configurable
** Take previously generated unique keys into account
** Map the same old key (auto/N) to the same generated key (literal/:M)
* Add getNextUniqueNumber() as a source for auto/N numbers: previously
used the length of the itemHtmlQueue, but that only works during
conversion, not from the UI dialog
ve.ui.MWReferenceDialog.js:
* For new references or conflicting names, generate an auto/N key and
let toDomElements() deal with actually mapping that to name
ve.dm.InternalList.test.js:
* Rename listKeys to new style
* Split the test case into two groups so we can test multi-group cases
* Add tests for getUniqueListKey()
ve.dm.mwExample.js:
* Rename things to new style
* Modify the test case so it attempts to trigger bug 54341
Bug: 54341
Change-Id: I726fb83e6fb66ffec643d996768a854ec9474b3d
Because there's no sane wikitext to handle that case, and Parsoid
will just output garbage.
Bug: 53151
Change-Id: I9e065aa46d88f6bed9c47127b3e002ec2e1fec5a
When we switched all base 64 encoded blank GIFs to the "stable" version,
we created a regression that prevented proper styling of the drag marker.
This restores the correct drag-drop experience.
Change-Id: I9c2a195fd866a5919245667a436106772debcffd
VisualEditor's hook changes the edit section link, which changes the
output of certain parser tests so that they no longer match the
expected text. Use the `ParserTestsGlobal` hook (which cleans up
after itself when the parserTests ends) to disable the
`onDoEditSectionLink` hook when we're running parserTests to avoid
the spurious failures.
Change-Id: Ic958d88f443ac37ba304d3256e2bb5ea2fde820d
Correct the return value descriptions for the `newFromMetadataInsertion` and
`newFromMetadataRemoval` methods (which appear to have been cut-and-pasted
from another method).
Change-Id: I019b0ef9c75ff47fc0f2df8c95da9d090710a5a8
* Check in #getGitHeadHash now ensures a false value is
cached as well.
* Made ve.version.id being false when invalid more stable
since we now rely on this as of eeb3ac3b19.
* Added documentation for ve.version.
Change-Id: I164aa9ebaa7f8a4d1e8f2210af76e06b23abef09
