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
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
Code with a similar purpose was added in 568e0e5701 but got lost
when some things were moved from ve.Surface to ve.ce.Surface in
5012ed10.
Initializing the selection at (0,0) was known to cause problems before,
and since 789d0caf09 breaks editing of empty documents: typing in an
empty document begins in an inline slug, but SurfaceObserver doesn't
notice typing in an inline slug unless the ce.Surface pawns it, which
is OK because insertions in slugs are always pawned, but the pawning
logic believes the cursor to be at offset 0 where there is no slug
(it's at offset 1) and so it doesn't pawn.
Bonus: update tests and add descriptions for dm.Surface.change tests
Change-Id: Id72314d0fe650dacc7cdb842f5cea2f3bfba5145
* Convert some spaces to tabs
* Move private function to top and document
* Give constructor a global name
Change-Id: I7ec144303d32b1bb454b4164222601c263fb75bf
Objectives:
* Scroll when needed to show highlighted (with keyboard) or selected (by
any means) options in select widgets
* Allow clipping and automatic scrolling for certain elements when they
are otherwise going to be rendered partially out of view
Changes:
*.php
* Add links to new file
ve.ui.Widget.css, ve.ui.Dialog.css
* Removed unneeded x-axis overflow rules
ve.ui.ClippableElement.js, ve.ui.Element.css
* New mixin, adds visible area clipping support to an element
ve.ui.PopupToolGroup.js, ve.ui.MenuWidget.js
* Mixin clippable element
ve.ui.OptionWidget.js, ve.ui.OutlineItemWidget.js
* Add scroll-into-view configuration for option widgets
ve.ui.SearchWidget.js
* Scroll items into view when highlighting with keyboard
ve.Element.js
* Add getBorders, getDimensions, getClosestScrollableContainer and
scrollIntoView static methods
* Add getClosestScrollableElementContainer and scrollElementIntoView
methods
Bug: 53610
Change-Id: Ie21faa973a68f517c7cfce8bd879b5317f536365
Previous was checking by string match to 'preformatted' which didn't
match 'mwPreformatted'. Now using node factory to see if
hasSignificantWhitespace is set.
Bug: 54083
Change-Id: I1be2d4568df7848e08074d200fb374acd508f6fa
These were meant to have been de-experimental-ised with the toolbar
commit; oh well. This moves the following text styles from being in
"experimental" mode to being regular annotations:
* Code
* Strikethrough
* Subscript
* Superscript
* Underline
Change-Id: I21be2dc844b47b825d7a1e48a592067166ecd122
The previous implementation couldn't deal with transactions that
replaced both data and metadata at the same time (rather than replacing
data while moving metadata around), and extending its approach to
deal with that case would have made it much more complex.
So I rewrote the algorithm from scratch. The previous implementation
scheduled deferred moves for existing items, but immediately processed
insertions and removals. This is problematic for replacements and
maintaining the order in the binary search list. So instead, this new
implementation builds an array representing what the new item list
should be, then processes insertions, removals and moves in the correct
order to achieve that state.
It looks like the previous implementation didn't always work correctly,
which was masked because the test suite passed full=false to
assertItemsMatchMetadata(). This rewrite fixes this.
Also remove setMove/applyMove from MetaItem, because we don't need them
anymore and they're evil anyway; and add isAttached(), because the new
algorithm needs it.
Change-Id: I899d2b3c94c2cfa55823879bca95456750f64382
This was already possible in the operation structure by using
removeMetadata and insertMetadata, but no transaction builders
generated transactions like that.
With this change, pushReplace() can be instructed to overwrite the
metadata with arbitrary data rather than collapsing it by passing the
optional insertMeta parameter.
Change-Id: I0272fe38e053161c738591cf0a7b447a0827d4dc
Transactions that replaced metadata twice at the same offset
(with retainMeta-replaceMeta-retainMeta-replaceMeta) were broken
because the processor for replaceMetadata didn't advance the
metadata cursor.
Change-Id: I7ad24e7ffb4c39b40ec9c347db301f8e28f3692d
Add some test cases for documents with trailing metadata, and fix an
off-by-one error in the metadata-mutating transactions (since the
document metadata array is one larger than the document data array).
Change-Id: I8f049466e03ed55010dfcf0a35702536edfa7b0a
Restructure SurfaceObserver methods so that the method calls are more precise.
modules/ve/ce/ve.ce.SurfaceObserver.js
* Move timing code into startTimerLoop / stopTimerLoop / timerLoop
* Move poll logic into pollOnce
modules/ve/ce/ve.ce.Surface.js
modules/ve/ui/ve.ui.Surface.js
* Change all surfaceObserver calls to use new API
Change-Id: I0085e4a53c5a776733dce6944b867b8d2228ba4b
Firefox:
* Doesn't fire events without a selection, so when all we have is a
focusable node, create a dummy selection in the paste target so the
browser triggers an event on command+C.
Clipboard keys:
* Instead of just creating a text hash which may or may not match up
with the plain text in the clipboard data, just convert the clipboard
store into an array and use the index as the key. Also prepend a
random number (clipboardId) so on paste we can verify the copy came
from the same CE document.
The text hash is now used for validation if only HTML is written
to the clipboard.
HTML:
* Instead letting the browser grab CE HTML, always get DM HTML from
the converter as it is cleaner (no phantoms, linefeed markers, extra
class names etc.), and will make cross-ve-instance pasting easier
in the future.
Clipboard overriding:
* Always override the clipboard with the above HTML, either using
clipboardData.setData if it is available (webkit) or by throwing
the HTML into the pasteTarget and selecting it during pre-copy.
Bug: 53375
Bug: 49396
Bug: 52096
Change-Id: Id0f39c10818047bb4b8922e97cead153a770757f
These are not considered errors in jsduck 4.x but are in 5.x.
Though we don't specifically want to support 5.x yet, these are
actually genuine errors that were already causing incorrect
documentation to be generated, even under 4.x (it just doesn't
warn for these under 4.x).
Not from 5.x warnings, but fixed while at it:
* Removed more redundant @method
* Added a missing @returns for ve.Range#flip
* Added newline at EOF
Change-Id: Idc22b46b082a813e8e1761403e1ebf908bf690c4
This version pushes a `replaceMetadata` operation after a `replace` to
fixup trailing metadata if there is no inserted region and the removed
region includes metadata. This avoids a corner case where the
size of the metadata arrays inserted/removed in `Transaction.pushReplace()`
do not match the size of the data arrays inserted/removed.
We remove the now-unused `Document.getMetadataReplace()` method.
We also adjust `MetaList.onTransact()` so that it continues to work
properly when the number of metadata entries in `replace.insert` is
not the same as the number of metadata entries in `replace.remove`.
Change-Id: I1d600405b855ca1cb569853bb885b0752df47173
The `Transaction.pushReplace` method has a corner case if the removed
region has metadata and the inserted region is empty. This works fine
unless there are two adjacent `pushReplace` operations, which can occur
in `Transaction.newFromUnwrap`. Fix this by having `pushReplace` look
at a preceding replace and correctly merge the two operations if
possible (in particular in the tricky case where the previous case has
a zero-length insertion). Pleasantly, this can be done without a lot of
special-casing code in `pushReplace` or `newFromUnwrap`.
Add test cases verifying the `newFromUnwrap` works correctly (both
in commit and in rollback) when there is metadata present.
Change-Id: I6cfec0d2b1823dad724422f018a3c73dc0c7f186
CODING.md
* Document the procedure for adding a new javascript class
ve.dm.MWExternalLinkAnnotation.js
ve.dm.MWInternalLinkAnnotation.js
ve.dm.ElementLinearData.js
ve.dm.LinearData.js
* Add whitespace line before preformatted code to fix a
rendering bug
Change-Id: I54443ea3d4799328655d279f379d4ddc176c50a0
It's important in case of replacing root element ($) of a node, so new element
does have CSS class and contenteditable property set.
Change-Id: Icf14e2164e89114e6b7c10672b782d02f4c5daac
Doing retainMetadata followed by a replace (not replaceMetadata)
doesn't make any sense and its behavior is undefined, so don't do that
in the test suite.
Change-Id: Ica032b0a5122d24e40e43e3eb43fea940270aece
* Replace addOuterLength with a recursionDirection as we only
want to add length when the first recursion was to the left,
and add nothing if we recursed to the right.
* Use isContentEditable which is the proper calculated boolean.
contentEditable is often just (string)'inherit' :/
Mercifully this works in in IE.
* Only check for the IE ce bug if we aren't recursing at all.
Bug: 53766
Change-Id: I247d1b68484cb510335b5f6789269ec254376cfe
