Commit graph

9 commits

Author SHA1 Message Date
Timo Tijhof a7e8c9d660 mw.ViewPageTarget.init: Document use of mw.libs.ve to test presence
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
2013-07-10 15:55:17 +02:00
Timo Tijhof fdedbb36e2 mw.ViewPageTarget.init: Clarify reason for FF12 / FF14 blacklist
Follows-up I7a9dddb693091f.

Change-Id: I49a952f6b1714808cd4f063c48cf3102997f8746
2013-07-09 13:11:15 +02:00
James D. Forrester d59a3f1202 Blacklist Firefox 13 and 14 too
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
2013-07-08 18:20:42 -07:00
Timo Tijhof 106f357852 mw.ViewPageTarget.init: Only bind edit section links on view page
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
2013-07-08 16:12:47 -07:00
jenkins-bot 614a1a3d9c Merge "mw.ViewPageTarget.init: Move edit section to top init" 2013-07-05 18:40:12 +00:00
Timo Tijhof eddd0b384a mw.ViewPageTarget.init: Move edit section to top init
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
2013-07-05 18:29:12 +00:00
James D. Forrester 92991ef20f Blacklist Firefox 11 and 12
Bug: 50780

Change-Id: I6461f066443223dfd5f6d73aeea0c87cbbdb81d0
2013-07-05 11:24:06 -07:00
Timo Tijhof 1875851f7e mw.ViewPageTarget.init: Remove harmless debugging code for ES5
Was accidentally kept in Ic8b0004ab5288fa9.

Change-Id: I1c95189437e3e74c5e2884d14c1ccf000ef0c178
2013-07-04 02:08:41 +02:00
Timo Tijhof b21fe5fbc1 Split off setup from the rest of mw.ViewPageTarget
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
2013-07-04 01:18:28 +02:00