The activation timing was always a bit of a lie even pre-TargetLoader,
because the timer only started when the first RL request for VE
modules had loaded. But at least the process it covered was consistent,
which is no longer true with TargetLoader. Now that we start the
request for the HTML together with the RL request, the activation
time might include some, all or none of the HTML request depending
on how fast the RL request was.
This change makes the activation timings more useful by measuring
from the moment the user clicks "edit" to the moment the editor
is done loading, which is what actually matters.
* Moved start of activation timing to VPT init
** For mobile this falls back to when mw.Target#load is called;
we'll have to fix that in MobileFrontend later
* Moved end of activation timing out of TargetEvents#onSurfaceReady
into individual onSurfaceReady handlers
** This is necessary because VPT's onSurfaceReady does quite a lot,
and we want to include the time that takes in our measurements
Change-Id: Ie44f0b839b39a2b3b22dcd86e20f0d1170cb6069
MobileViewTarget.
Due to this being missed, pageName was getting set to a jQuery object,
which eventually got passed as a data value in a $.ajax call, causing
jQuery to emit a TypeError: Illegal invocation.
I guess this needs a MobileFrontend commit as well. Don't think it fixes
all the issues with loading VE mobile though.
Bug: T78710
Change-Id: I431a902563f608a7a33028cd60112f39c57000a4
Also remove toolbar definitions as they can now be derived from
command availability.
Depends on If32d514a in core.
Change-Id: I2313f3cc2531686b27f96dc1110b28bb4b295f89
Extract the part of mw.Target#restoreEditSection responsible for moving
cursor to a separate method and move the cursor only on desktop.
Bug: 68832
Change-Id: I4ffc54ced64ce9e52d0cbcffb2fb4d082239098c
Trevor promised to do this in Iafe64a6f but never did.
This needs styling changes to look right. It also means that
VE mobile standalone doesn't have a context at all right now,
which is horrible, but at least this makes MW mostly work.
Bug: 68546
Change-Id: Id8cc4b07905f777f667f36cbcc65e821847142d5
When I05f11246ca90a1ce3f741fd93194a827528cd597 gets merged, we will need
this to be able to scroll to a section on iOS (where the content will be
scrolled within a div, not as a whole page).
Change-Id: I6e47edfa8c3a3a46fd7a4f11e4a54955f3694b9b
Use new setupToolbar and setupDebugbar methods in base target.
New changes:
7ff523d Localisation updates from https://translatewiki.net.
3815224 [BREAKING CHANGE] Debug bar refactor
155f4ab Edit HTML mode in demo
Change-Id: I554ce51eae872ab0f741a913bf10394c2a8c3e52
Replace instances of target.$document, which was removed
in VE core.
New changes:
8083623 [BREAKING CHANGE] Remove $document cache from target
9256158 Cleanup target properties
cc0d71f Multi-surface fixes
ba8872e Localisation updates from https://translatewiki.net.
Change-Id: Ibff83cae770c056ed64bcf438ed74b44d929cdc0
No need to set in mw.Target as it now exists in core Target.
Add config param to MobileViewTarget override.
Depends on I555935d2 in core.
Change-Id: I72be9098bd9d59272ca3d7a9a64dca4271ef3ee5
These changes are to accomodate the design for the mobile/tablet
version of VisualEditor which uses an icon rather than a label
for the drop-down button.
Change-Id: I1086ed4a84ae4061fcc79cc7f587657232c5d5df
New changes:
dd15f23 Split ve.ui.Surface into DesktopSurface and MobileSurface
16283f4 Add OOjs UI's sco.json i18n file
ef94038 Split ve.ui.Context into DesktopContext and MobileContext
Minor adjustments to point to desktop and mobile Surface or Context.
Change-Id: I7cf6f99a5a1216a28a7146afcd4deb68c7eac38e
The experience should be consistent between mobile and desktop.
We should explore re-styling these buttons to look like
Ib3c94d19231b018a509b78269001223ad0568795 in desktop as well
at a later date.
Change-Id: Ic9e4c5d12c3c75fcb195432c9155ec0a7eecac04
Split tracking out of the base target and from viewPageTarget
Primary reasons for this change:
* Makes it possible to resolve an issue with tracking in mobile
* Lets us reuse the viewPage save workflow tracking
* Support existing and new targets with tracking
* Simplification of target classes
Change-Id: I036e4f2129d929db0a3b9a4baa87c946a4b194a9
* Use correct class name for setUpToolbar() in MobileViewTarget
* Move shared setUpToolbar() code into ve.init.mw.Target
* Fix iconModuleStyles documentation, remove leading space
Change-Id: Icf5ed36fd817837c0434db8202bef8a78e6cb898
The selector is too weak and results in the toolbar being placed
in positions it shouldn't be! Whoopsy!
Change-Id: I63540130e4de01f9326fe110d606985fea70b644
The toolbar in very desktop vector skin specific
In mobile we want to have more control over the toolbar,
and its placement.
* Thus make setUpToolbar abstract
And move the function to ViewPageTarget
* Introduce ve.init.mw.Target.static.iconModuleStyles to
allow the use of different icons
* Update the mobile toolbar to only have B and I tools
Change-Id: I4c72b4b9128b3a74de8b8b5bce7664fbb315216b
The down arrow is no longer default, so it needs to be specified
explicitly.
Updates submodule to include indicator changes
(see I0a1faef11a1e7e6ea3e44275c85f2efafae4dc9a)
Change-Id: I32aef3ea2e66fd823aeb07dac06cfefba9954270
Follows-up I55ef2622c9eacc which activated code introduced in
mw.Target in commits before that one that caused a change in the
execution order.
Hiding of page content (regular wiki page content provided by
original view request) must happen before the surface document is
focussed.
We used to hide the content from mw.ViewPageTarget#setUpSurface,
which is called from #onReady, which focusses the document after
setUpSurface is done.
Most of this code was moved to mw.ViewPageTarget#onSurfaceReady
which is the listener for the surfaceReady event emitted from
If our surface document gets focus while the original wikipage
content container is still there, the view port is forced to
scroll down because our surface is the next element sibling after
the wikipage container in the DOM.
And browsers (apparently Chrome is not affected) naturally retain
scroll position even if the elements above the one you "scrolled to"
disappear.
We can't (and shouldn't) move the hidePageContent call because
that's the responsibility of the Target subclass, so instead
moved the document focus to below the hidePageContent which is
now also part of the responsibility of the Target subclass.
Also:
* Removed target.surfaceOptions reference because that property
does not exist. We never passed a second argument here, and
whatever this was intended for, doesn't exist.
Bug: 58089
Change-Id: I230fbd5401cbd6e3b9450c7f156650409be8ef16
Changes include:
* Target mobile for ve dependencies
* Create mobile view constructor
** Some tools like dialogs are excluded for now
* Refactor mw.target to permit code reuse
** Split out pageTarget view functionality from core init methods
Change-Id: I786b63ab57518fc6af7761501259ed66592f70e3
