Commit graph

12 commits

Author SHA1 Message Date
David Chan 1987d3aa2b Don't emit Surface changes back to the Surface
modules/ve/ce/ve.ce.SurfaceObserver.js
* add emitChangeEvents argument to poll (and start and stop)

modules/ve/ce/ve.ce.Surface.js
* Pass emitChangeEvents=false to calls to start/stop in certain places
* Pass async=false in the onDocumentKeyDown call to stop
* Explicitly pass emitChangeEvents=true elsewhere, to preserve prior behaviour

modules/ve/ui/ve.ui.Surface.js
* Explicitly pass emitChangeEvents=true to poll

modules/ve/test/ve.test.js
* Escape non-BMP unicode text literal (to prevent potential editor problems)

Change-Id: Ia96efad0c808b9a02e508bbfda65fdf4f5cedeff
2013-08-19 14:20:08 +00:00
Timo Tijhof 8f05cdbf70 doc: Add placeholders for unindexed methods
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
2013-07-31 23:00:30 +00:00
Timo Tijhof c9cd496fdc ve.ui.Toolbar: Emit position event on toolbar instead of surface
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
2013-07-31 21:59:30 +00:00
Timo Tijhof 301eaa4088 mw.ViewPageTarget: Emit position event after toolbar is animated
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
2013-07-31 22:15:33 +02:00
Timo Tijhof 14343c7bf7 ve.ui.Toolbar: Refactor floating logic for performance
== 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
2013-07-30 01:47:54 +02:00
Moriel Schottlender 5bb15c4332 Quickfix for Transclusion icon in RTL wikis
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
2013-07-23 20:31:08 -07:00
Rob Moen c472b2fe4a Make local overlays local to surface and remove insane z-indexes
ve.ui.Surface.js
* Make local overlay a child of ve-ui-surface and a sibling to
  ve-ce-surface elements.
** This keeps local overlays relative to their surface and eliminates the
   need for insane z-indexes.

ve.ui.PopupWidget.js
* PopupWidget boundaries are now relative to ve-ce-surface and no longer
  protrude out

ve.ce.Node.css, ve.ui.Window.css
* Removal or replacement of insane z-indexes.

ve.ce.FocusableNode.js, ve.ce.ProtectedNode.js, ve.ce.ResizableNode.js,
ve.ui.Context.js
* Translate offsets from local overlay

ve.init.mw.ViewPageTarget-monobook.css,
ve.init.mw.ViewPageTarget-vector.css
* Skin specific z-indexes for global overlay

ve.init.mw.ViewPageTarget.js
* Applied direction specific mw class to ce.Surface vs ui.Surface to
  prevent mw content styles from being applied to ui elements.

ve.ui.Dialog.css
* Adjustments to surface inside of dialog so that relative offsets for
  local overlays can be properly calculated.

ve.ui.Surface.css
* Explicitly force .ve-ui-surface to be relative so that it's children can
  be relatively positioned.

ve.ui.Widget.css
* Removal of unnecessary font-size properties now that local overlay is
  sibling of surface.

ve.js
* Added get relative position helper method to translate position offsets
  from target parent

Bug: 50241
Change-Id: Ibadce404a2286bc5dcec48f0d9da89004dbbd867
2013-07-02 19:35:43 +00:00
Roan Kattouw c41f96cf6b Some basic async code in the initialization
Break setUpSurface into a bunch of parts that setTimeout() each other.
This breaks the initialization of the editor as a whole up into the
following phases:
0) Receive AJAX response, parse HTML
1) Build linear model data
2) Build DM tree
3) Build CE tree, CE DOM, create surface
4) Initialize surface, some UI initialization
5) Launch sanity check, remaining setup, unlock editor

This is a bit hacky right now, we'll probably want to refactor later.

ve.dm.InternalList.js:
* Allow construction without a dm.Document

ve.ui.Surface.js:
* Allow construction based on a dm.Document

Change-Id: Ibf48a7e85cd7376c8f6205ed165ff57e71e34c35
2013-07-01 13:02:10 -07:00
Christian Williams 68f635b482 Local Overlay Stacks
After a spirited discussion, localOverlay is getting some children.

* localOverlayBlockers - UI elements that are meant to prevent
interaction with the element. This includes Phantoms and
Highlights.

*localOverlayControls - UI elements that are meant to be
interacted with in order to modify the element. This includes
resize handles and drag marker.

*localOverlayMenus - UI elements that should always position
above all other controls. This includes the context menu.

Bug: 50159
Change-Id: Ic69c2ad275389a31c9fbaf47f3665dcdbb7ac2af
2013-06-28 00:30:54 +00:00
Timo Tijhof 85c4ebf373 mw.ViewPageTarget: Move save dialog out of toolbar tree
Bug: 49275
Bug: 49361
Change-Id: I2fbc4c8af943f1b096b8912191924961405d5c47
2013-06-20 14:16:50 -07:00
Trevor Parscal 2e76271b4e The Great ve.ui.Surface refactor of 2013
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
2013-05-24 14:01:02 +02:00
Trevor Parscal a56e795f58 ve.Editor
Objectives:

* Split ve.Surface into ve.Editor and ve.ui.Surface
* Move actions, triggers and commands to ve.ui
* Move toolbar wrapping, floating, shadow and actions functionality to configurable options of ve.ui.Toolbar
* Make ve.ce.Surface and ve.ui.Surface inherit ve.Element and use this.$$ for iframe friendliness
* Make the toolbar separately initialized so it's possible to have a surface without one, as well as control where the toolbar is

Some change notes:

VisualEditor.php
* Added standalone module for mediawiki integrated unit testing

ve.ce.Surface.js
* Remove requirement to pass in an attached container to construct object
* Inherit ve.Element and use this.$$ instead of $
* Make getSelectionRect iframe friendly
* Move most of the initialize stuff to a new initialize method to be called after the surface is attached to the DOM

ve.init.mw.ViewPageTarget.js
* Merge toolbar functions into setup/teardown methods
* Add toolbar manually (since it's not added by the surface anymore)

ve.init.sa.Target.js
* Update new init procedure for editor, surface and toolbar separately
* Move toolbar floating stuff to ve.Toolbar

Change-Id: If91a9d6e76a8be8d1b5a2566394765a37d29a8a7
2013-05-15 10:39:12 -07:00