* changes:
Plain text paste with paste special
Use rare unicode characters for paste placeholders
Rich paste
Add fixUpInsertion to newFromDocumentReplace
This allows things outside of VisualEditor to style themselves
differently while the editor is active.
Bug: 57555
Change-Id: Ief6b5f53096dd5eeb43a72a7bb182a2c04ec97ca
Allow pasting of rich (HTML) content.
ve.ce.Surface
* Use a sliced document clone for converting to DM HTML (copy)
* Add full context to pasteTarget before copying
* Add ve-pasteProtect class to spans to prevent them being dropped
* Implement external paste by converting HTML to data and inserting
with newFromDocumentInsertion
* Remove clipboard key placeholder after read so they aren't picked
up by rich paste. Hash no longer includes the placeholder.
* Detect the corruption of important spans and fallback to clipboard
data HTML if available.
ve.dm.LinearData
* Add clone method for copy
ve.dm.ElementLinearData
* Add compareUnannotated for use by context diffing.
* Add sanitize method for cleaning data according to a set of rules.
ve.dm.Transaction
* Add range parameter for inserting a range of a document only,
e.g. stripping the paste context.
ve.dm.Document
* Implement sliced document clone creation so that DM HTML
is generated correctly in onCopy
ve.dm.DocumentSlice
* Replaces LinearDataSlice. Now has two ranges for balanced data
and data with a full context.
ve.init.Target.js
* Define default, loose, paste rules (just remove aliens).
ve.init.mw.ViewPageTarget
* Define strict MW paste rules:
+ no links, spans, underlines
+ no images, divs, aliens
+ strip extra HTML attribues
ve.init.sa.Target, ve.init.mw.ViewPageTarget, ve.ui.Surface
* Pass through and store paste rules.
Bug: 41193
Bug: 48170
Bug: 50128
Bug: 53828
Change-Id: I38d63e31ee3e3ee11707e3fffed5174e1d633b42
We had CSS that applied to our rendering of autonumbered links,
but not for raw <a rel="mw:ExtLink"></a> tags appearing in
generated content like templates.
Bug: 57420
Change-Id: Ic1585ecb1a133d16b7393ce0ce38a11b76cc2239
We were using it for the pop-out save dialog, but now that the save
dialog is real dialog, we don't need it any more.
Change-Id: I72697b5502d5f3fd19f2369a754a62d614af715b
* Don't use setTimeout() within a change event, because change fires
after the text has already changed
* Don't use .$input.val(), use .getValue() instead
* Don't use .placeholder()
** Reaching into .$input is bad
** Any use of .placeholder() is TextInputWidget's responsibility
** All browsers we support also support placeholder natively
* Remove .editSummaryByteLimit from ViewPageTarget, unused
* Remove ve.bind() wrapping, we already have var saveDialog = this;
Change-Id: I380575fec8d02d1191bfc1f3f235b94c64cd23b6
The save dialog DOM is pretty big, so building it on demand
like every other dialog out there seems like a good idea.
Change-Id: I02077c3e45f01d3467d41616eb879bd1d608a82b
Each used their own implementation of building a form and submitting it.
The edit source one wasn't passing in the oldid, which caused edit
conflicts.
Also introduced a separation between form fields (for the action=edit UI)
and API options, building one from the other.
Bug: 56835
Change-Id: I38547b4ba1827f4028a2255109cba2a57cd59e8a
It looks like it also came from there originally, because it uses
this.pageExists which doesn't even exist in MWSaveDialog. This caused
all pages, even existing pages, to be watched when 'watchcreations'
was set.
This logic really belongs server-side, though.
Bug: 56206
Change-Id: Idf500383b27a93136dc0cfdd60a2e7b2607af95c
Move generation of initial edit summary from setupSaveDialog() to
restoreEditSection().
This allows us to get rid of the properties tracking whether both
halves of the edit section handling had happened, because they're
now in the same method.
Moving setupSaveDialog() down so it runs after restoreEditSection();
this is needed for the communication via this.initialEditSummary
to work correctly.
Change-Id: I06a9c5cf5c752acea8a2ac25d0ffb6ac61cfe986
Add prepareCacheKey() which submits HTML for serialization and saves
the resulting cache key, and tryWithPreparedCacheKey() which uses that
cache key (if available; if pending, it waits for it) for API requests.
Implemented save(), serialize() and showChanges() in terms of
tryWithPreparedCacheKey().
When opening the save dialog, run the conversion, cache it, and fire
off a prepareCacheKey(). Then use the cached conversion for save/diff/
serialize. This means we don't convert multiple times, and it causes
the prepared wikitext to be used.
Bug: 55979
Bug: 56011
Change-Id: I1d56fe88d312e9810a57d56a285ccdf4f1facf42
* parameter.svg had no opacity set
* replace.svg had a document opacity of 80% in addition to the normal 75%
* re-rendered parameter.png (syntaxhighlight doesn't have png's yet)
Change-Id: I9c990fefaf4f5a7536b884b92523408146d7b2c7
initialize() is currently called synchronously, but once the CSS
transplantation code is fixed and it goes back to being async, that'll
cause problems.
* Add this.setupDeferred and use it to defer setupCheckboxes() until
after initialization
* Move code populating the edit summary from ViewPageTarget into
MWSaveDialog and use .setValue() rather than manipulating the
TextInputWidget's DOM. Defer this until after init as well
* Move clearing of the diff from ViewPageTarget into MWSaveDialog,
and don't connect it to the transact event at startup, only when
we've actually shown a diff
* Remove swapPanel( 'save' ) from ViewPageTarget, instead do this
on setup in the dialog itself
Bonus:
* Document events
* Get rid of onFooButtonClick handlers in favor of array syntax
Change-Id: Idcdae5e013340f4519db4387bab507e714d47941
We can't get the directionality from the focused node if there isn't one.
This doesn't add any logic to determine the directionality in creation
mode, filed https://bugzilla.wikimedia.org/show_bug.cgi?id=57421 for that.
Change-Id: I3ff8d48f19c7beef5e24b55712a26d86efa5812a
In order to do this we have to separate out the removal
operation from NDFR, so it becomes newFromDocumentInsertion
(again, although actually, for the first time). As NFDI is
an insertion we can just run fixUpInsertion on the data
part of it.
In order for the removal operation to be a proper removal
we have to allow metadata removal (the default is to merge it).
Change-Id: I16d575b61b9796e7e889f2c27cfe02b4a40b7639
This fixes some of the problems with pasting references.
It's a bit overzealous in that references get renumbered even when
replacing, which is unnecessary but doesn't actually have any
noticeable effect.
Unfortunately, the internal list state depends so much on the converter
having run that we now need to add yet another hack, to set the counter
to the appropriate value.
Change-Id: I3c6514ce600af4f4c037f419554d34b5a5c86a63
* Use 'this' instead of 'viewPage' in setupSaveDialog()
* Unwrap unnecessary .each() in restoreEditSection()
Change-Id: I45d0c9714d59e195d0c4413ed3dbe9cbabe45e9d
* Fix invalid @param name (mixup of type and param name).
* Fix incorrect reliance on inferred name for ve.Range.
@class uses the below function to guess its name, however
if @property is encountered, the @class block ends. Thus
it was indexed as a nameless class.
* Separate @property definitions because combining them like
that doesn't work (it silently ignored everything after the
first "from" property).
Also:
* Add some missing @static to static methods in ve.Range.
* Remove a few redundant @method while at it.
Change-Id: I8357c30711a4830af0b68b18350352c457a607f3
Us grouping the inheritable static properties that way is an
implementation detail that is polluting the index and makes
it harder to refer to individual identifiers.
It also causes problems under JSDuck 5 because that version is
more strict about defining properties (Foo.static.bar) of which
the parent is not defined in the index (Foo.static), we'd have
to add a sea of `@static @property {Object} this.static` all
over the place. Might as well hide this implementation detail
and just consider them static properties (just like we already
do for "private" properties).
Change-Id: Ibf2ebf7752aabc2b75b6ac6fa00e2284a181a600
Previously we had a defaultSortKeyChanged value that lied - it was
possible for the value to be changed A -> B -> A by the user mid-
edit. However, the meta dialog assumed that defaultSortKeyChanged
wasn't lying, so blindly changed the meta item to the new value,
causing an unnecessary meta change if the user had done a no-op.
Now the value is renamed to defaultSortKeyTouched, and we actually
detect for content changes, and only change the meta item if a
change is actually needed (be that a removal, a replacement, or an
insertion).
Change-Id: I13022090bd7561a460a1151013e2b7d2a029f4dd
As of 46f40dc, we've split the VisualEditor API backend and the
part containing the parsefragment method no longer needs
an edit token.
This gets rid of the warning that started appearing after 46f40dc:
{
"warnings":{"main":{"*":"Unrecognized parameter: 'token'"}},
"visualeditor":{"result":"success","content":"<p>foo\n</p>"}
}
Change-Id: I36f79fa8ae48cdbec1b3506953418561ef2ff828
Previously was failing for two reasons:
1. FF requires the form to be attached before submitting
2. options.watch failed because of FF's annoying Object.prototype.watch
Bug: 56767
Change-Id: I7b3d349f057f5b87f823ce788b4143f817af5303
Changes:
* Cleanup the window API to use more consistent and intuitive methods - we
now use initialize/setup/teardown instead of
initialize/onSetup/onOpen/onClose as methods which are overridden, and
use open/close methods to control the window
* Change events around to have opening/open and closing/close events which
act as before/after points during the opening/closing process
* Make WindowSet and Context respond to windows being opened, rather than
opening them directly
* Fix a LinkInspector creation mode bug where the initial text doesn't get
reset
* Move inspector, a VisualEditor concept, back to VE
* Cleanup naming of SurfaceDialog, SurfaceToolbar, etc. to use shorter
names, they were given Surface* names when the generic ones were also in
VE, but now the generic ones are in OO, so they can return to their
original names
Change-Id: I82c4fed8bcb3fb5630938c8bc4dd9b2d5f1a8c1d
In general, the direction of the MWExtensionInspector textarea
should be dependent on the directionality of the node it is editing.
The only exceptions are <hiero> and <math> that need to have their
textarea LTR always; these two inspectors' directionality definition
is overridden in their onOpen() method.
Bug: 56779
Change-Id: Iac5c1c3bf2c61b9fa36c9588c1734c91ca4305c4
