== 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
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
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
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
* 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
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
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
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
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
