This preference will allow users to opt-out of VisualEditor during the beta
if they so choose. We do not re-use the alpha enablement flag because (a) this
would lead to a confusing preference description, and (b) because opting in
and then out of the alpha is not the same user choice as opting out of the
beta period.
Change-Id: I0f0a1b5eb21703ad422d007cab65c75ac1aa6fd8
Load the module always and have the conditionals on the
client-side so that we can change these without running into
problems with the new conditions not being rolled-out quickly
for anonymous users because the load queue is in the HTML
and cached for 30+ days.
This also allows us to fix above problem retroactively in wmf
production by just adding a mw.loader.load for this module
in something like MediaWiki:Common.js or something else that is
already in the cached load queue (temporarily, until the cache
has rolled over).
Removed unreachable code for loading ext.visualEditor.splitTest.
Change-Id: I21114960a88d224747447f2dc83d17d160f5f066
Refactor a few things to make it easier for scripts to see
not just whether mw.libs.ve is present but also whether it
allows the user to activate VisualEditor.
Change-Id: I50da8d9a260207d4ec1c43254dfe738f91386a9e
The presence check used to be against the VE global, but we
recently made that impossible without providing an alternative.
Though by accident, mw.libs.ve has become the new way to check
for presence.
Change-Id: If85695525777a71dde467675052d2ede4e52c9b7
Firefox 13 and 14 were the cause of links magically turning into [[./Foo]].
Once the immediate rush of deployment is over, we'll want to investigate as
to why and hopefully find a way to unblacklist FF.
Bug: 50720
Change-Id: I7a9dddb693091fa1e44b4325e77b9e4f55e5c193
The handler for the Edit tab already is in this conditional,
for edit section we were making the assumption that they only
ever appear on a view page, but that's wrong. They're also shown
on a diff against the latest revision of the page.
Bug: 50925
Change-Id: I802e548cbcdc03cfca66129466668854604bc3e7
Since we're now only loading the light-weight init on page load,
the section editing wasn't just deferred to after page load (like
it was before), but wasn't happening at all until you clicked
"Edit" (at which point the library loads). It only worked when
going back to "View" after "Edit".
Contrary to tab layout, edit section handling needs to be
accessible both in the top init and in the main target class
because we need to run it both at run time and after the user
has saved a page when we show them the updated page without
refresh. This is why we need to transfer the method at run time
and give the main class access to it as well.
Can't wait for bug 50707 to get rid of this mess...
Bug: 50731
Bug: 49993
Change-Id: Iab9c81222df7f1084179c3643d158374a89ca14b
Initialisation initialisation? It's time to rename ve.init
to ve.platform and ve.init.Platform to ve.platform.Environment,
but that'll come later.
* Moved support detection and skin set up to separate class-less
file.
* Swapped usage of ve.msg for mw.msg.
* Callback of edit tab now does an mw.loader call to fetch
the actual VisualEditor libraries.
Though mw.loader won't load the same thing twice, we would
bind a callback each time. To avoid instantiating ViewPageTarget
more than once we use a Deferred.
Bug: 50542
Bug: 50608
Bug: 50612
Change-Id: Ic8b0004ab5288fa91bb29d496485b93ffd8d977e
