ve.dm.MWTransclusionNode
* Implement getClonedElement to remove originalDomElements
and originalMw. We don't want to put these in the clipboard
as there is no guarantee they are the rendering of the current
set of parameters (a refresh may be in progress) and they may
confuse the converter on the way back in.
Remove about attribute to prevent about grouping of duplicated
nodes.
* Set an extra attribute to flag that the outputted DOM doesn't
have any generated content attached to it that can be stored
on load.
* Check for said attribute in toDataElement and skip the
storeGeneratedContents step. This will trigger an async update
of the generated contents on paste.
ve.ce.Surface
* Call cloneElements before writing to pasteTarget so data in external
clipboard is stripped of generated contents.
ve.dm.Node
* Only strip data-parsoid as other attributes may be meaningful.
ve.dm.mwExample, ve.dm.Node.test
* Update tests
Bug: 58241
Change-Id: I3e15cc97e94747647078204a0b398e6ac3ec6382
This change is meant to transform the current block image node rendering
in ContentEditable from the nested <div> structure to a <figure> tag more
closely matching Parsoid's output, with CSS to style it the same. This is
mostly so we can work with and display attribute changes, like 'type' and
'alignment', without constantly destroying and rebuilding nested <div>
structures.
This change also includes all the attribute changes that will be called
when the media edit dialog changes image type, alignment, size, etc.
Node: The mw-classes 'thumb', 'thumbinner' and 'thumbcaption' are
preserved in the structure of the <figure> but CSS designers should note
these styles are no longer necessarily attached to <div> elements.
Bug: 53436
Change-Id: I40065acd9fd59d30f94b5336736d4986e8de15aa
Move all text styles, and the remove styles button, into a new 'list' toolbar
group, using the text-styles icon. Less-used text styles (strikethrough, code
and underline) are demoted, with remove styles at the end, and bold and italic
promoted.
Now re-label the "More" catch-all to now be "Insert", which is what's left.
Change-Id: I66a1bba347ea64e540106b1090995b3117a8b1b2
This introduces a small reorginization of how commands are registered so
that they are associated with their corresponding symbolic names.
This change is mainly to aid with event tracking, but it might be
generally useful for other things as well.
Change-Id: I2ccf4522f786a54c1f5395008b7b0333a1fa6072
We already do this for removeHtmlAttributes mode.
Add tests in ElementLinearData and ce.Surface. Get rid of unused
clipboardHtml param in ce.Surface tests as it is unused and replace
with clipboardKey flag which tests the VE->VE paste path.
Change-Id: I0cd82a37d6e765ecab489dc22f642ebbcfbb5387
Make available only as a static method so you don't accidentally
change a node without using a transaction.
Change-Id: If27442b502ec176a58e75ef4f9afa5119d06dcc5
ve.ui.Context#updateDimensions does two things: it updates the position
of the popup by measuring where the selection is, and it updates the
width and height of the popup by measuring the contents of the inspector
or the context menu.
In some cases, measuring where the selection is fails, and
ve.ce.Surface#getSelectionRect returns null. This seems to only happen
1) in phantomjs while running the test suite and 2) when an inspector
is opened and doesn't adjust the selection while opening. I suspect
it has something to do with the selection not having been recently
set or the documentNode not having focus, but I haven't investigated
this in depth yet.
Prior to 5d7673eb, the editor would simply crash of the position
measurement failed. 5d7673eb changed this to just bail completely if
the position couldn't be measured, but that's also wrong. Without a
position measurement, we can't update the position of the popup, but
we can still adjust its width and height, and we should.
The failure to adjust the popup's width and height in this case was
causing a bug where opening the link inspector with the selection
set exactly to what the inspector would expand it to would cause the
popup's width and height to never be adjusted, and most of the inspector
to be invisible.
Bug: 58301
Change-Id: Ia6504e0a7b0cd1affbff2632e9f573684f1d5dcb
Captions were not in the allowed lists of children for tables.
This causes an exception to be thrown if you try to do fixUpInsertion
on a transaction containing captions.
Bug: 58318
Change-Id: I866e015c14e787830c45da93dfed9d2119fb0865
Bonus: give both the language name and page name
lang and dir attributes.
Further bonus: reintroduce message that was deleted
earlier with all of its original translations.
Change-Id: Id137ff9a069799b6c09574b72f450eac6665d144
It appears that if the pasteTarget is given focus too close to the
range being set it may not take effect in time. Moving up to before
any of the selection setting logic seems to fix the issue.
Bug: 58283
Change-Id: I9bfb0ab6952863496fb3548e6804cb347d52cc57
The shim triggers bug 58249, but that's not as bad as we thought.
It turns out LocalisationUpdate still finishes despite the scary
exception, it just skips VisualEditor and finishes the rest successfully.
I will work on making the LU error more useful, and eventually
making it support JSON blobs, but the shim isn't causing a
lot of damage for now.
Change-Id: I92f11524d891e901f1a089dd8cad1232478a5ee4
Move containsElementData to FlatLinearData next to isElementData. Move
tests for both methods to FlatLinearData.test.js.
Change-Id: I07a192f5925da7cc763efe5e41427f1f47d85850
In Chrome you can paste the empty string which triggers
the paste events but doesn't change the paste target. This
results in the insertion of the context character on empty
lines. To avoid this we can detect if the selection we put
around the context character is still there and abort the
paste.
Bug: 58138
Change-Id: Ib73465a2376cd316dbac6ce2567ecb64bc500307
This reverts commit 9abad0385d.
I guess for now we'll just have to keep these in sync manually until MW core is updated.
Bug: 58249
Change-Id: I243303bdcbd048248776866fa12a17fc8279b80f
It used to be that when you closed a dialog, the thing that the dialog
inspected or inserted would be selected. For insertions, the selection
will now be collapsed immediately after the inserted node.
For modifications, the original behavior was kept, as it makes sense to
keep selecting the node that the user had to select in order to access
the dialog. For removals (only possible in the transclusion dialog),
the selection ends up as a collapsed selection at the location where
the removed node used to be; this was already behaving correctly,
as we get this behavior for free with offset translation.
Bug: 54957
Change-Id: Ibd14e8084d67a9ee85e3bac075c3fb50f27b05b2
