Commit graph

919 commits

Author SHA1 Message Date
jenkins-bot 877463e712 Merge "Add hooks and classes, initially to support GuidedTour" 2013-07-10 19:32:32 +00:00
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
Matthew Flaschen 7f094ee607 Add hooks and classes, initially to support GuidedTour
* Hooks for activation, deactivation, save dialog state change,
  and tab setup.
* Class for save button (needed to point to it in a clean way).
  Also done for cancel button to be consistent, though GuidedTour
  doesn't currently use this.

Change-Id: I4a0e0631d513fb09c3408f2f36a0de0bd51e1a37
2013-07-10 00:05:05 -04:00
jenkins-bot f8184ebeb9 Merge "Lock surface while inspectors are animating open" 2013-07-10 01:54:05 +00:00
Timo Tijhof 50b7a9fc93 mw.ViewPageTarget: Explicitly release our copy of linmod data
Follows-up Ic0c6d190c9b78 which introduced a full linmod copy in a
scope that is also accessible by other closures (namely the
callbacks to jQuery.Deferred #done and #always, and setTimeout).

Though in theory engines may be able to garbage collect it,
I doubt it. Though browsers probably destruct the setTimeout
callback I know  at least the closures pass to jQuery.Deferred
are not released by jQuery, so an engine would have to
understand these other functions well enough to know it doesn't
access the `data` variable.

Let's release explicitly to be safe.

Change-Id: I11000edcad4690dcce53b6e9d1a45bf2ab82fbcb
2013-07-10 01:02:10 +00:00
Trevor Parscal 33e2c8f280 Lock surface while inspectors are animating open
Objective:

* Prevent input while the inspector is animating open

Changes:

ve.ui.LinkInspector.js
* Disable and then re-enable the surface while the inspector is opening

ve.ce.DocumentNode.js
* Remove opacity changes on disable/enable

ve.init.mw.ViewPageTarget.js
* Change the opacity of the document when save dialog is open

Bug: 51075
Change-Id: Ic7910a666b33b41b57b035a15cf1f8c9264e7111
2013-07-09 17:16:25 -07:00
jenkins-bot bf930c88c6 Merge "Defer conversion in the sanity check" 2013-07-09 23:33:31 +00:00
Roan Kattouw e9ca44c86c Transplant CSS from the main document to each iframe
We previously manually loaded CSS into these frames, which is flawed
because it completely bypasses ResourceLoader (so CSSJanus didn't flip
them, necessitating a bunch of hacks for RTL), and doesn't pull in
MediaWiki styles (so templates inside references don't render correctly).
Instead, this commit copies all styles from the main document into each
frame's document, inlining what it can.

Loading all styles in dialogs and inspectors caused some problems,
initially. We didn't namespace our styles for dialogs vs. inspectors
at all; the only reason inspector styles weren't being applied to dialogs
and vice versa was because we controlled which files were being loaded
in which context. This commit namespaces the inspector and dialog styles
where needed so they don't conflict and try to override each other.

Tested in Vector and Monobook, but not in Apex and not in RTL.

ve.init.mw.ViewPageTarget*.css:
* Namespace styles that are only intended for the main document
* Undo Monobook's font-size: x-small; in frames

*Dialog.js:
* Remove addLocalStylesheet() calls, we don't need those any more
** ve.ui.MWDialog seems to be unneeded now, we may want to remove it

*.css:
* Remove @noflip-ped RTL rules where they were just flipped versions of
  their LTR counterparts

ve.ui.Dialog.css, ve.ui.Inspector.css:
* Namespace styles with .ve-ui-dialog-content / .ve-ui-inspector-content

ve.ui.Frame.css:
* Move the margin:0 and padding:0 here (were in the frame <body>'s style
  attribute) and add background:none to prevent frames from getting
  the skin's background (grey in Vector, a book in Monobook)

ve.ui.Dialog.js, ve.ui.Inspector.js:
* Add ve-ui-dialog-content / ve-ui-inspector-content class to the
  frame's content <div> so we can restrict styles to only apply in
  dialogs / inspectors

ve.ui.Frame.js:
* Replace infrastructure for @import-ing stylesheets with transplantation
* Remove code polling to see when the stylesheets were loaded
** We can't do this in the new approach AFAIK, since all styles in the
   frame are either inlined or inaccessible due to the same-origin policy
** We also shouldn't need it because the browser should have cached the
   styles when it loaded the main document
* Apply ve-ui-frame-body class to the frame's <body> so we can style it
** Move inline padding:0;margin:0; into ve.ui.Frame.css
** Move the ve-ltr/ve-rtl class up to the <body>

ve.ui.Window.js:
* Remove infrastructure registering stylesheet URLs to load

Change-Id: I4a37115301811ad860f4578344a04873ea8c2b69
2013-07-09 16:13:28 -07:00
Roan Kattouw b77a1b2250 Defer conversion in the sanity check
Conversion is apparently pretty slow on large articles, so put it inside
the setTimeout(). We still need to copy the data array synchronously
though.

Change-Id: Ic0c6d190c9b782f8c643d00d335f0e004d860bcf
2013-07-09 13:21:48 -07: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
Timo Tijhof d16fef546a mw.ViewPageTarget: Fix incorrect retention of the wrong oldid
* Only pass the oldid to the API from #load if we restoring from
  oldid in the url. Otherwise load the latest version.
* Setting 'restoring' from mw.Target instead of mw.ViewPageTarget
  so that we don't rely on mw.ViewPageTarget in mw.Target#load.
* Fix the API to not require 'oldid' to be passed.
* Fix the API to actually return the 'newrevid' property. It
  was doing a no-op on a $result that is never used due to the
  same variable being overwritten with the result of parseWikitext.
* Moved updating of wgCurRevisionId to mw.ViewPageTarget as it
  belongs there (possible future inline editors probably act
  on a different page than the main one). Also made it only
  update if it isn't undefined, so that a null edit doesn't
  result in wgCurRevisionId being unset.

Bug: 49943
Bug: 50441
Change-Id: I221e5038f95eadf6d87013e80f12394f0376a293
2013-07-08 16:11:23 -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
Roan Kattouw 92c38eab85 The great directory split of 2013
Move all MW-specific files into the ve-mw directory, in preparation
for moving them out into a separate repo.

All MW-specific files were moved into a parallel directory structure
in modules/ve-mw . Files with both generic and MW-specific things were
split up. Files in ve/init/mw/ were moved to ve-mw/init/ rather than
ve-mw/init/mw ; they're still named ve.init.mw.* but we should change
that. Some of the test files for core classes had MW-specific test cases,
so those were split up and the test runner was duplicated; we should
refactor our tests to use data providers so we can add cases more easily.

Split files:
* ve.ce.Node.css
* ve.ce.ContentBranchNode.test.js (MWEntityNode)
* ve.ce.Document.test.js (some core test cases genericized)
* ve.dm.InternalList.test.js (uses mwReference test document)
* ve.dm.SurfaceFragment.test.js, ve.ui.FormatAction.test.js
** Made core tests use heading instead of mwHeading
** Updated core tests because normal headings don't break out of lists
** Moved test runners into ve.test.utils.js
* ve.ui.Icons-*.css
* ve.ui.Dialog.css (MW parts into ve.ui.MWDialog.css)
* ve.ui.Tool.css
* ve.ui.Widget.css (move ve-ui-rtl and ve-ui-ltr to ve.ui.css)

ve.dm.Converter.test.js: Moved runner functions into ve.test.utils.js

ve.dm.example.js:
* Refactored createExampleDocument so mwExample can use it
* Removed wgExtensionAssetsPath detection, moved into mw-preload.js
* Genericized withMeta example document (original version copied to mwExample)
* Moved references example document to mwExample

ve.dm.mwExample.js:
* Move withMeta and references example documents from ve.dm.example.js
* Add createExampleDocument function

ve-mw/test/index.php: Runner for MW-specific tests only

ve-mw/test/mw-preload.js: Sets VE_TESTDIR for Special:JavaScriptTest only

ve.ui.Window.js:
* Remove magic path interpolation in addLocalStyleSheets()
* Pass full(er) paths to addLocalStyleSheets(), here and in subclasses

ve.ui.MWDialog.js: Subclass of Dialog that adds MW versions of stylesheets

ve.ui.MW*Dialog.js:
* Subclass MWDialog rather than Dialog
* Load both core and MW versions of stylesheets that have both

ve.ui.PagedDialog.js: Converted to a mixin rather than an abstract base class
* Don't inherit ve.ui.Dialog
* Rather than overriding initialize(), provide initializePages() which the
  host class is supposed to call from its initialize()
* Rename onOutlineSelect to onPageOutlineSelect

ve.ui.MWMetaDialog.js, ve.ui.MWTransclusionDialog.js:
* Use PagedDialog as a mixin rather than a base class, inherit MWDialog

bullet-icon.png: Unused, deleted

Stuff we should do later:
* Refactor tests to use data providers
* Write utility function for SVG compat check
* Separate omnibus CSS files such as ve.ui.Widget.css
* Separate omnibus RL modules
* Use icon classes in ViewPageTarget

Change-Id: I1b28f8ba7f2d2513e5c634927a854686fb9dd5a5
2013-07-02 20:51:38 -07:00