/_preconnect is a special end-point that is handled by Varnish with an HTTP
204, sparing the RESTBase backend. See I95a716592.
Change-Id: I0c0430014768d7a1c6673d078569d0cf4062d338
Keep VisualEditor load times snappy by eagerly establishing a connection with
RESTBase via a beacon request, which is deferred until after window.onload /
setTimeout to ensure it does not slow down the loading of the page.
Task: T94784
Change-Id: I19fd2ef6beffe1c4c4f05c2716da079b49e88b95
If70ff601 didn't really fix anything. The only reason you'd want this data is
to distinguish between mobile and desktop data, but it just set the value to
the desktop version always...
Bug: T95432
Change-Id: I76722e3ad8b7dbe644374b24093bec696f27f48c
Due to changes in the way VisualEditor is loaded, the trace.activate.{enter,exit}
events no longer enclose the entire VisualEditor initialization process. This
change ensures that trace.activate.enter is emitted as soon as the user clicks
on an edit link / tab and that the trace.activate.exit is not emitted until the
toolbar has been fully activated.
Change-Id: Ief798faa95a58898b9ae4dcbbbd30506c5dbd9a7
On short pages which don't extend below the fold, the progress
bar should center within the #content element.
Change-Id: I0b99e42f5bab8177d3b4ca6dd372d6403ae9b136
Set 've-activated' as soon as edit is clicked, with a 've-loading' state.
This necessitates moving the relevant styles to mw.ViewPageTarget.init.css.
Change-Id: Ic9757cdbf63a2f72eda0dd03ff5588d79028ba0e
Move requestPageData from mw.Target to TargetLoader, call it
in init init, and pass the promise it returns into load()
via activate().
Bug: T90372
Change-Id: I828b8474e5a76b3d0d7d08735b4d865c29d2f820
This introduces TargetLoader, which manages plugins and RL modules
in a slightly more generic fashion so that Targets themselves don't
have to. This allows us to load all RL modules in one load.php
request, rather than first loading ViewPageTarget which then
loads the other modules.
TargetLoader loads in the bottom queue, so it will be loaded
as part of the main load.php request, but in VPT.init.js we
still have to wait for it with using() because it might not
have arrived yet. This also degrades gracefully on cached pages
where TargetLoader isn't in the bottom queue: it'll be loaded
as a separate request instead, which is suboptimal but no
worse that what we were doing before.
Right now TargetLoader is small enough that it could also be in
the top queue, but in the future we want to add things like
the action=visualeditor API request to it, and mw.Api is
relatively big.
Note: this also makes a breaking change to the plugin API:
plugin callbacks no longer receive the target instance
as a parameter, as they're now executed before the target
has been constructed rather than after. In the long term,
if we want to give plugins access to the target instance,
we could give them the target promise somehow. For now,
I've killed this feature because nothing used it and
the change from a direct object reference to a promise
would have been a breaking change anyway.
Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init.
Bug: T53569
Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
Follows-up I002322beaae. I had this in the local patch but got
lost in rebasing. The missing return statement caused an uncaught
error when clicking section edit links as it was not forwarding
the return value.
Change-Id: I66b6a789f7182a4446122e94f19cfdb324f8d675
De-duplicate the logic of:
* Call showLoading()
* Call getTarget()
* Call activate()
* Bind always(hideLoading)
Also use then() instead of done() on getTarget() so that failures
propagate to the always() handler. Previously the interface would
indefinitely be in a loading state if target fails to load.
Change-Id: I002322beaae64c0de96457eb56dbc68a5fc16369
Originally added in 5036099906.
* Account for bug T89513 for 'tempdisable' (was done for 'enable' in 9cba9910c6).
* MediaWiki core now loads user defaults in a separate module not
subject to page caching, making our workaround obsolete.
Keeping defaultthumbsize as that is intentionally ignoring the user's
preferences.
Change-Id: I07a7aa8e08c728ddeba67f36a98e989c220dcb50
New changes:
9929b6d [BREAKING CHANGE] Make ve.init.target an OO.ui.Element
Local changes:
* Fix target constructors now they generate this.$element
Change-Id: Ia6bf604c67305834a3f73863a10336cfbb83fa77
Move ve.track() subscriber to its own file, and have it
route mwtiming.* events (for TimingData) and mwedit.* events
(for Edit schema) differently. Most of the data population
lives in the subscriber, so actual ve.track() calls are
pretty lightweight.
Existing ve.track() calls with timing data were kept with
their names intact for backwards compatibility, but
we may eventually want to throw them out and start from scratch.
ve.init.mw.ViewPageTarget.init.js:
* Remove old track subscriber
* Track init and ready events
* Remove old ve.track( 'Edit', ... ) crap that didn't work
ve.init.mw.ViewPageTarget.js:
* Fire the saveWorkflowBegin event before the save dialog
loads rather than after
* Remove unnecessary this.events.trackSaveError() calls:
TargetEvents already listens to these events itself
* Remove badtoken handler because all it was was an
unnecessary trackSaveError() call
* Add abort tracking
** Pass trackMechanism through deactivate() and cancel()
ve.init.mw.Target.js:
* Add static.integrationType to populate the 'integration'
field in the schema
ve.init.mw.TargetEvents.js:
* Simplify onSaveError* methods away into connect bindings
* Map track topics to mwtiming.* so they can be routed separately
* Track save-related mwedit.* events
Depends on I978eda96c in WikimediaEvents
Change-Id: Iae677d9b15c71d2b18e795bd5179d11876c06abd
Follows-up Ica33de675, If505a46f54.
* The setting of 'uri' looked like a redundant local alias before
passing on to pushState, but is actually important on itself.
* Remove binding for hideLoading. It's a detachable method on
a singleton, not an instance method.
Change-Id: Ic3536caf3f42ee893124312fd5981b67336bd480
When you clicked the Back button in the browser, the URL
in the address bar would change (removing veaction=edit),
but we would not go back to read mode. This was broken
by 5c0c11753 almost a month ago but apparently no one noticed.
This is because 5c0c11753 moved the pushState() calls to
be earlier (in init init), making the replaceState() call
in the ViewPageTarget constructor (which is there
specifically for this bug) run too late in those cases.
The simplest way to fix this is to duplicate these replaceState()
calls before the pushState() calls in init init.
I feel a bit bad about copying code, but not very bad
because the code I'm copying already has a FIXME comment
about how there should be a better way :P
Change-Id: I6627a5d1d9377ae815bc58bceeb059ce9f4f19ab
Just like DOM interfaces such as document and location. And JS
constructors like Object.prototype, and libs like jQuery.
No need for the window host object.
Change-Id: Ie39aaea2ca17bdec5fb3afe32a4e6c9f751bd0c6
After 5c0c117, clicking the VE edit tab on /wiki/Foo?oldid=123
sent you to /wiki/Foo?veaction=edit , dropping the oldid parameter
and editing the current version rather than the old version.
Fix this by only recomputing veEditUri from scratch when necessary,
and reusing the current URI when possible.
Change-Id: Iee9a745990f1a2bad40f46b8cdaaa727bb7fead8
We were attaching its removal to the wrong promise in 2 of the 3
places where it was being called.
Also this file is horrible and should be refactored. A lot.
Change-Id: If74b1629266f22e2d110305b139bef4a8e69b13b
Moved the spinner code from ViewPageTarget to ViewPageTarget.init to make it appear immediately on clicking edit.
Bonus: also fixes the URL to add the parameter vesection when clicking a section edit link.
Bug: 65453
Change-Id: Ica33de675203cc0f0594b8362731c4e98a644313
Depends on I468d4eb4 in core.
Uses various hacks to trick the test runner into thinking
an MW target is in use, when in fact we still use SA targets.
Change-Id: If4611307d5d7aaee4af84f86ef82faf9078043b6
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
Follows-up e3be4a6. Object properties default to undefined, no
need to check existance first. Looks like like an "isset()" in
PHP for preventing E_NOTICE.
Change-Id: I594b23e6caf1e17d6d5d37e6a5fd81152e78b3a6
jshint:
* Update to grunt-contrib-jshint v0.10.0 (jshint v2.5.0).
* Remove coding style options covered by jscs.
* Enable new option "freeze" (prohibits changing native prototypes).
http://www.jshint.com/blog/new-in-jshint-oct-2013/#option-freeze
* Re-order to match http://www.jshint.com/docs/options/
jscs:
* Update to grunt-jscs-checker v0.4.4 (jscs v1.4.5).
* Format .jscsrc file in a more spacious way and order the
properties less arbitrarily (using the jscs's readme order).
* Enforce more details of our coding style
* Get rid of the unsable "sticky" operator rules which have been
deprecated in favour of using other rules instead that are able
to enforce this more accurately.
- disallowLeftStickedOperators: Remove deprecated rule.
* Ternary covered by requireSpacesInConditionalExpression.
* Rest covered by requireSpace{Before,After}BinaryOperators.
- requireLeftStickedOperators: Remove deprecated rule.
* Comma covered by disallowSpaceBeforeBinaryOperators.
- requireRightStickedOperators: Remove deprecated rule.
* Logical not (!) covered by disallowSpaceAfterPrefixUnaryOperators.
See also If46b94ce1, Ib731f11b1 and I0b0cadbc5 in oojs/core.
Also:
* Update grunt-contrib-watch to latest upstream version.
Change log at https://github.com/gruntjs/grunt-contrib-watch/blob/v0.6.1/CHANGELOG#L1-L17
Change-Id: I6c5a34afea8b05a3dca617897c192594df06ca90
We don't have a FOUC on the appearing of the 'edit' link. That
one is handled quite intelligently:
* Via the stylesheet that is also loaded in noscript mode, its
(hidden) appearance is already predetermined. So as soon as
those elements are seen by the browser they style correctly
for users without JavaScript (display: none).
* This same stylesheet also hides it for users with JavaScript
but where VE is not available (e.g. due to browser support).
While ve-not-available is added very early on (before
document ready), it could in theory cause a short FOUC, but
that's okay. We simply don't know that VE isn't supported
until then. We optimise for the common case (JavaScript
enabled, VE available), while still ensuring that it is
always hidden in noscript, and is hidden as soon as possible
when VE turns out not to be available.
For some reason, one small detail (the little bit of whitespace
added inside the brackets), was left out of this and was
implemented by adding the class 'mw-editsection-expanded' to them
from a document ready handler.
* First step, get rid of the script that adds this class and
use ve-available instead. That means they're styled
correctly much earlier (we add the class to <html> before
document ready). This can still cause a brief FOUC, though
in most cases they're correct from the start.
* Step two, make brackets expand by default for script users,
and let ve-not-available reset it. This way, like with edit tabs,
a FOUC will never happen for ve-available. And even for
ve-not-available, a FOUC is rare since we add it before
document ready via <html> look-ahead styling.
There was still a brief reflow jump because of negative margins
between two paint events. One was undoing the other at a later
time. These negative margins are a remnant of when we were doing
animations (follows-up I4b9c47fd65a70). They were added to reduce
reflows and content shift, but were now actually causing them.
Removed "padding-right" from mw-editsection, and negative margin
from the brackets.
Also:
* Don't add inline 'style="direction: ltr;"' on every single
editsection throughout the DOM. This was the only operation we
were doing unconditionally. While I doubt the need of it in
general, we can at least allow MediaWiki to do it right, and
only add the override if needed. This saves quite a few DOM
operations.
Change-Id: I7a729edc2cd4a66ebc0ad6935ffd02cb9b948bff
Unfortunately the best way I've come up with to do this so far is
checking the namespace.
Bug: 53477
Change-Id: Ib2dbe91aff516f2d2408e07ff3f73ea861bfcbe2
