Fixed two bugs found after merging:
1. Opened the Math node inspector without editing
anything, then clicked somewhere else on the page,
it crashed.
2. Similarly, opened the Math node inspector
without editing anything, then clicked the
"Cancel" button to cancel the edit, it crashed.
Both of these problems are fixed by this patch.
The issue was with using the getFocusedNode() in
the inspector onClose function to save changes.
Also, I included some minor changes relating to
the last code review. =D
Change-Id: I6e200f2a228b71dc5af5aa9843c461f43b926f8d
Refactor a few things to make it easier for scripts to see
not just whether mw.libs.ve is present but also whether it
allows the user to activate VisualEditor.
Change-Id: I50da8d9a260207d4ec1c43254dfe738f91386a9e
Adding the <code> element as a matched text style annotation, plus some
tests (for all the other un-tested text styles as well, whilst I'm at
it).
We'll need an icon, a button and a way of the buttons not forever
extending the length of the toolbar to properly edit <code> spans, but
this is a start.
Bonus: unit test coverage for all TextStyleAnnotations
Bug: 51590
Change-Id: I5438bcf2ec6eeb2e50400f8013964f91c33ce455
Objectives:
* Make use of the new ve.ui.SurfaceWidget.js for image caption editing
Changes:
ve.ui.MWDialog.css
* Remove styles that are no longer needed
** -body class isn't needed if you contain the content in a layout and
configure it to be padded
** Toolbar styles are now part of surface widget
ve.ui.MWMediaEditDialog.js
* Wrap caption fieldset in an editPanel (also nice because we may merge
this dialog with MediaInsert and use a stack panel layout in the future
* Replace surface and toolbar with surface widget which manages both
Change-Id: I1b7e0e2ec1cfa30879360a7ebde2b0f35d26aca5
Objectives:
* Merge reference insert and edit dialogs
* Change workflow to put editing/creating a new reference first
* Add secondary page in dialog for selecting an existing reference
Changes:
*.php
* Cleanup unused files/messages
ve.ui.Dialog.css
* In the footer; make primary, constructive and destructive buttons
appear on the right; all others on the left
ve.ui.MWReferenceSearchWidget.js
* Fix documentation
* Remove create option and reuse section header items
ve.ui.MWReferenceInsertButtonTool.js,
ve.ui.MWReferenceEditButtonTool.js,
ve.ui.MWReferenceButtonTool.js
* Merge reference button tools
ve.ui.MWDialog.css
* Remove body styles, use padded option of layout instead
* Update selectors as per merging of dialogs
ve.ui.MWReferenceInsertDialog.js
ve.ui.MWReferenceEditDialog.js
ve.ui.MWReferenceDialog.js
* Merge reference dialogs
* Add buttons to switch between edit and select mode
ve.init.mw.ViewPageTarget.js
* Update reference button name as per merging of tools
ve.ui.SurfaceWidget.js
* New widget!
* Encapsulates a "sub-surface"
Bug: 51152
Bug: 50458
Change-Id: I8265febf4fd8f64d2ac40470ff033bac68b24d99
We need to detect if the endNode we are trying to move is
inside our original delete selection, and not perform the
move if it is.
Bug: 50076
Change-Id: Ib89706c8717d13829bf89e44c4fb39e16a00821e
Ran makeStaticLoader.php:
- Synced mis-match of css in demos.
- Added missing experimental.
We originally had experimental in static. They were removed
because the section became empty (not because we no longer
wanted them in static loader). If we don't want them here, we
should remove the entry from makeStaticLoader.php.
Change-Id: I275133d1cfebf174e54bf1b8f44465495949991a
Fixes mistake made in I50e996b9d2fde361238cde75e09baa5872e12223 which made scrollable panels not be, well scrollable.
Change-Id: I0ec59a1b76acf047b1a4d6de426a0ddb554a3e42
Objectives:
* Add option to layouts to control whether it's padded or not
* Rename "scroll" option to "scrollable" to better fit with it's boolean value
Changes:
ve.ui.Layout.css
* Add styles for scrollable and padded options
ve.ui.StackPanelLayout.js, ve.ui.PagedDialog.js, ve.ui.ReferenceListDialog.js
* Update use of scroll option
ve.ui.PanelLayout.js
* Add padded option
* Rename scroll option to scrollable
* Switch to using a class for scrollable option, rather than hardcoding CSS properties
Change-Id: I50e996b9d2fde361238cde75e09baa5872e12223
If the element is undefined, it would stand to reason that there are no annotations there.
Just sayin'.
Change-Id: I2b66e7adc2b3af19df1a3f490ab479627807636e
Misc:
* Updated signature of #showMessage to include allowing
an array of nodes to be passed. We pass this to jQuery#append
so we're just extending the explicitly documented subset of
things it could already do due to passing to jQuery#append.
Bug: 50472
Change-Id: I3f56820a4f14b0684bfa265e3eb5e3820f2a3513
The domains which contains articles are those from $wgContentNamespaces,
which by default is just array( NS_MAIN ).
Bug: 51527
Change-Id: I1f1356f1950c542ae05095a9ebd7b3d66ceb4e40
These represent <nowiki> tags. If the user doesn't edit the text inside
the nowiki, we round-trip the <span typeof="mw:Nowiki"> wrapper cleanly,
but if they do edit it, we unwrap it. This then triggers re-escaping
in Parsoid, and prevents cases where the user edits the text to no
longer need escaping but Parsoid still wraps it in <nowiki> because
of the <span typeof="mw:Nowiki"> wrapper.
In order to detect whether the contents have changed, the nowiki
annotation stores a copy of its contents. To avoid infinite recursion,
we have to exclude this attribute for hash generation.
Bug: 47678
Change-Id: I2edc46b6d87d2f91e952efcb09c0edae5166958f
In the DomFromData tests, we put the provided storeItems in the store
first, then run preprocessAnnotations (which puts annotations in the
store). However, in DataFromDom we ran preprocessAnnotations first
(which puts annotations in the store), then ran getDataFromDom (which
is expected to put the asserted store items in the store). Because the
order was reversed between these two tests, it was impossible to write
a test for an annotation whose toDataElement function adds to the store.
Fix this by reordering the operations in the DataFromDom test, doing the
conversion first and only then running preprocessAnnotations on the
expected data. This preprocessAnnotations call will not write to the store
if the test passes, because all annotations in the expected data should
already have been put in the store by the conversion.
Change-Id: I8f741d96fe12590fd711542794570fb95b1132d0
This way annotations inherit it too.
Also add htmlAttributes to the hash, and implement getComparableObject()
in terms of getHashObject().
Change-Id: Iea905f2b430f8e51c6026065be17b89b9a03cfab
Point out that the software may have issues, and point users to the "Edit source"
link explicitly.
Change-Id: Id84d76887038a3a6a9e11a203f19dc3db7703e6a
Previously they were only run from the dedicated standalone test
which meant they weren't being run from Jenkins.
Change-Id: If22456f0031c68b0c1e7621b35b1e79c0664da15
This effectively unwraps the annotation. Annotations can do this by
returning an empty array from their toDomElements() function.
Right now this is only supported for annotations, but once the converter
is rewritten to be entirely bottom-up, this is trivial to support for
other model types, and could even be used to implement unwrapping of
wrapper paragraph.
Change-Id: Ia572fd0610afccccfe795c257c0de9d003330f13
This is special-cased for annotations but should be supported for
all model types once the converter is rewritten to be bottom-up
entirely.
Add a toDomElements() stub to ve.dm.Annotation overriding the stub
in ve.dm.Model so there's a place for the new parameter to be documented.
Change-Id: Id81da87b8b83d556a3618cc6187b22443a1e37e6
This means that instead of creating a DOM element for an annotation,
then appending stuff to that DOM element, we queue up the things to
append and only create the DOM element after we've built everything
that's going to be in it.
Most significantly, this moves the toDomElements() call to the close
function, which paves the way for passing in the annotation's contents.
Change-Id: I98a7d3ebb0f3eb8627c22348b48596906db2646e
It is already loaded by VisualEditorMessagesModule in
content-language. It was added here in error and caused it to
be replaced with the user language version at run time.
Bug: 47730
Change-Id: I82304bea0a5eadbe254beccd1899621d0bd0be46
This way if both are the case, the user (or VE, if possible)
will deal with badtoken first instead of potentially having to
solve the captcha twice (as each handling of the error does - and
should - end with an early return).
Change-Id: I9e4264a7001ffa9654bfab02cc955aa36ff5b6aa
We already call clear() 4 other times in this code path, including
one right at the end of change(), which is called right before this
clear() call.
Change-Id: I6d5ba5075e1b24a981546243977c6a8501748c5f
