In ve.dm.Document.getMetadataReplace(), we used to only merge metadata
if the amount removed is larger than the amount inserted. But this
could end up putting metadata in odd positions, for example if you
have Foo[[Category:Bar]]Baz and you delete 'ooBa' and replace it with
{image}xxx{/image}, then the category ends up inside the image.
We should always merge metadata when a segment is deleted, so that it
appears outside any new structure added.
There's a weird corner case here when a segment is removed but no
insertion is made: the removed metadata then needs to get glommed onto
the next element. We extend the insert/replace metadata array
when this happens.
Bug: 53444
Bug: 53445
Change-Id: I51d55fb370b473273f9cf152fdd0f356377d4109
Was previously broken as getSlice was using ve.Range#equals to
compare ranges which is direction-sensitive.
Bug: 51538
Change-Id: Ib58d1d8fd11b62388c111a5da66171d13a9db9c2
Currently ignores all non-element data, but element content (e.g.
images) can be annotated.
Added test cases and updated the test runner to only compare
store indexes for a more readable output.
Bug: 50127
Change-Id: I234586a28072811c8288aab56f6abaaa0da0c88d
Objectives:
* Use a class for toolbar groups to add more functionality later
* Rename addTools method to setup
Changes:
*.php
* Add link to new file
* Move ui element classes up for more general use
ve.init.mw.ViewPageTarget.js, ve.init.sa.Target.js, ve.ui.Context.js,
ve.ui.SurfaceWidget.js
* Update use of addTools method
ve.ui.Tool.css, ve.ui.Toolbar.css
* Move styles between sheets
ve.ui.Toolbar.js
* Rename addTools to setup
* Use ve.ui.ToolGroup objects when building tools
ve.ui.ToolGroup.js
* New class, encapsulates tools
Change-Id: Ic3a643634a80a8ac7d6f6f47f031d001c7efaee7
Objective:
* Make it possible to make a toolbar without a surface
Changes:
*.php
* Links to new file
ve.ui.Toolbar.js, ve.ui.SurfaceToolbar.js
* Split toolbar into generic and surface specific classes
*.js
* Update symbol names
Change-Id: Ice063a2fb67b5ce5155cdc96a0d47af49eee48cb
This is bit of a hack, as leading whitespace could be
significant if styled with white-space:pre.
Long term VE shouldn't be editing the user's HTML, and
should just highlight potential formatting issues.
We avoid the stripping in preformatted elements as we
expect they will have that styling.
Bug: 51462
Change-Id: I654d98e17dd604cb2a192831ff3f3597f95b9962
Because trying to work out how broken your test case is
by looking at two (potentially multi-page) serialisations
of the DOM summary is a pain in the arse. Diffing two
HTML strings may highlight the problem much more clearly.
TODO: Is it possible to defer the calculation of the HTML
infused summary object until we have determined the assertion
has failed. Otherwise we're slowing down our tests for no
reason.
Change-Id: I873bf2479ab81d15389792bd59d15580da63941a
These have been pointing to the same method for a while now,
we can safely remove these obsolete aliases and just use it
as generic copy.
* Each file touched by my editor had its new line at EOF fixed
where absent
* Don't copy an otherwise unused empty object
(ve.dm.Converter)
* Use common ve#copy syntax instead to create a link
(ve.dm.Document, ve.dm.example)
* Remove redundant conditionals for isArray/copyArray/copyObject
(ve.dm.example)
Change-Id: If560e658dc1fb59bf01f702c97e3e82a50a8a255
This is the language inspector UI engine with ULS core.
The Language Inspector works alongside ULS to choose and change language
blocks in text. The inspector was based on ve.ui.TextInputWidget and
now changed to inherit ve.ui.Widget and display details in a table
instead of an input textbox.
Added jQuery.ULS module:
* Repository: https://github.com/wikimedia/jquery.uls
* Latest Commit 728f112ffc90b03b50c0109487886a2647f12020
* Taken 'src' / 'images' and 'css' folders into modules/jquery.uls
Bug: 47759
Change-Id: I3c9fd6c135c05a54f6c7fc28c5962fc0a6677806
We would dirty-diff "</span>\n<!-- comment -->\n<span>" to
"</span>\n\n<!-- comment --><span>", i.e. the second newline made
a bunny-hop to the left over the comment.
The actual bug turned out to involve a double bunny-hop, with
"</span> <!-- comment -->\n<span>" turning into
"</span>\n <!--comment --><span>", i.e. the newline bunny-hops
both the comment and the space.
This happened because outputWrappedMetaItems() didn't take
wrappedWhitespace into account when restoring meta items and
associated whitespace. I hacked a check for wrappedWhitespace into it,
but we should really just rewrite this pile of hacks into a unified
system for queuing and processing both whitespace and metadata.
Change-Id: I4375f4c07983ffec6877d0371aeaa9bf6e65fd6e
To avoid confusion between IV store indexes and the index
within the set, rename them to storeIndex and offset.
Change-Id: Ic7d741bd5d39240d63fdc04a2df45658a64441de
Pretty straightforward, although we should start thinking about
grouping/hiding 'advanced' formatting options in the toolbar.
Making this button experimental for now until we've come up with
a way to deal with this problem.
Bug: 51590
Change-Id: Ieb1935b742aced4b883d8a194e6cb69be68473d0
To achieve this we need to evaluate the DOM contents of
transclusion nodes to see if it consists solely of meta items
and whitespace.
To check for meta items we do a model registry match, but with an
additional parameter to exclude mwTransclusion types as a possible
result (as the first item may be a meta tag, but with a mw:Transclusion
typeof attribute).
Bug: 51322
Change-Id: I89a220350fb7e10e15f3682d21438539196a5846
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:
* 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
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
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
An empty document is one which contains no 'real' data, so
we should check for meta-only documents when deciding whether
to add in a wrapper paragraph.
Bug: 50289
Change-Id: Ib3ebf0717aa0c6c51fd1d0b14e95de50b2842647
It was being used correctly in the textual replace case, but it was
omitted in the structural replace case. This caused rare, insidious
metadata placement bugs that I haven't been able to reproduce outside
of newFromDocumentInsertion testing, but this might explain some of
the odd category bugs that have been reported.
Change-Id: I1424e482303853f285e4516a93c9609076648eff
Objective:
* Make the majority of link inspector, which is generic to any annotation,
usable for other annotation inspectors
This was merged earlier (f7107fa20d) but broke master, so it was
reverted (092fa74dee). This commit also incorporates 5dcf5d1c49.
Change-Id: Ib9190dee66ce064d69962f9c4c5b3a710be8ad07
Any annotation could have a style attribute which has
a compound effect, and this also prevents roundtrip
errors. Button tool logic should prevent any annotation
from being applied twice which shouldn't be.
Bug: 49755
Change-Id: I8502a55cd2b195d28d0e2ecd63f15de670f80d60
This was broken after 92c38ea removed ve-mw files from the
static loaders but didn't update makeStaticLoader.php so
it was harder to keep the files in sync and a few minor issues
on the documentation pages.
Since the files are still mixed in the non-mw modules the only
way to exclude them is to do what was manually done in 92c38ea:
Filter out paths starting with "ve-mw/" from non-mw modules.
Change-Id: Id58ee89ac18c63c01719dc11ec7a07ddeee3ea0b
Objective:
* Make the majority of link inspector, which is generic to any annotation, usable for other annotation inspectors
Change-Id: I1f7e9c13537105da7aa0351c9c92e8af5eb5a3f4
