When using jQuery insertBefore and insertAfter make sure to pass as a parameter jQuery selection of only one element (first for insertBefore and last for insertAfter).
Change-Id: Id469ed775642ab5be8e274ab3cb7730899e9487a
The signature of getUnlistRanges() changed in the UI rewrite, but the
recursive call wasn't updated. This caused unlisting of lists that
contain lists to break and throw a JS error.
Change-Id: I990120a906868a5160561cff6b963f5ba5473427
About groups are HTML structures like the following:
<div about="#mwt1">....</div>
<span about="#mwt1">...</span>
<div about="#mwt1">...</div>
When about groups are alienated, they are now merged into one alien
node, rather than producing a separate alien node for each sibling.
This is very basic about group handling, because it only works for
groups of directly adjacent siblings (text nodes are permitted in
between, but nothing else) assumes all about groups are aliens (which
is currently true).
* Before processing an element in the DOM->data converter, perform about
grouping on its children. This temporarily wraps about groups in
<div data-ve-aboutgroup="value of about attribute">
* Extended createAlien() to handle single nodes as well as wrappers
holding multiple nodes.
* In the data->DOM converter, temporarily wrap multi-node aliens in
<div data-ve-multi-child-alien-wrapper="true"> . This makes the rest
of the algorithm easier.
Change-Id: I2df5f62bc222b570fc11a89fe43d353f8363ead8
* Now ve.Factory inherits from the more general ve.Registry
* New class ve.CommandRegistry
* Refactored setupToolbar and command setup code into setupComands
Change-Id: Ic548e5de95b77889727362d3e66d7be83c12a603
The port of mousetrap wasn't really what we needed. This is much simpler, matches the rest of our code, and does exactly what we need.
Change-Id: I67f413e097fc2d4078336edb14dd9440e771f196
This fixes a problem with how Chrome renders native selection around floated elements. By adding pseudo elements before and after block aliens, the rendering is fixed.
Change-Id: I7fdbb8f4c42e29d0574b308b8c5740066bb58e94
Sequences that were scheduled directly after each other, such as "a b c" and "1 2 3" would end up overlapping sometimes, producing "a b 1 c 2 3" which failed to trigger the correct commands.
Change-Id: I27bb60e856e9d692a21e1587dc227f8aeb5fcf4e
This causes the converter not to strip inner whitespace in them, and
causes CE to suppress the whitespace mangling logic that is normally
applied (↵ for newlines, ➞ for tabs, alternating s for spaces).
Change-Id: I738a750c91a4ca4836c485e282865bb7525bf30a
* Add map of change markers per offset to Transaction
* Map is populated by TransactionProcessor
* Markers are reversed on rollback
* Removals aren't marked, Parsoid can detect these using DSR
discontinuities
Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
* Added selectionStart and selectionEnd events to ve.ce.Surface
* Switched from debouncing model change events to just ignoring
model change events while the user is in selection mode
(dragging mouse or pressing shift+arrow keys)
* Fixed bug with callout appearing on resize.
Change-Id: I3bb9952867a983a4f7612964ff719a1179dd0fc6
* Remove VisualEditor namespace, and restrictions on it
** For MW.org these will be moved to mediawiki-config
* Add $wgVisualEditorNamespaces
* Add visualeditor-enable preference and respect it
* Use $skin->getTitle() rather than $wgTitle
* Remove "Sandbox" from i18n message
* Remove duplicate enforcement of VE namespace from JS
Change-Id: I956f68c2dde55e4063530fcc7c90eda048e0d78b
* Things broke when ve.ui stuff was refactored
* Save dialog is now completely stand-alone
This is an alterantive to Ib028e6967e8d2e158b05fd7582620c21cf9b85fb
which I believe is a better approach.
Change-Id: I7cb52d0750e859c4052e2008d929d197b88b9877
* ve.dm.Converter still generates metaInline/metaBlock elements as
before, it's not affected by this change
* ve.dm.Document constructor splits its input into "real" data and
metadata
** Metadata is stored in this.metadata (the meta-linmod) as a sparse
array of arrays, with an element for each offset in this.data
** this.data itself does not contain the metadata
** This means the node tree also doesn't contain the metadata
** Which means CE doesn't know about it at all
* All splice operations on the linear model are sent through
ve.dm.Document.spliceData(), which performs the splice and syncs the
meta-linmod
** Metadata in the removed range is reaped and added to the metadata for
the offset immediately following the removal
* ve.dm.Document.getFullData() splices the linmod and meta-linmod back
into each other; this "full data" is then fed back to ve.dm.Converter
Change-Id: Ief6dfd5b59cc13a8457993ed85c725413029c4fb
* Allow inspector to open with 0 length selection.
* Allow context menu to open with 0 length selection.
* Fixed bug in doc.getAnnotationsFromRange on zero length selection:
Method now returns annotations from start vs empty annotation set.
Change-Id: I3937c5c2824c7396d0c3ee11c13ffecdbed6052a
* Moved to tool specific configuration to static properties (left tool instance specific stuff in the constructors)
* Added documentation for tool configurations
* Centralized typePattern matching for inspectors
Change-Id: Ieacf61b320c10fd37ea69a05e543313fa990b403
* Actually return the spliced data like the docs claim we do
* Remove false claim that offset can be negative
* Add that data=[] && remove=0 is invalid; native splice() doesn't allow
this, and there is a case where we call native splice() directly
* Add tests
Change-Id: I90e77c1b22ea1c36cb61e89ea47831885a0b1cb9
