Following on from getDomFromModel, this returns a document model
instead of element linear data. The only instance that hasn't been
replaced is in rich paste, where we need to sanitize the converted
data before constructing the document model.
This should be cleaned up in a later commit.
Change-Id: I37a2b641632af2cb515e3409deed5cd1fa358af5
Was already implemented in the parent class. Moved setPasteRules() so it
would still get run, everything else had already been moved.
Change-Id: I55ef2622c9eacc8b46bd3487919165bccfc347d5
Also, as OOjs UI's StackPanelLayout was renamed to StackLayout, and the
showItem() function to setItem(), fix uses in VisualEditor.
Change-Id: If153e5e7c3a7c60e3d62e20aac8fabd4eaaa73c2
Currently it takes 4 arguments which are all properties
of the document model, so just pass the model instead and
access the properties later. Rename to getDomFromModel.
Change-Id: I0c378a04dc08b9b90bdc3984f8fa8c4acfe0b667
Earlier check-in for a VE media interface test
inadvertently re-named a page element that
should not have changed.
Change-Id: Iac1ef365e9cb3912977c8a89f3158ad9d122c93d
Add rtl/ltr-related classes to the toolbar based on cursor context, so
certain icons can change based on inline and block directions.
Change-Id: I1b6e450226bf8da820fb622f28c1c3062c534bb0
Moving items around in the MetaList only works if all deletions are
done before all insertions. This was almost but not completely true:
when moving an existing item we would delete it and immediately re-
insert it, meaning that if there were multiple items being moved
there would be a removal after an insertion.
Instead, let the insertion loop re-insert the moved items while
making sure not to emit insert events for them. This is how I
originally intended the code to be structured, but I thought that
duplicating the insertion would be equivalent to protecting the
emission of the insertion event. Clearly I was wrong.
This fixes weird bugs where categories sometimes appeared twice
in the category dialog depending on where the category was in
the list and what the exact length of the list was (i.e., whether
the binary search in the MetaList found the first or second item
with identical offset and index).
Change-Id: I4cd131052dda396add7a0e2dbe2383bb5c1b5721
Sometimes a save is not a save, but a switch to the wikitext editor; in this
case, the save dialog doesn't exist, so don't assume that it does.
Bug: 57947
Change-Id: Ic2df7d2066ba03564ed531e1d31351cd27441abe
Also:
* Added modules/syntaxhighlight to csslintignore because
it is broken right now, so it's hard to fix those warnings
without being able to verify it.
* Fixed a typo in the grunt-watch config that accessed an
inexistent property.
Change-Id: Ib81572506786b6a1203c454d1b2b91bb6ae2a3de
That's where they belong IMO, since ViewPageTarget is the one that
has .activate() and .deactivate(), and mw.Target doesn't retain any
state (apart from some caching things).
Change-Id: Ia6cf5bac9054163d54ab492d691d8ce9d6a3bb90
* changes:
Split apart onSaveError logic for other mw targets
mw.ViewPageTarget: Remove unused onTokenError handler covered in onSaveError
Create base MobileView config and target refactor
Changes include:
* Target mobile for ve dependencies
* Create mobile view constructor
** Some tools like dialogs are excluded for now
* Refactor mw.target to permit code reuse
** Split out pageTarget view functionality from core init methods
Change-Id: I786b63ab57518fc6af7761501259ed66592f70e3
It's possible for the user to put the cursor back from the inspector
in the surface without triggering a selection change, if the selection
was collapsed and they clicked in exactly the right spot.
In practice, this can happen if the link inspector is open in creation
mode and the user clicks to drop the cursor at the same position where
it was when the inspector was opened.
When this happens, the inspector wouldn't close, because it only closed
in response to selection changes. If the user then typed something,
weird things would happen.
To prevent this state (cursor is in surface but inspector is open) from
occurring, close the inspector and hide the context when the document is
focused. This fixes the link inspector creation mode issue, and it also
causes the link inspector to no longer briefly remain visible after the
user has clicked out of it.
Bug: 56976
Change-Id: Ib70fc13031873009a175e4b049a07694a87ce25d
They contain iframes and those need to not be display: none;
in order to make Firefox happy.
Bug: 57568
Change-Id: I177877bff3c3b18bfc87ee4e6afa7e60fea26ffc
There's no point in hiding the WindowSet if we've already closed the
open window in it. In fact, there's no point in hiding a WindowSet
pretty much ever.
Change-Id: I49a02b5d255b266eb9e0a537cb64082eb0ad5e4b
ve.ui.MWReferenceDialog.prototype.teardown:
* Pass ranges rather than nodes to transaction builders
* Don't do a removal in insertion mode, we know the removal range
will be empty
ve.dm.Transaction.newFromDocumentInsertion:
* Correctly splice the edited internalItem into listData in the case
that newDoc isn't a document slice of doc
* Rename range to spliceItemRange for clarity
* Introduce spliceListNodeRange and set it to either newDoc's
listNodeRange or doc's depending on whether newDoc is a slice of doc
Bug: 57683
Change-Id: Iae7de7701ae86bed89b707038407243d82249e1a
Using display: none; on the inspectors WindowSet causes Firefox to
neglect to load CSS in the inspectors' iframes, which means the frame
never initializes and the inspector never opens.
Bug: 57568
Change-Id: Ia1a0ce78754fa1318a7d439abe1f0e2f86420e7a
Currently we assume getNearestContentOffset will give us something
sane however it can return -1 when there is no nearby content and so
an exception is thrown. In this case we have to create an empty
paragraph to place the cursor in.
Change-Id: Ic6c19da881e47ff6be45cdaa4b71bfcc1c654796
MW extensions are XML not HTML, so we shouldn't build them as XML
to prevent HTML specific rules being applied, such as <source>
always being self closing.
Bug: 54577
Change-Id: I84af4a29cd1c4ae4d1db4f70a4012a8ad0f98bf6
* changes:
Make autonumbered external links inspectable
Always remove the annotation when the remove button is clicked
Add abstract getAnnotation() method to AnnotationInspector
When the target of an autonumbered link is changed to a URL, it's kept
as an autonumbered link and its target is updated. When the target is
changed to a MediaWiki page, the autonumbered link is removed and
replaced with an internal link with the text set to the target.
So for instance, if you inspect [http://www.example.com] and change
its target to "Foo", the result will be [[Foo]].
The core of this commit adds support for inspecting nodes to
ve.ui.LinkInspector. This support should probably move into a
class in between AnnotationInspector and LinkInspector, perhaps
called HybridInspector or something, but I'm deferring that for now.
LinkInspector allows changes to inspected nodes to be reflected either
as attribute changes on the node, or by replacing the node with something
else. MWLinkInspector uses this feature to replace the autonumbered
external link node with an internal link annotation when the target is
set to an external link.
Bug: 53505
Change-Id: Icb404af84c24574438e4de3ef05bbd1993b593f7
When you inspect a link, then close the inspector immediately,
nothing should change. However, AnnotationInspector was comparing
the generated annotation and the existing annotation by hash, and so
would consider an annotation with htmlAttributes different from
one without. This meant that inspecting a Parsoid-generated link
and then closing the inspector would cause a transaction to be
processed that removes the htmlAttributes from the annotation.
I believe a similar issue also existed for annotations with attributes
like origTitle and hrefPrefix, although I didn't reproduce this.
The fix is to have AnnotationInspector compare annotations by the
hash of their comparableObjects, rather than their hashObjects.
Change-Id: I848ffc2b7e7b2c67754a0ece3af105ffafa837ec
Didn't bother to deduplicate blur-focus event pairs that occur when the
focus moves from the documentNode to the pasteTarget or vice versa
(this happens when switching between normal selection and FocusableNode
selection).
Change-Id: If1ccd2fbf11de956b6c2364ae81b9dc20a1bf409
Remove weird check that prevented a removal from happening if the
subclass's getAnnotation() method returned null.
This caused a bug where if you inspected a link, typed an invalid
link target (e.g. '|'), then clicked the remove button (trash can icon),
the inspector would close but the link wouldn't be removed.
However, if you typed something that was a valid link target (or didn't
touch the input at all), the remove button would work as expected.
Change-Id: Ib6efc2a5827b109c6b38185e6d89b7bb29b13a75
It was relied on, and all subclasses had one, but for some reason
it wasn't defined as an abstract method.
Change-Id: I6d48f8ee666bd339be87744840c6edb4abb56dbf
Otherwise the old save dialog will still be around if the user sets up
another surface (e.g. a second edit), but won't be attached to the DOM.
Bug: 57654
Change-Id: I23c10849a212534bdd0600637d8ad4fa3ebc4fb7
* 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
This is a prerequisite to browser-based grapheme cluster handling, which
is needed so left/right cursoring and backspace behave as users expect.
modules/ve/ve.js
modules/ve/ce/ve.ce.Document.js
modules/ve/ce/ve.ce.js
* Revert cluster-aware splitting to trivial javascript code unit splitting
* Rewrite ve.splitClusters as a trivial compatibility method (remove soon)
* getClusterOffset/getByteOffset use unicodeJS.graphemebreak.splitClusters
modules/unicodejs/tools/unicodejs-properties.py
modules/unicodejs/unicodejs.graphemebreakproperties.js
modules/unicodejs/unicodejs.js
* Allow grapheme break tests to work with surrogate pairs
demos/ve/pages/minimal.html
demos/ve/pages/multibyte.html
demos/ve/pages/unicode.html
* replace file with more precise tests
modules/ve/test/ve.test.js
* Remove reference to grapheme-based splitting (which is no longer used)
* Correct typo
Bug: 53757
Bug: 51472
Bug: 51596
Bug: 51846
Change-Id: Ife34c87ebe40bc1689298b592eec5c0cdc2f7589
Register ctrl/cmd+shift+v as a trigger which sets a flag for the
next paste event.
When the paste special flag is set, modify the sanitizeData method
to strip all annotations, and any elements other than paragraphs.
Bug: 53781
Change-Id: If814e1786ffa805b52ab32f4a06f52da743fd9af
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
There was a bug when you moved over an image with the arrow keys:
if your selection was on an image and you pressed an arrow key, the
selection would move but focus would remain with the paste target
rather than going back to the document node, which caused strange
symptoms (immobilizing the arrow keys and scrolling horizontally)
in Firefox.
Bug: 57600
Change-Id: Iaf6a49787dd2fd2f3f88abd0d1f5ae512fd3fd68
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
Move the userPrefEnabled check out of isAvailable and instead check
it in-line with isAvailable for setting up the tabs with CSS, but
not for the veaction=edit function.
Bug: 55900
Change-Id: I23984e377ff3fc797e921546492b8c73a5101235
* 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
ve/ce/SurfaceObserver.js
* Do not setTimeout if frequency === null
demos/ve/eventLogger.html
* Standalone event logging script
ve/test/ce/imetests/*.js
* JSON event logs for various tests/browsers/IMEs
ve/test/ce/ve.ce.test.js
* Add an IME test
VisualEditor.hooks.php
* Add test files
Change-Id: I50e89d5a289f3fcb4fe2a6835a2ec96fb497242c
* modules/ve/test/ce/ve.ce.TestRunner.js
Class to interact with the CE Surface and document in tests
* modules/ve/ve.EventSequencer.js
Wrap setTimeout/clearTimeout calls (for easy replacement in tests)
Change-Id: I2e2407e2b169ae77237c87bf8857b3026cc7efce
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
setValue() doesn't do anything if this.value === value, but with
sanitization it's possible for that to be true while the value in
the DOM is out of sync and needs to be changed.
The fix is to check for this.value changing and the DOM changing
separately.
Change-Id: I5f571445f5729f5477902c155a4ee9588b7194a8
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
Also encourage callers to pass plain objects unless they know what
they're doing; it's almost always wrong to pass in a MetaItem.
Change-Id: I8e8ef8ac7f77ec9f929d797e467b9c9d1140d721
This was a regression that occurred when the toolbar was refactored
recently. The correct and previous behavior was if the cursor is in a
location where the context would show an inspector tool, that inspector
tool should be active in the toolbar.
Change-Id: I8ac2b1bd21b843db30e3e9f951702378007e139a
Otherwise you get rendering issues when you resizing adjacent
resizable nodes and you drag over the other node.
Change-Id: Ie70833fa6ae38879b70a19e8d7ecec13a1d54e92
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
The generation promise can get resolved (e.g. AJAX request can complete)
after the node has been detached. In that case accessing this.model.doc
will fail, so check for this in doneGenerating().
Also attempt to abort the pending promise on teardown.
Bug: 56649
Change-Id: Ia55f1c2c8dc3a3619c0b50795e50fcae4bc6471f
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
Syntax highlight editor shouldn't rely on GUI language directionality
but always allow for LTR text editing.
Bug: 56780
Change-Id: Iae7f9eee20ffb9a003830503865458918f5e1df3
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
