Add teardown call to surface destruction in mw target, and
teardown listener to resizeable node.
Bug: 48530
Change-Id: I807a0f32d3d1eb490456d887f7bf867bdb896df4
MW meta is close to being moved out of experimental, but language
editing is not in line for the beta release.
Bug: 48561
Change-Id: Ie87a3c7dde2f29c3898c08d4cade5c0ba2f937dd
Also remove the exception thrown when we try to add an non-existent
toolbar button, as it may just be experimental and not loaded.
Change-Id: I0a60421f45d7a3941c510defc60d1fbf9469e784
Right now the internal list is very much HTML-based, so it's not
populated at all when creating a document from data. So hack this in by
specifying what should be in the internal list as a property of the
example document's data array.
Change-Id: I51c7b7b4dcd9fd3333777c1287b7ba544887aa32
Prologue:
Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't
see you there! In a world where iframes are outlaws, and symbols like
document and window are global, there were more than a few assumptions
about which document or window was being used. But fear not - for this
commit (probably) tracks them all down, leaving a trail of
iframe-compatible awesomeness in its wake. With the great ve.ui.Surface
now able to be used inside of iframes, let the reference editing
commence. But there, lurking in the darkness is a DM issue so fierce it
may take Roan and/or Ed up to 3 whole hours to sort it out.
Note to Roan and/or Ed:
Editing references seems to work fine, but when saving the page there
are "no changes" which is a reasonable indication to the contrary.
Objectives:
* Make it possible to have multiple surfaces be instantiated, get along
nicely, and be embedded inside of iframes if needed.
* Make reference content editable within a dialog
Approach:
* Move what's left of ve.Editor to ve.ui.Surface and essentially
obliterate all use of it
* Make even more stuff inherit from ve.Element (long live this.$$)
* Use the correct document or window anywhere it was being assumed to be
the top level one
* Resolve stacking order issues by removing the excessive use of z-index
and introducing global and local overlay elements for each editor
* Add a surface to the reference dialog, load up the reference contents
and save them back on apply
* Actually destroy what we create in ce and ui surfaces
* Add recursive frame offset calculation method to ve.Element
* Moved ve.ce.Surface's getSelectionRect method to the prototype
Bonus:
* Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it
was separate in the first place, but I'm likely the one to blame)
* Fix blatant lies in documentation
* Whitespace cleanup here and there
* Get rid of ve.ui.Window overlays - not used or needed
Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
The spec you link to appears to not correlate to the real world.
Firefox has a value of 0x2E (46 in decimal) store for this, and
both FF & Chrome report that value in my tests.
Change-Id: I4b0d4d27448587ca7381c640d6d3949402305656
* VisualEditor.hooks.php
** export URL to magnify clip as a configuration variable so thumbnail image can render correctly
* ve.ce.Surface.css
** add CSS styling to make image captions look the same way in edit mode as they look in the view mode
* ve.ce.ParagraphNode.js
** add CSS class ve-ce-generated-wrapper if it is a generated wrapper
* ve.ce.MWImageCaptionNode.js
** make image caption rendering match the view mode
Change-Id: I0cd1b25e8f8355e0500aabc90e7c4cdf591545f3
On wikis where certain "topicons" exist the toolbar showed a
weird blank space pushing the entire toolbar down and
ve-ui-toolbar-actions to the left.
Bug: 48734
Change-Id: Ic5f73ac1eb8c41b891dd1c67b71795cb6c456141
Previous check wouldn't make sense, cause the last offset in the data
could be that one that makes data balanced (and j is increased always
after iteration).
Change-Id: Ie9498d0ac9e3417d09b8b3043bf3281e7dfbf9db
Relying on any native implementation of window.KeyEvent is
unreliable. The two specs listed in the comments for this method
are not the same and Firefox now has DOM_VK_ENTER and
DOM_VK_RETURN which are equivalent to 13 and 14 respectively.
The key on the right side of my home row triggers 14 using
native window.KeyEvent in Firefox, where Chrome uses our
defined constants and returns 13. This fix ensures the same
values for all browsers.
Change-Id: I12b2f5d674bdf13526577cb81d0505b608f2846c
Don't suggest a "new page" (redlink) for values that are
strictly different but the same as a suggestion according
to mw.Title (e.g. input "foo" with an existing "Foo" page
should not suggest a redlink to inexistant page "foo").
Bug: 48476
Change-Id: I66f5fc56554984af58d6223dc6cd76b3ab9940bd
Fetch
* Added basic name expansion logic since bug 48663 is not yet
resolved in Parsoid.
* Fetch info from template data API.
Clean up (follows-up 97157a1c, de203cb8, 718db58)
* Remove redundant initialize method.
* Pass the entire target object to #getTemplateData
because `target.wt` is *not* the template name.
* Reorganise #createPage to be more logical and rename
to #createParamPage.
* Add todo comments for things currently missing.
* Implement error handling of promise to prevent UI from
going stale if the promise is not resolved.
* Fix documentation in ve.ui.MWCategoryInputWidget.
Change-Id: Ie0114a81eead86d7a3b3e3a7a5b10d25c457b524
If the commit message is empty we show a warning, and if the warning
is already visible we allow the user to proceed.
Bug: 47752
Change-Id: Idba707abaea8b08a94f7fa4d5bc5b1e35261a572
