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
