* Check the popup fits within the node horizontally as well
as vertically before embedding.
* Calculate the position of the node relative to the document.
Previously we assumed the parent was the document and so used
jQuery#position but this is not the case if a custom $focusable
is passed to FocusableNode.
* Forcefully re-show the context menu on resizable node mouse up.
This is apparently done automatically by a redraw event, but if
the user just clicked on a resize node without dragging the context
menu would be lost.
Change-Id: Id477a30827c9393a446e9c44466c83dabc7e0ab4
Documentation says third argument is 'data' when in fact it is
'insertion' which is then re-used as the result of fixupInsertion :/
Change-Id: I17c959f858eddddc90a6fa839da0d32da69a784f
Function was removed in eb64743436 but one caller was still left,
which caused VE to throw a JS error when opening the reference dialog
to insert a new reference.
Change-Id: I827381bfe3bdeecdbaa1fba55a09b3e8e03575a6
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
