The stylesheet contains workarounds for highlights on references
being drawn in the wrong place, resize handles appearing on headings,
and highlights being opaque.
Change-Id: I78da4d6a751429cd160b693b4a524fc7ea1ef76f
Also implement isInternetExplorer() in mw.Platform using jquery.client.
New changes:
9b2102f Skip over nested handlesOwnChildren nodes in getRelativeOffset
30a9835 Localisation updates from https://translatewiki.net.
5d142a0 Restrict get relative offset to movements of +/-1
7a2c984 Check that the surface has a selection after focus
851a63d Remove jquery.client
8786e53 Add evil detection functionality for IE
96f19ad Disable triple-click handling in IE
d746d42 Revert "Restrict get relative offset to movements of +/-1"
859d578 Revert "Skip over nested handlesOwnChildren nodes in getRelativeOffset"
Change-Id: Ib2e6568a862336e2516e4c519468218ec2a84834
Merge the media edit and media insert dialogs. Allow editing
of media properties when inserting a new image, and also
allow the user to replace the image on edit.
Bug: 67170
Change-Id: I35bd95503565dbf95090ee8110284db5a8fbba83
Mobile doesn't want the tool+dialog functionality for those yet,
so move them to a separate module and only load the bare bones
for mobile. We did the same with mwimage/mwimage.core.
Change-Id: I9185ce62f458b3de08cbd28f2a41370d2301de9d
This puts reference insertion and editing tools into the same menu (yay) and
applying-annotations-to-text tools into the same menu, too.
As part of this, I'm re-labelling the generic reference tool to "Basic" (now
that it has some context for users).
Change-Id: I8b8196d3c2e40237d61c8491ab30e737b82597d6
This will mean it will be more obvious if making a change to the SD or HD version
that an equivalent adjustment may be needed.
Change-Id: I6129220839ef55017fe69d723524ecdf6cf0234f
1. It's a bad check, it tells you if the device supports mobile
events, not if it's mobile (e.g. a touch screen laptop has such events)
2. It's no longer used
Change-Id: Ic46bc5b8fdc33b7c2b2bd67e75d65a5e564dbeca
Our coding style has been upstreamed and first released
in node-jscs v1.5.0 (grunt-jscs-checker v0.6.0).
Change-Id: Ifc0cfc7177946b9d11407f60e38b0177883724c5
This reverts commit b7401f838b.
Didn't break everything, but we should probably avoid this getting deployed until I can work out wtf is going wrong with it.
Change-Id: I048143239e998b30aba79fa395a0af1cb06c6a9b
This reverts commit 5565ccca54.
I have no idea what is going wrong on deployment-prep to cause
the error in bug 66792. Let's try to find out.
Bug: 50341
Change-Id: I5041de838128bb55c57baddae01cdcb263626537
Causing HTTP 500 errors in ApiVisualEditorEdit.php (calling
getDisplayTitle() on a non-object).
This reverts commit dedc89b5ff.
Bug: 66792
Change-Id: Iaf438660f0623dc05f76294ad847b2fc5e25bed6
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
Implement new language platform functions.
Also remove unused MWLanguageSearchDialog and MWLanguageSearchWidget.
New changes:
4d919d2 [BREAKING CHANGE] Move language functions to the platform
Change-Id: I54c0a8e5816a3c81851f95f1d3062a6091a9f4a3
* Update size of save dialog earlier on, and swap back to save panel in
save dialog on setup instead of ready to avoid scaling and sizing
simultaneously
* Update use of closing/closed/opening/open events to use
setup/ready/teardown events instead
New changes:
43a48cb [BREAKING CHANGE] Update OOjs UI to v0.1.0-pre (9f4f250f88) for window process cleanup
Bug: 65705
Bug: 65343
Bug: 60843
Change-Id: Idf6f85ae12f6ca80fde57a400cb5b11270938c1a
Remove ProtectedNode mixins for new FocusableNode.
New changes:
e1b0e33 [BREAKING CHANGE] Merge ProtectedNode into FocusableNode
Change-Id: Ie515704163c24317739fd34d35094b9ada6bfa66
Replace instances of target.$document, which was removed
in VE core.
New changes:
8083623 [BREAKING CHANGE] Remove $document cache from target
9256158 Cleanup target properties
cc0d71f Multi-surface fixes
ba8872e Localisation updates from https://translatewiki.net.
Change-Id: Ibff83cae770c056ed64bcf438ed74b44d929cdc0
The API moans about it in a warning, but it works.
Along with edit page checkboxes, this also fixes edit notices.
Bug: 65455
Change-Id: I7c319d43fd06ab04ab4e4cc099ae49b11c31fabd
Switch to processes for windows (dialogs/inspectors)
This conversion also required the splitting of MWLinkInspector into
MWLinkNodeInspector and MWLinkAnnotationInspector.
New changes:
88fe25f [BREAKING CHANGE] Update OOjs UI to v0.1.0-pre (dd888aba5c)
Change-Id: I662d8985463c9fc881775f70aef87ebeb454a73f
It now only sends a single 'done' event, which we can use .once on
Relies on I4f485d4f in OOjs UI.
New changes:
418cd67 Update OOjs UI to v0.1.0-pre (0f101c6f5d)
Bug: 65571
Change-Id: I19aa65612bf02bed056de292f212d2f5732a8fec
No need to set in mw.Target as it now exists in core Target.
Add config param to MobileViewTarget override.
Depends on I555935d2 in core.
Change-Id: I72be9098bd9d59272ca3d7a9a64dca4271ef3ee5
Instead of overwriting everything else on the page (e.g. 'Pages in category ...')
See also bug 65349 / Ib6c49286 for file pages with a similar issue
Bug: 64239
Change-Id: I59ff9de5d0463f0f1ae8a18d54ebea5844fb1af5
Check that the user is anonymous before looking at their cookie to decide whether
to show beta warning dialog.
With the existing code, we would see that the preference is false and then check
that they have no cookie. But being logged in should make the cookie existence
be disregarded.
Fixes Ica9e5a92
Bug: 65821
Change-Id: I84e31323930c404222388bb74e4b4ca8d303e05c
We weren't unbinding these handlers at all, and so the 'ok' or 'cancel'
handlers could run multiple times for one button click, and even worse,
you could get in a situation where clicking 'ok' in one confirm dialog
would also run the 'ok' handler for the other one. This happens because
the ConfirmDialog instance is recycled by the WindowSet.
The way the unbinding is done is ugly; we should either consolidate the
'ok' and 'cancel' events so we can use .once(), or come up with some other
way to automatically unbind the handlers.
Bug: 65557
Change-Id: Iabf0c0d0229add09cc775358fc5a4e5ae783db04
"Yes, switch" isn't constructive; make it primary instead.
"No, cancel" isn't destructive; make it neutral (no flags) instead.
Change-Id: I841cbed4a81eaed679a8c7da89942c6b030a1217
"Discard edits" isn't constructive, and "Continue editing" isn't destructive.
Instead, mark "Discard edits" as destructive, and make the continue
button neutral (no flags).
Change-Id: I7648555ad47be698e75b5019d7738b0afb8611aa
Per TTO on bug 51655, the implementation of confirm() in most browsers is crappy and we
shouldn't use it.
Change-Id: I755085a253c05958e4b50af57b19dab90f2f0fb6
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
Relies on:
* I292fb34d in OOjs UI to add the confirmation dialog
** I67329820 in MediaWiki core to use the messages added in OOjs UI
** I38f5bb63 in VisualEditor core to register the confirmation dialog
Bug: 50955
Change-Id: I98f9a03d780556b360b57c018c05a27cc1b3862e
Usually we can just send 0. Sending anything else makes PostEdit think we're restoring an old revision.
Bug: 65269
Change-Id: I60454a7a4ea3f6c7cef4c707da3016dd0ec29b88
These changes are to accomodate the design for the mobile/tablet
version of VisualEditor which uses an icon rather than a label
for the drop-down button.
Change-Id: I1086ed4a84ae4061fcc79cc7f587657232c5d5df
Three 'minor' points:
* You have to declare even hidden preferences. Whoops.
* There's no such thing as an "optionsToken", use "editToken".
* You need to POST action=options API calls.
Ahem.
Change-Id: I9c4358107af7bcfca157bd014de49882914e990c
For logged-in users, we can a preference instead of a cookie. This way it is
also preserved between browsers and when cookies are cleared.
Keep using cookies for logged-out users, except if the beta welcome dialog
has been suppressed using the one-off GET parameter 'vehidebetadialog'.
Bug: 55551
Change-Id: Ica9e5a92841fec003ce4a21d740a9bc6ff3da9c7
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
There was a slideDown() call, but this didn't do anything since
toolbars are visible and in the DOM by default.
As a temporary hack, hide it synchronously after creation and
then do the slideDown still.
This could ever so briefly cause a flash, though that didn't
happen in my testing.
This makes the experience smoother when we initialise the surface.
In particular the moment where we swap #bodyContent for our Surface
(which should look visually almost identical), before this change
it was still a bit of a flash since the Surface version has a
toolbar on top, and thus instead of swapping smoothly, we hide
content and show a similar piece of content that has an incompatible
offset from the top.
Bug: 64751
Change-Id: Id94974ba71fd887ce494d7b2b16ec62d43b18575
