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
Code speaks for itself, see also bug 52441.
Though not introduced by 14343c7bf7, that made the bug worse.
Bug: 52441
Change-Id: Ie2b80b22df03eb563de8812a47fb25152527e786
For configured wikis, show a dialog that welcomes the user to the
amazing and fantabulous world of VisualEditing, which is not only full of
wonderment and joy but also may lead to increased popularity and love.
The dialog only shows up once (uses a cookie).
Change-Id: I8e7c4dc2c63b36594378a543b9d66291395eebcf
* Generate the edit tabs and the section edit links in PHP, with a
fallback in JS for cases where we don't have them yet due to
caching. But only change things if VE is enabled, and have the JS
correct the state if the wrong cached HTML comes through.
* Make the order of the tabs/links and the messages to use as captions
configurable
* Make the edit tabs and section edit links always be present in the
page (regardless of namespace, user prefs, etc.) but be hidden and
have JS unhide them (using html.ve-available) if appropriate
* Add appendix messages so we can do a superscript "beta" even in places
where we can't use HTML in the message
VisualEditor.php:
* Add new hook registrations
* Remove edit link caption messages from the init init module because
they're now added dynamically in VisualEditor.hooks.php
* Add a noscript CSS module so we can hide some things in JS-less
environments
* Remove $wgVisualEditorTabLayout and replace it with
$wgVisualEditorPosition
* Add config vars for link captions, with null causing us to use
the default caption
* Add config vars for link caption appendices. Too many config vars
but we'll clean that up later
VisualEditor.hooks.php:
* Dynamically add tab messages to the init init module
* Remove unused globals in onBeforePageDisplay()
* Add noscript CSS module
* Add a SkinTemplateNavigation hook that changes and reorders the edit
tabs as appropriate
* Add a DoEditSectionLink hook that overwrites the edit section links
* Export the new config variables to JS
VisualEditor.i18n.php:
* Add beta appendix message
* Add a message for the default VE edit section link
ve.init.mw.ViewPageTarget.init.css:
* Remove the animation on the edit section links
* Darken the color of the brackets and the pipe from #ccc to #555
* Style the beta message to be superscript-like (but not real <sup> to
avoid moving the baseline)
ve.init.mw.ViewPageTarget.noscript.css:
* Hide the VE edit tab, the pipe and the VE edit section link initally
unless and until JS unhides
ve.init.mw.ViewPageTarget.init.js:
* Toggle .ve-not-available / .ve-available
* Edit tabs
** Only generate the the edit tabs if they're not already there from PHP
** Rewrite the edit tab generation to mirror what's being done in PHP
* Section edit links
** Same as for edit tabs
** Also add mw-visualeditor-expanded to pad the brackets
ve.init.mw.ViewPageTarget.js:
* #ca-ve-edit is now always the VE tab (and #ca-edit always the
edit source tab) so update the .selected behavior accordingly
Change-Id: Idcb15faea7fabe5fe7578b1508079969b27d2469
In some cases this would make VisualEditor be way too aggressive in
forcing you into the first matching page.
Bug: 52420
Change-Id: Ie0a793853d884ee0abf490a99c5214082e9dbf27
Added wgIsArticle to isViewPage checks, otherwise we were attempting
to load VE dynamically on Special:Move/Delete, which resulted in a
broken h1 title and odd behavior off the 'Read' tab.
Also added !wgIsArticle to pageExists. This is a bit of a hack because
we don't have any info on page existence in the JS on these pages
(I think?). But it's better to display 'Edit' for a page that doesn't
exist, than 'Create' for a page that does.
Bug: 49000
Change-Id: Ib47e5524d41e6066b362e0f5645750c769de5193
By testing against a regex of legal title characters we can determine
if the entered text is a valid internal link. If it isn't we should
prevent the link inpsector from creating/changing the annotation.
Bug: 33094
Change-Id: Ia1df602601e4e82fc351279e432c28c425f5157a
Not having a description yet is fine, but they should at least
be indexed as blocks so that they are searchable and listed
in the jsduck generated pages. jsduck defaults to @method + name
of prototype property. And it even guesses parameters sometimes.
Search: \n\n([a-zA-Z\.]+\.prototype\.[a-zA-Z]+)
Where: modules/ve,modules/ve-mw
Where-Not: modules/ve/test
Replace: \n\n/** */\n$1
Added @return in a few places where it was easy to add.
Change-Id: I830c94cc7dbc261bd7a077391f930cbfff165f9d
mw.ViewPageTarget is currently getting events from both the
platform target toolbar and context menu toolbar because the
event is emitted from within the toolbar to the surface.
Instead we're now emitting it on the toolbar itself and it is up
to the binder to access the correct one and listen to its events.
Bug: 52317
Change-Id: Ibd8053768e82b1df91081bd77a172628ea855db7
Follows-up 867ec44a9.
Because:
- #toolbarPosition is emitted more than once (so this
should at least have been a once() bind, not a connect)
- It is emitted for more than 1 toolbar (includes context menu
toolbar)
- Semantically incorrect (we want to know when the surface changes
not the toolbar)
- We want to get rid of that event entirely and this is the last
use of it.
Change-Id: Ica5ed04052f48fe84607abab72bcf65f97d689ed
Follows-up db3da5d. Also scanned code base for more matches but
looks like those have been cleaned up already.
Change-Id: I62d1c4367e1ed7b7162d7b688227dfa5dca562aa
Though this is already handled by Ie50b63ba5064e85d26 for the
server-side, and that should automatically reflect to the
client-side. Since we're dealing with cache conditions in
wmf-production where the user.options manifest does not yet
contain an entry for these relatively new preferences, lets
transfer the default value here as well. This does not affect
logged-in users (since their user options are always up-to-date
and embedded in the page).
Also made ve.support.es5 be casted to boolean. Previously it
would be a reference to JSON.stringify (if supported), or the
bottom value of whichever feature the browser didn't support.
Doesn't change any behaviour but should make things slightly
more performant when this value is evaluated.
Change-Id: I9ca430051ae6f4e603c2d89982e540e455055255
On browsers that implement the Navigation Timing API, performance.now()
provides values with microsecond precision that are guaranteed to be monotonic
(i.e., they are not subject to skew due to changes to the system clock).
This patch adds a `ve.now` utility function that will use this API when it is
available and fall back gracefully to `Date.now` when it is not.
Change-Id: I377025fcb23cb26399b9e437e33c8afa138916af
In target#setUpSurface, both target#setUpToolbar and
target.surface#initialize are called. #setUpToolbar does an
asynchronous animation.
After that animation is completed we call target.toolbar.initialize
and target.surface.context.update.
Right now ce.ProtectedNode needs to update the position of its
shields when the CE Surface changes position (which it does when
the UI Surface changes position because of the UI Toolbar changing
position), and does so by listening to toolbarPosition.
Adding this event to allow it to listen to that instead.
Change-Id: I826986794630c04c34cef6da36ccb15ff7dde49a
Formerly known as "The greatest commit in the history of the world*".
* Within a 3 block radius of Drayton Park and Auburt Park, starting
from July 30th at about 9pm or so.
Bugs:
* (bug 51404) Allow escaping out of the link inspector when in creation
mode (no text is selected, text will be inserted based on link target)
and the text input is empty
* (bug 51065 and bug 51415) Keep model and view in sync when changing the
link inspector's text input value and showing options in a menu
* (bug 51523) Either restore selection at the time of close to what it was
before opening the inspector (when using back) or to what it was before
closing (might be changed by transactions processed during the close
method) - this makes it simpler and more natural when clicking away from
the link inspector, even when there are changes that must be saved by
the link inspector on close
Bonus:
* Use only the light blue highlight color for menu widget items - the
checkmark already displays the selected item, the dark blue is just
masking the current highlight position and confusing the peoples
* Remove links when the user deletes everything from the link inspector's
text input and then closes the link inspector
* Replace select menu's evil "silent" selectItem/highlightItem argument
with a new method called initializeSelection which sets both selection
and highlighting to an item without emitting events - this is needed
when synchronizing the view with the model so the model isn't
immediately told to change to a value it already has
* Make the MWTitle lookup menu not flash like crazy as you type (this was
caused by a copy-paste oversight overriding
initializeLookupMenuSelection unnecessarily)
Bug: 51404
Bug: 51065
Bug: 51415
Bug: 51523
Change-Id: I339d9253ad472c2f42c3179edc84a83d27561270
The 'ext.visualEditor.genderSurvey' module was introduced in I2b4aba6a9
for the purpose of instrumenting a short-lived microsurvey that would be
concomitant with the deployment of VisualEditor. The survey has now run
its course; this patch removes its code.
Change-Id: I8be6198a66957d792757a5312e9e71b3c8cdd1e3
This code caught badtoken errors on load, but we can't get those
any more since the API module was split and we no longer send a token
on load. badtoken handling on save is done in mw.ViewPageTarget.
Bug: 51253
Change-Id: Idb172ee46b7142681d41e593eacd9600b8f11a9a
7557dd39ed make the badtoken handling code unreachable. Revert that
change, and fix the rest of the function to deal with the possibility
that editApi is undefined. Let handling of the read-only mode error
and any other errors fall through to the bottom of the function.
Change-Id: I0673f2bb629e5cc9449675c1074d283e3926e1d5
VisualEditor.php
* Add CSS file
ve.ce.MWMathNode.js
* Wrap the image in a span, so GenerateContentNode doesn't
try to nest an image inside an image
* Remove unnecessary attribute setting
* Only pass unwrapped image to deferred.resolve
* Retrigger MathJax rendering
ve.ce.Node.css
* Use inline-block for image wrapper
ve.dm.MWMathNode.js
* Mixin GeneratedContentNode and implement getHash
* Copy over functionality of MWTransclusionNode:
+ Just store data-mw for attributes
+ Store orignal(DomElement|MW|Index) for selser
ve.init.mw.ViewPageTarget.js
* Add mwMath to the toolbar
ve.ui.MWMathInspector.js
* Remove static.InputWidget, not required in this architecture
* Use multiline TextInputWidget
* Only update mw attribute
* Allow creation of new math nodes
ve.ui.MWInspector.css
* Set height of TextInputWidget
Change-Id: I520f8ccc9f89a2ce70aa1d9e02ed0c6cacbecc2f
It's totally unnecessary, and actually caused a bug where new references
got about="undefined", which caused Parsoid to about-group adjacent
new references together.
Bug: 52228
Change-Id: Id40d53c72a35412d612ae9441ae3d561622c1bec
When we encounter a ref tag inside the mw-data of a references
tag, we pass it off to the converter and store it as nested data.
In toDomElements we convert any nested children and write them
back to mw-data if changed.
As refs in references are invisible we exclude them when generating
the references list in ve.ce.MWReferenceListNode.
Bug: 51741
Change-Id: I31d06616849a00449df0fc77f3b33e46207cdc7f
op !== operation in all iterations of this loop except the first,
and using information from one operation to apply another one
doesn't work very well.
The fact that undefined cast to a number is NaN rather than 0
is very unhelpful :(
Also fixed some commas that should be semicolons.
Bug: 52238
Change-Id: I4138c023c955f2866881084506e24bb8b6db5a4d
Now Ctrl+\ (Cmd+\ on Mac) will trigger the 'clear annotations' button
on the current context. Ideally we'd also bond to the 'clear' keyboard
button (ASCII 12) but it does not seem possible to do that yet.
Bug: 51507
Change-Id: I300ec1ffa237e51418ec429be39001f820f053ae
== Renamed methods ==
* enableFloating -> enableFloatable
* disableFloating -> disableFloatable
* setPosition -> float
* resetPosition -> unfloat
== Scroll and resize event ==
Timeline for scroll event reduced from about half a dozen
"Recalculate style" and various forced "Paint" down to 0.
New timeline for scroll is clean (for me: from ~35 to ~59 fps):
* 1 Event (scroll)
* 1 Composite Layer
The composite layer action is the browser changing the viewport
to a different portion of the document drawing. Exactly the one
thing a simple scroll should do.
Timeline for resize event is still pretty crowded and low fps,
but it has improved. Further improvement would likely be around
using requestAnimation and going outside ve.ui.Toolbar.
== Changes ==
* New: ve.ui.Toolbar#initialize.
Similar to what surface has. Users of Toolbar should decide
whether to call enableFloatable, append it to the DOM at some
point and then call initialize() once.
* Don't compute offset() every time.
Eliminated by doing it once in #initialize. These 'top' and
'left' offsets do not change.
* Don't compute outerWidth() and $window.width() every time.
Reduced by doing it once in #initialize to compute the 'right'
offset. Updating it only on resize.
* Don't set 'top' every time.
This is already in the stylesheet. It was never set to anything
else so the abstraction for it in #float has been removed.
This also made it obvious that code for "ve-ui-toolbar-bottom"
was unused and left behind. Tha class was only ever being
removed from something (never added).
The one addClass call for it was in a condition that is always
false ("if top > 0").
* Don't set 'left' every time.
Eliminated by doing it once in #float.
* Don't set 'right' every time.
Reduced by no longer doing it on scroll. Done once in #float,
and on resize after computing the new value for it.
* Remove no-op style operations.
Wrapped methods in if-floatable, if-floated etc. to reduce a
fair amount of easily avoided re-paint overhead.
* Avoid double re-paint in mw.ViewPageTarget.
Though we prevent a lot of redundant re-paints now, whenever
we do repaint we want to do it in 1 repaint instead of 2.
ve.ui.Toolbar emits #toolbarPosition, which tells
mw.ViewPageTarget to update toolbarTracker which would read
the new $bar style properties and copy them over to the
$toolbarTracker. However, this read operation forces the browser
to do an immediate re-paint half-way just for $bar.
Browsers only repaint when style properties are changed and
JS has yielded. The exception to this is JS reading style
properties: in that case the browser is forced to do those
deferred repaints directly and reflect the new values.
We can avoid this double repaint by passing the updated values
as data instead of requiring the receiver to read the DOM (and
thus a keep the deferred repaint). Now toolbarTracker can use
them directly whilst the browser hasn't even repainted $bar yet.
== Clean up ==
* Redundant "border-radius: 0". This would reset something, but
it never does. None of the things it inherits from set a
border-radius. There is one subclass where toolbar is used
with a border-radius (".ve-ui-surfaceWidget .ve-ui-toolbar-bar"
sets a border-radius) which overrides this on purpose, so the
default of 0 is redundant.
* Pattern "if ( .. ) addClass() else removeClass()" changed to:
"toggleClass( , .. )"
Bug: 52014
Change-Id: I9be855148962eee068a77fe83e98eb20bbdcfeec
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
The core changes to postedit in I778b18b that this depends on were
deployed to the cluster as part of 1.22wmf11.
Bug: 39632
Change-Id: Id4a8bc22c09a552ef79670b0d4fc4a70df07ec33
Opera 12 seems to work well enough, but I'm not confident enough to
whitelist it just yet.
Opera 15 is basically Chrome with a different interface, so it should
work perfectly, but it's barely out of beta and untested right now.
Bug: 36000
Change-Id: Ia80a6f53f8c128ef52d0bfde1828fdc132046afb
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
Annotations' attributes might contain DOM elements, which cause infinite
recursion in ve.compare(). Annotation classes can protect against this
by overriding getHashObject() to summarize DOM nodes, but that doesn't
help if that's not respected everywhere.
Instead, compare the hash objects, those are safe. This does not appear
to be a problem in practice, currently, because the nowiki annotation
is experimental, oo.compare() now short-circuits if a === b, and because
of optimizations in openAndCloseAnnotations() which lead to the relevant
compareToForSerialization() code path being taken very rarely.
Bug: 51948
Change-Id: If1bcc3eee4fd14d107db1935d89dcc5516643b53
This only affects debug mode, but things look broken when the
background of every single node is set to transparent (e.g. a
<pre> looks weird with a white instead of grey background).
It also leaves the DOM dirty full of inline styles.
Though setting a grey background isn't guaranteed to be visible
either, and all of these redraws and stuff really slow things
down (we should perhaps only start doing these after the initial
document is painted).. the least we can do is undo it and not
leave it there.
Change-Id: I9abfd46765914828ad8618748be5716a8c6b185c
By using annotation indexes only we can avoid a lot of
ve.getHash calls. This reduces the number of getHash calls
on load of [[:en:Argentina]] from ~60,000 to ~2,000.
Bug: 52013
Change-Id: I0bc9aa8feea5f7e4e90a5fcd829de57cab803c15
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
As that method makes expensive ve.compare calls, we can quickly
avoid most cases by testing AnnotationSet#contains first.
On page load this reduces the number of ve.compare calls on
[[:en:Argentina]] from ~6,000,000 to about ~2,000.
Also reduces ve.compare calls per backspace keystroke from
~300 to 2.
We can optimise this further, but this is a good simple start.
Bug: 52013
Change-Id: Ie3b4517fd13383c48acb64b3c4e82051c34e7484
Previously, we'd clone the data but convert it in the context of
the existing dm.Document, whose nodes had pointers to elements in the
old data array, not to the cloned ones. Because dm.MWReferenceNode
has logic like if ( something === dataElement ), this caused the sanity
check conversion to behave slightly differently compared to the real
conversion that happens on save, and so a references corruption
bug went unnoticed.
Change-Id: I79a42ae21f91cb8eb410ae26ea638036db19e217
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
Server-side, plugins can register themselves by adding to
$wgVisualEditorPluginModules. This is the recommended way for
MW extensions to extend VE. Client-side, plugins can register
themselves through mw.libs.ve.addPlugin(), which takes a string
(RL module name) or a callback.
When VisualEditor loads, we load the registered plugin modules in
parallel with ext.visualEditor.core. Note that they're loaded in
parallel, not after, and so the plugins should explicitly depend
on ext.visualEditor.core if they use or extend classes in VE core.
Once the modules finish loading and user and site scripts have run,
we execute the registered plugin callbacks. These callbacks can
optionally return a promise. We gather these promises and wait for
all of them to be resolved, then initialize the editor.
This allows Gadgets to extend VE by top-loading a small module that
depends on ext.visualEditor.viewPageTarget.init and calls
mw.libs.ve.addPlugin( 'ext.gadget.bottomHalfGadget' ); , the bottom
half being a hidden Gadget that depends on ext.visualEditor.core and
contains the actual code. The addPlugin() call needs to be in a
top-loading module because otherwise there's no guarantee that the
plugin will be registered before the user clicks edit and VE loads.
User and site scripts can extend VE by simply calling addPlugin()
directly, as mw.libs.ve is already present when user scripts run (since
it's top-loaded) and VE waits for 'user' and 'site' to run before
executing plugins.
If user/site scripts need to load additional JS files, they can load
these with $.getScript() and return the corresponding promise:
mw.libs.ve.addPlugin( function() { return $.getScript( 'URL' ); } );
For a diagram of all this, see
https://www.mediawiki.org/wiki/File:VE-plugin-infrastructure.jpg :)
VisualEditor.php:
* Add $wgVisualEditorPluginModules
VisualEditor.hooks.php:
* Expose $wgVisualEditorPluginModules in JS
ve.init.mw.ViewPageTarget.init.js:
* Add mw.libs.ve.addPlugin function that just stores the registered
values in an array and passes them into the mw.Target when it's
being initialized
ve.init.mw.Target.js:
* Add $wgVisualEditorPluginModules to the set of modules to load when
initializing VE
* Add a Deferred (this.modulesReady) to track module loading
* Add addPlugin() and addPlugins() methods that add to either
this.modules or this.pluginCallbacks
* In load(), instead of mw.loader.load()ing this.modules, use using()
to load this.modules plus user and site, and fire onModulesReady()
when they're loaded
* In onModulesReady(), execute the registered callbacks, gather the
returned promises, wait for all of them to be resolved, then resolve
this.modulesReady
* Fire onReady based on this.modulesReady being resolved, rather than
using a second using() call
Bug: 50514
Change-Id: Ib7d87a17eaac6ecdb8b0803b13840d7ee58902df
Introduce method ve.ce.MWBlockImageNode.getCssClass and use it instead of
accessing ve.ce.MWBlockImageNode.static.cssClasses - it gives a better
way of handling special cases.
Bug: 51995
Change-Id: I236b08c8345a10d144f392ec37fd130cf5f7737d
If undoIndex is 0 then we don't need to do anything, or even
emit the history event which is quite expensive as it triggers
various node redraws.
Bug: 52012
Change-Id: I09ca2d6cd0f4cbaf8316819dab0bd6edfc5de62c
Whenever there is more than 2 spaces (except the extra space
on a continued line of an @ tag, or the extra space on a
continued line of a list item) it causes a <pre> context.
Removed both spurious spaces that caused a <pre> and ones that
didn't but looked like it could.
When making an ordered or unordered list, the first item needs
to be on a new line and in block context (e.g. an empty line
before it). Otherwise it is rendered inline as 1. Foo 2. Bar
(such as in #rebuildNodes where both the ordered and unordered
lists were broken).
Change-Id: Id0f154854afbdc8e5a8387da92e6b2cdf0875f69
The fix to the transclusion icon messed up the way inspectors appear in RTL
wikis. The rtl check/correction (inside 'this.embedded') seems to be the only
rtl fix necessary. Something completely different will have to be done to the
transclusion icon.
Change-Id: I2417e125c99de9b0c5fd922a47de43ed9952d6fd
If the first thing on the page is an image, then we'll try to select
it in Firefox, and get a JS error because .data( 'view' ) is undefined.
It turned out that MWBlockImageNode's onSetup() didn't call the parent
implementation, and all the way up in ve.ce.View.onSetup is where
we set .data( 'view' )
Bug: 51986
Change-Id: I0de3692566b0aa02a229054e07767e45fd5d4a49
* Give them a role=button, and a default tabIndex of 0
* Listen for a keypress of 'space' and emit a click event
(you'd have thought role=button would do this, but oh well)
Bug: 50047
Change-Id: I429ad165c95f34d26975daf81db18cc966802cde
We already correctly show the read only error if the user tries
to load VE which the database is locked, but if the database gets
locked after they've loaded VE, we also need to show the error
when they try to save.
Bug: 51636
Change-Id: I7a56f1b4387e7ea594a2a7f939c81626c9eee834
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
For now this approach is bit of a hack and will hopefully
be replaced with an ability to cursor either side of an
annotation.
Bug: 51463
Change-Id: I701e3d26e06a28fed2d4950b1d418eda80a1fac5
EditPage has a lovely getCheckboxes() function which includes the
minor and watch checkboxes as rendered by MW core, as well as any
checkboxes extensions like FlaggedRevs might have added. Output
these in the API, render them, and send their values back.
ApiVisualEditor.php:
* Build a fake EditPage, get its checkboxes, and return them
ApiVisualEditorEdit.php:
* Pass through posted request data to ApiEdit, which passes it
through to EditPage thanks to Idab5b524b0e3 in core
ve.init.mw.ViewPageTarget.js:
* Remove minor and watch checkboxes from the save dialog template
and replace them with a generic checkbox container
* Have getSaveOptions() pull the state of all checkboxes in
** Special-case minor and watch, and pass the rest straight through
** Move normalization from true/false to presence/absence here, from
ve.init.mw.Target.prototype.save(), because here we know which ones
are checkboxes and we don't know that in save() without
special-casing
* Remove getSaveDialogHtml(), we don't need to hide checkboxes based on
rights anymore because in that case the API just won't send them to us.
** Moved logic for checking the watch checkbox down to where the same
logic for the minor checkbox already is
* Unwrap getSaveDialogHtml() in setupSaveDialog()
* Access minor and watch by their new IDs throughout
ve.init.mw.Target.js:
* Get and store checkboxes from the API
* Pass all keys straight through to the API
Bug: 49699
Change-Id: I09d02a42b05146bc9b7080ab38338ae869bf15e3
Previously it was faded out to 60%. contentSub contains FlaggedRevs
stuff we don't want around in the editor, and contains the revision
navigation when editing an oldid, which James decided also shouldn't
be visible when editing.
Change-Id: Icdef98f756ce92a32d276d6eeb22c9de04640d8b
Added GUI-level and Page-level "getDir()" methods to get the direction
of the GUI and Page respectively in the ve.ui.Surface and ve.ce.Surface
respectively.
The correction to the direction-test condition in ve.ui.Context reflects
the new method of getting these directions, and fixes the problem with
the transclusion icon. The icon position depends on the wiki/page-level
directionality, regardless of the GUI-level direction.
Bug: 51819
Change-Id: I36cef115017542c461e6d757f1c8bfda92074607
This preference will allow users to opt-out of VisualEditor during the beta
if they so choose. We do not re-use the alpha enablement flag because (a) this
would lead to a confusing preference description, and (b) because opting in
and then out of the alpha is not the same user choice as opting out of the
beta period.
Change-Id: I0f0a1b5eb21703ad422d007cab65c75ac1aa6fd8
This removes the initial alignment (either left or right) from new
inserted images, letting the wiki decide the default positioning.
Also, it makes sure that VisualEditor positions the image properly
(according to wiki defaults tright/tleft for ltr/rtl) when editing.
Bug: 51851
Change-Id: I25b966cf6f2736437509ea7e70bfda1bdbc79021
Flipped the generated positions of the MWCategoryPopupWidget and the
suggestion popup in the TextInputMenuWidget. The RTL position within
TextInputMenuWidget is only adjusted if the popup appears inside another
frame. This fix also corrects the suggestion popup positions in general
when inside another frame.
Bug: 51490
Bug: 51828
Change-Id: I83436d50a4a0596fdae9526c3fc2804cf880a530
Load the module always and have the conditionals on the
client-side so that we can change these without running into
problems with the new conditions not being rolled-out quickly
for anonymous users because the load queue is in the HTML
and cached for 30+ days.
This also allows us to fix above problem retroactively in wmf
production by just adding a mw.loader.load for this module
in something like MediaWiki:Common.js or something else that is
already in the cached load queue (temporarily, until the cache
has rolled over).
Removed unreachable code for loading ext.visualEditor.splitTest.
Change-Id: I21114960a88d224747447f2dc83d17d160f5f066
Opera triggers 'blur' on the document node when clicking on any <a>
link and never trigger 'focus' until after the user blurs the document
node *again* (by clicking outside of it or pressing 'Esc').
This causes the change polling to stop (SurfaceObserver#stop is called
without a subsequent call to SurfaceObserver#start).
To avoid this let's bind a delegated 'focus' event on all <a> links
inside the document and refocus it whenever that happens.
Bug: 47793
Change-Id: I7962f59bd02e075f91e42e6514b390c0d0feb3ab
Due to CSS specificity rules the styles defined for
.ve-ui-panelLayout-scrollable and .ve-ui-panelLayout-padded in
ve.ui.Layout.css were being overriden by more general rules for
.ve-ui-pagedDialog-pagesPanel .ve-ui-panelLayout in ve.ui.Dialog.css.
Bug: 51739
Change-Id: If2d5ec3168a874eb4f856450583d6c89967513df
* changes:
Add a node class for mw:Nowiki
Move getHashObject() from dm.Node up into dm.Model
Allow annotations to render nothing
Pass child DOM elements to annotations' toDomElements()
Process annotations bottom-up rather than top-down in data->DOM
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
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
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
This isn't as simple as just dropping applyToAppendedContent = false
on LinkAnnotation, because browsers differ in their continuation
behavior. Firefox continues links, but Chrome doesn't.
To work around this, add a property indicating that the annotation
needs its continuation behavior to be forced.
Rename areAnnotationsCorrect() to needsPawn() accordingly.
Bug: 49931
Change-Id: Id6424af89c92bba2be87736e8a937e0f2067c007
Objective:
* Make the inspector close and context menu reset when the selection is
changed while an inspector is open
Changes:
ve.ui.PopupWidget.js
* Add isVisible method
ve.ui.Context.js
* Check if popup is visible when the selection changes and close the
inspector and reset the context if it is
ve.ui.AnnotationInspector.js
* Don't update the selection when closing if the selection has changed
since opening
Bug: 50895
Change-Id: Ie7f0b7ac76b0460b39ec002705172376e4e602dc
Objective:
* Allow fieldsets to not have labels
* Remove label from reference edit dialog field set
Changes:
ve.ui.Layout.css
* Only apply negative top margin if fieldset label is being used
ve.ui.FieldsetLayout.js
* Only add label element to DOM if icon or label are used
ve.ui.MWReferenceEditDialog.js
* Remove label from reference edit dialog's first fieldset
*.php
* Remove unused message
Change-Id: I4a36e819ec6ef73aad80d3fb2f06000cb35ec109
Objectives:
* Reduce the number of clicks and mouse maneuvers required to insert
media, references or template parameters
* Make use of highlighting with mouse movement or arrow key presses,
similar to menus, to suggest action when clicked
* Improve the way media search results look and feel
Changes:
ve.ui.SelectWidget.js
* Add mouseleave handler to un-highlight when the mouse exits the widget
* Document highlight events (already being emitted)
ve.ui.SearchWidget.js
* Propagate both select and highlight events from results widget
* Make arrow keys change highlight instead of selection
* Get rid of enter event, make enter key select highlighted item instead
* Provide direct access to results widget through getResults method
ve.ui.MenuWidget.js
* Use the selected item as a starting point if nothing is currently
highlighted when adjusting the highlight position
ve.ui.Dialog.js
* Add footless option to hide the foot element and make the body extend
all the way down to the bottom
* Remove applyButton, which only some dialogs need, and should be creating
themselves, along with other buttons as needed
ve.ui.Widget.css
* Change highlight and selected colors of option widgets to match other
selection colors used elsewhere
* Leave selected and highlighted widget looking selected
ve.ui.Frame.css
* Add background color to combat any color that might have been applied to
the frame body in the imported CSS from the parent frame
ve.ui.Dialog.css
* Add rules for footless mode
ve.ui.MWReferenceResultWidget.js,
ve.ui.MWParameterResultWidget.js,
ve.ui.MWMediaResultWidget.js
* Allow highlighting
ve.ui.MWParamterSearchWidget.js
* Switch from selecting the first item when filtering to highlighting
ve-mw/ve.ui.Widget.js
* Adjust media result widget styling to better match other elements
ve.ui.MWTransclusionDialog.js,
ve.ui.MWReferenceListDialog.js,
ve.ui.MWReferenceEditDialog.js,
ve.ui.MWMetaDialog.js
ve.ui.MWMediaEditDialog.js
* Add apply button, as per it being removed from parent class
ve.ui.MWTransclusionDialog.js,
ve.ui.MWReferenceInsertDialog.js,
ve.ui.MWMediaInsertDialog.js
* Insert parameter/reference/media on select, instead of clicking an
insert button
* Use 'insert' instead of 'apply' as argument for close method
Bug: 50774
Bug: 51143
Change-Id: Ia18e79f1f8df2540f465468edb01f5ce989bf843
Otherwise links don't get removed as an empty link is not
comparable to a real link with an href.
Bug: 50461
Change-Id: Id8b421bd44cd5c427d0e5cd738c380bc2b1ea719
Previously we only looked at error info/code from the root of
the API response, not the ones from the root of the response
that action=visualeditoredit forwards from action=edit.
This changes the message for e.g. AbuseFilter from:
> Error: Invalid error code
to:
> Error: Hit AbuseFilter: [name of triggered filter]
Also changed default error for other reasons (e.g. hooks of other
extensions that we don't yet have specific support for) to "Unknown error"
instead of "Invalid error code".
Bug: 50472
Change-Id: I3b32eddafd8fff83f323606f9922ac60b5d3b58e
* Rephrased visualeditor-savedialog-error-badtoken to emphasise
that it is the old session that become invalid, not the one
the user started browsing with since in a different window.
* If the session changed, the user will be asked whether they
agree to save with this new session instead.
* We explictly update mw.config so that future save attempts
in the same window compare against the correct environment.
Without this there are two problems when saving and then
making a second edit in the same window and saving that:
- It will bring up the same question again (user A -> user B),
which is annoying.
- If the user logged back in again (new session, but for
user A again) it would silently try with that new token
without asking, thus saving as user A when the user still
thinks it switched to user B. It switching back automatically
is not obvious since we asked them from A->B, so we should
also ask the other way around.
This can be reproduced by opending ve-edit logged-in, then
logging out in a new window, save, confirm anon, save,
open edit again, log back in in a new window, save open edit
in the old window, confirm new logged-in, save.
Bug: 50424
Change-Id: Id055eca1886f85aeaf615f645de29898afc0373c
Per bug 51330, cs (Czech), he (Hebrew) and pl (Polish) should use the same icons
as English (B for bold, I for italics), rather than the generic As; da (Danish),
no (Norwegian Bokmål), nn (Norwegian Nynorsk) and sv (Swedish) should use those
that German (F for bold, K for italics).
Bug: 51330
Change-Id: I1d5937bed658d45ba6a18d8eb77e9e20d55a16cc
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
Some methods apply to all types of LinearData. Also moved to
static so they can be used by the converter on raw data.
Change-Id: I79066d6d3ccde48aea7c0848d56ef86bc70f6656
Without making the code much more complex (and possibly create
performance issues) the warning will fire on pages which already
contain escaped wikitext (when that text is edited). I think this
should be a small enough minority that it won't be an major annoyance.
Bug: 49820
Change-Id: I0f67ec04b890f4add9247be6126bdc086b6ae72f
Adjacent annotations should not be merged if they both
originate from Parsoid. This is a hack because this logic
should be in Parsoid, not VE.
Bug: 49873
Change-Id: If1e23e3039178300d72b1c0c585931417bb603b5
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
Problem:
Adding or moving templates or content resulted in the incorrect item
being selected.
Diagnosis:
Although recently we solved a few issues by making addPart async, it
caused some other issues where callers of addPart were assuming
otherwise
Solution:
Return a promise from addPart which is resolved after the part is
actually added and setup callers to use the promise when needed
Changes:
ve.ui.MWTransclusionDialog.js
* Use promises to auto-select new or moved parts
ve.dm.MWTranclusionModel.js
* Make addPart return a promise
* Resolve promise when queue is processed
* Automatically remove existing items before adding them in different
locations at the time of processing the queue we don't yield between
removing and adding
Change-Id: Ie43c5b89ca4ed34d5f797714e19c9a7e1824cdec
Problem:
Parsoid has a property called "i" which we don't use, but they need for
round-tripping purposes. Since we were generating a structure from
Parsoid data and then generating data from the structure without
preserving properties we didn't use, it was getting lost.
Solution:
Abstract creating a template from data vs. creating it from name. Make
only templates have an origin argument in their constructors, so and
set it within a set of static constructors that create a template for
either data or a template name. Store the original data in the former
case, and use it as a base when serializing.
Changes:
ve.ui.MWTranslcusionDialog.js
* Remove no-longer-needed mw global declaration
* Move most of the addTemplate function to a static constructor in the
template model class
ve.dm.MWTransclusionPartModel.js,
ve.dm.MWTransclusionContentModel.js,
ve.dm.MWTemplatePlaceholder
* Remove unused origin argument/property/getter
* Add serialize method (if needed)
ve.dm.MWTranclusionModel.js
* Move template/parameter generation from data into static constructor
of template model
* Move serialization to part classes
ve.dm.MWTemplateModel.js
* Add mw global declaration
* Stop passing origin to parent constructor, store it locally instead
* Add original data property/setter for preserving unused properties
when round tripping
* Add static constructors for generating a template from data or by name
* Add serialize method
Bug: 51150
Change-Id: Ide596a0ca0ae8f93ffce6e79b7234a1db7e0586c
Previously all it did was surface api response error.info,
which surfaced underneath the edit summary form as mere:
"Error: Invalid token".
Bug: 50424
Change-Id: I60169b42701ae3b88e54626c4ff7050549e6ef55
This allows us to make the token no longer a requirement
for non-save actions while still using the built-in system
for token verification.
Update documentation for "oldid" since it is not required even
outside (paction=save). In fact, if we require it VE loading
fails because it doesn't pass oldid unless it has to when
restoring a specific version.
Bug: 50424
Change-Id: I7b1b50a43648b1cc40a984340846efdb0ba2ecc9
Objectives:
* Automatically add required parameters to templates that users create
using the GUI, without touching existing templates loaded from data
* Cleanup some confusing terminology and APIs
Changes:
ve.ui.MWParameterSearchWidget.js
* Remove special logic for skipping aliases, which are no longer included
in the list of names given by getParameterNames
ve.ui.MWTransclusionDialog.js
* Add origin arguments to constructors of transclusion parts
* Re-use onAddParameter method during initial construction of parameter
pages
* Add required template parameters for user created template parts
ve.dm.MWTransclusionPartModel.js
* Add origin argument/property/getter for tracking where a part came from
ve.dm.MWTransclusionContentModel.js,
ve.dm.MWTransclusionPlaceholderModel.js,
ve.dm.MWTemplateModel.js
* Add origin argument pass through
ve.dm.MWTranclusionModel.js
* Add origin arguments to constructors of transclusion parts
ve.dm.MWTemplateSpecModel.js
* Rename origin to name - was a bad name to start with and will be even
more confusing with the new part origin property
* Add isParameterAlias method
* Make getParameterNames only return primary names, excluding aliases
ve.dm.MWTemplateModel.js
* Update use of parameter origin, now called name
Bug: 50747
Change-Id: Ib444f0f5a8168cd59ea52a6000ba5e42ccdc2a24
Objective:
* Make outline widgets and fieldset layouts take up a little less space
Bonus:
* Fix option icons always showing up on the first item because the option
wasn't position relative
Changes:
ve.ui.Widget.css
* Add position: relative to option widgets
* Cleanup unused background properties for outline items
* Reduce padding for outline items
* Move icons to match padding changes
ve.ui.Layout.css
* Reduce margins for fieldset layouts, including using a negative top
margin to compensate for the overly tall legend
Change-Id: Ida6147b8171dcb4152ca9be0e099a5f9b81ac1c0
Also in this commit is a fix to the regex for brackets in general
as previously it was grouping multiple pairs together which was
making the stack count incorrect.
Bug: 50801
Change-Id: I2cd825eaa7242e37a6317286cb8f9a4a78e693e2
Some of the ones that were moved to ve-mw disappeared from index.php
(the MW-only test runner) and/or VisualEditor.hooks.php (the runner for
Special:JavaScriptTest that's also used by Jenkins).
Add the missing tests, and rename the SurfaceFragment test. We can't
add the ViewPageTarget test to the index.php file in ve-mw because
it only works when running inside an actual MediaWiki instance.
Change-Id: Iec34f2029f5f9c34855b4d79ef70db5751461a96
This is harmful because we don't know whether <span> is acceptable
in context. They're not allowed in <tbody> for instance, and so if
we replace a <tr> with a <span> that breaks things.
Instead, use the nodeName of the first original DOM element.
Change-Id: I95ea9f13985767123f692706c6cc71fefd74d517
Apparently it's possible for a stylesheet's .cssRules to be accessible,
but for the individual items' .cssText not to be, in which case Firefox
throws a nice security exception that kills the entire editor.
Wrap all inspector of cssRules in a try-catch, and fall back to cloning
the ownerNode if anything weird happens.
Change-Id: I0187ad308e395e92aea587c00fd8d8eb0280822e
Objectives:
* Trim leading or trailing whitespace that parsoid may have left on
parameter names
* Preserve the original name for round-tripping cleanliness
* Ignore leading or trailing whitespace when entering new parameter names
in the parameter search widget
* Consider aliases when listing suggested parameters
Changes:
ve.ui.MWParameterSearchWidget.js
* Use hasParameter method instead of using indexOf - uses map lookup
internally, which is much faster, and also take aliases into account
* Trim query input value to prevent leading or trailing whitespace from
being considered when filtering known or creating unknown parameters
* Take aliases into account when showing filtered results
ve.dm.MWTransclusionModel.js
* Use original name when round-tripping
ve.dm.MWTemplateParameterModel.js
* Store original name for round tripping, and trim the original name for
other uses
* Add getOriginalName method
ve.dm.MWTemplateModel.js
* Add hasParameter method, which currently just does a map lookup, but can
do other processing in the future
ve.dm.MWTemplateSpecModel.js
* Add isParameterKnown method
Bug: 50715
Bug: 50717
Change-Id: I36a5e93ca8938ac3401a6e274647597704700468
Listen to keyup to properly capture and respond to up and down arrows.
Rewrite calculation for scroll to better follow toolbar obscured cursor.
Bug: 48787
Change-Id: Ia46fb15ec9a8c07b3945b53a6545897ca23e59fa
This is the infrastructure for the Language Inspector prototype, defining
the dm and ce pieces of the <span lang='xx' dir='yy'> annotations. It also
sets up a visual indicator for language blocks (with informational tooltip
for the user while editing. The UI is built on top of this.
Bug: 47759
Change-Id: I239eef5124e29369ea9c5d8c0f49b2f6a61bc053
Since the menu only shows while it's input is focused, input must be focused
prior to suggestions being popuplated. Fixes race condition where
look up request is near instantaneous.
Change-Id: Icf645d051415ac3ee9e15bc85f22f29dc9b64666
The presence check used to be against the VE global, but we
recently made that impossible without providing an alternative.
Though by accident, mw.libs.ve has become the new way to check
for presence.
Change-Id: If85695525777a71dde467675052d2ede4e52c9b7
* Hooks for activation, deactivation, save dialog state change,
and tab setup.
* Class for save button (needed to point to it in a clean way).
Also done for cancel button to be consistent, though GuidedTour
doesn't currently use this.
Change-Id: I4a0e0631d513fb09c3408f2f36a0de0bd51e1a37
Objective:
* Cut off really long parameter names with ellipsis
Changes:
ve.ui.Widget.css
* Use ellipsis when option labels get too long
ve-mw/ve.ui.Widget.css
* Limit the size of a parameter result widget label - this is a hack, but
since there are strange bugs with using ellipsis together with % based
width, it's the best we can do for now
Bug: 50800
Change-Id: Idbfa336d2bba376b0d078fdd0ece65926d610d81
Objectives:
* Make context menu toolbar consistently sized and aligned, especially
in monobook
Changes:
ve.ui.Toolbar.css
* Remove vertical line between groups, just use whitespace
* Switch from padding to margins to avoid size calculation issues
ve.ui.Tool.css
* Remove tiny margin on button tools, tightening them up a bit
* Replace 50% 50% with center center
ve.ui.Context.css
* Switch from padding to margins to avoid size calculation issues
* Use different margins depending on text direction
* Reverse the 0.8em rule used in the dialog - this is a hack, it should
be cleanup up later with a better strategy for normalizing the size
of text within VE elements
Change-Id: If65f12382625efa33777e284bd23a94dc509436a
Reference counting indicates these styles are not in use, so they can now be safely garbage collected.
Change-Id: I432f73490eeb00ff414f150fcf26c718607bac95
Follows-up Ic0c6d190c9b78 which introduced a full linmod copy in a
scope that is also accessible by other closures (namely the
callbacks to jQuery.Deferred #done and #always, and setTimeout).
Though in theory engines may be able to garbage collect it,
I doubt it. Though browsers probably destruct the setTimeout
callback I know at least the closures pass to jQuery.Deferred
are not released by jQuery, so an engine would have to
understand these other functions well enough to know it doesn't
access the `data` variable.
Let's release explicitly to be safe.
Change-Id: I11000edcad4690dcce53b6e9d1a45bf2ab82fbcb
Objective:
* Prevent input while the inspector is animating open
Changes:
ve.ui.LinkInspector.js
* Disable and then re-enable the surface while the inspector is opening
ve.ce.DocumentNode.js
* Remove opacity changes on disable/enable
ve.init.mw.ViewPageTarget.js
* Change the opacity of the document when save dialog is open
Bug: 51075
Change-Id: Ic7910a666b33b41b57b035a15cf1f8c9264e7111
Objectives:
* Make option widget icons correctly placed in RTL
* Make embedded context toolbar correctly placed in RTL
Approach:
Use separate elements for icons within option widgets which have more
flexibility when rendering in either LTR or RTL when compared to CSS
background position. The simpler approach, using CSS background
position offsets, isn't cross-browser compatible at this time.
Changes:
ve.ui.OutlineItemWidget.js
* Remove custom icon implementation, using parent class implementation
instead
ve.ui.OptionWidget.js
* Add icon option, which adds an icon element only if an icon was
specified
ve.ui.MenuItemWidget.js, ve-mw/ve.ui.MWParameterResultWidget.js
* Add override for icon config option
* Document icon config as private
ve.ui.Context.js
* Add detection and special handling for positioning embedded context
toolbar when rendering in RTL
ve.ui.Widget.css
* Add styles for option widget's new icon option
* Add styles to make indentation still work for outline item widgets
* Adjust styles for menu item widget as per changes in option widget
ve-mw/ve.ui.Widget.css
* Adjust styles for parameter result widget as per changes in option
widget
Change-Id: Ibfa4b613e0fd7902f8a2c78b5717de402c5f82b8
We previously manually loaded CSS into these frames, which is flawed
because it completely bypasses ResourceLoader (so CSSJanus didn't flip
them, necessitating a bunch of hacks for RTL), and doesn't pull in
MediaWiki styles (so templates inside references don't render correctly).
Instead, this commit copies all styles from the main document into each
frame's document, inlining what it can.
Loading all styles in dialogs and inspectors caused some problems,
initially. We didn't namespace our styles for dialogs vs. inspectors
at all; the only reason inspector styles weren't being applied to dialogs
and vice versa was because we controlled which files were being loaded
in which context. This commit namespaces the inspector and dialog styles
where needed so they don't conflict and try to override each other.
Tested in Vector and Monobook, but not in Apex and not in RTL.
ve.init.mw.ViewPageTarget*.css:
* Namespace styles that are only intended for the main document
* Undo Monobook's font-size: x-small; in frames
*Dialog.js:
* Remove addLocalStylesheet() calls, we don't need those any more
** ve.ui.MWDialog seems to be unneeded now, we may want to remove it
*.css:
* Remove @noflip-ped RTL rules where they were just flipped versions of
their LTR counterparts
ve.ui.Dialog.css, ve.ui.Inspector.css:
* Namespace styles with .ve-ui-dialog-content / .ve-ui-inspector-content
ve.ui.Frame.css:
* Move the margin:0 and padding:0 here (were in the frame <body>'s style
attribute) and add background:none to prevent frames from getting
the skin's background (grey in Vector, a book in Monobook)
ve.ui.Dialog.js, ve.ui.Inspector.js:
* Add ve-ui-dialog-content / ve-ui-inspector-content class to the
frame's content <div> so we can restrict styles to only apply in
dialogs / inspectors
ve.ui.Frame.js:
* Replace infrastructure for @import-ing stylesheets with transplantation
* Remove code polling to see when the stylesheets were loaded
** We can't do this in the new approach AFAIK, since all styles in the
frame are either inlined or inaccessible due to the same-origin policy
** We also shouldn't need it because the browser should have cached the
styles when it loaded the main document
* Apply ve-ui-frame-body class to the frame's <body> so we can style it
** Move inline padding:0;margin:0; into ve.ui.Frame.css
** Move the ve-ltr/ve-rtl class up to the <body>
ve.ui.Window.js:
* Remove infrastructure registering stylesheet URLs to load
Change-Id: I4a37115301811ad860f4578344a04873ea8c2b69
Resolving this bug reveals a completely unrelated bug where hitting
enter while making a link prior to the input being focused, the
selected text gets replaced with a new line.
Bug: 51075
Bug: 49941
Change-Id: I61a90eeaa40b8b66886c17152544c46fa8ca396a
Whoops, merged too soon. The dropdown part of it doesn't
actually work right.
This reverts commit 3c51ebad93.
Change-Id: Ieafbf18ca8a43b07e33a787772abbc77aef63e4c
Conversion is apparently pretty slow on large articles, so put it inside
the setTimeout(). We still need to copy the data array synchronously
though.
Change-Id: Ic0c6d190c9b782f8c643d00d335f0e004d860bcf
* ve.ui.MenuWidget.js
MenuWidget no longer creates an embeded input element by default.
In the case of no configured input element, we bind the keydown
handler to window with addEventListner while using the useCapture
flag. This nicely prevents elements lower in the dom from triggering
( document node ) Supported in IE9 and above and all modern browsers.
* ve.ui.ListAction.js
Since MenuWidget is no longer stealing focus from the surface,
we no longer need to restore focus after a list item conversion.
This is the end goal, as browsers like Chrome like to scroll to
the top of elements that gain focus.
Bug: 50792
Change-Id: I5b6969bca1a58b040708f8ac9d3dc8b07ddf9e6b
Apparently they can't get their basic ECMAScript right. In 2013.
It doesn't come up that often, because you don't splice an array with
more than 256 elements every day. Only implemented in ve.batchSplice
for now, as that function does handle thousands of elements routinely.
Other callers of .splice() can simply use that instead.
Bug: 50385
Change-Id: I281a61d55c6f7df5f28627a1df80f2a001110607
Firefox 13 and 14 were the cause of links magically turning into [[./Foo]].
Once the immediate rush of deployment is over, we'll want to investigate as
to why and hopefully find a way to unblacklist FF.
Bug: 50720
Change-Id: I7a9dddb693091fa1e44b4325e77b9e4f55e5c193
The handler for the Edit tab already is in this conditional,
for edit section we were making the assumption that they only
ever appear on a view page, but that's wrong. They're also shown
on a diff against the latest revision of the page.
Bug: 50925
Change-Id: I802e548cbcdc03cfca66129466668854604bc3e7
* Only pass the oldid to the API from #load if we restoring from
oldid in the url. Otherwise load the latest version.
* Setting 'restoring' from mw.Target instead of mw.ViewPageTarget
so that we don't rely on mw.ViewPageTarget in mw.Target#load.
* Fix the API to not require 'oldid' to be passed.
* Fix the API to actually return the 'newrevid' property. It
was doing a no-op on a $result that is never used due to the
same variable being overwritten with the result of parseWikitext.
* Moved updating of wgCurRevisionId to mw.ViewPageTarget as it
belongs there (possible future inline editors probably act
on a different page than the main one). Also made it only
update if it isn't undefined, so that a null edit doesn't
result in wgCurRevisionId being unset.
Bug: 49943
Bug: 50441
Change-Id: I221e5038f95eadf6d87013e80f12394f0376a293
Show an inspector with inputwidget when the user clicks a math
node. The data of the math equation is shown in the
edit box, it can re-render the math tag image when
the inspector is closed, and save the change when
saving the page.
TODO:
* Change the icon from link to math
* Translate title by translatewiki in i18n
* Other further UI improvements
Change-Id: I4d7533af25186cc39cc4bc6a4326d222ffd6db19
This patch creates two files handling math node matching,
which are:
ve.dm.MWMathNode.js - a basic version of toDataElement
and toDomElement functions work
ve.ce.MWMathNode.js - math formulas in VisualEditor are
clickable and render as img tags
Change-Id: Ib909c5fb02e385c88050f42d02d207ab6a97d0dd
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
