Add a message indicating to the user that no image results were
found in the media insert dialog in case no results are found.
Bug: 52463
Change-Id: I93aea897d864298bf891a90c2fb147f7d34df06d
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
Before applying default size based on originalDimensions, make sure
these are available through the scalable call. The image will be
marked as default size, but the presentation will depend on whether
or not we have the defaultDimensions from the API.
Bug: 65239
Change-Id: I41b30498713e969bd24ef0ad3e9a074c6ffcdc3b
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
Greatly enhance the functionality of ve.dm.MWTransclusionNode#isSingleTemplate
and actually use it places.
Use mw.Title to normalize titles, accounting for case differences and
spaces vs underscores. Also allow an array of template names to
be specified.
Use isSingleTemplate() in the transclusion and citation dialog tools,
which were duplicating this logic. Also document the .static.template
properties.
Without this, the citation tool will appear for a reference using
{{Cite news}}, but not for one using {{cite news}} or {{Cite_news}}.
Change-Id: I18d2bb1b22a5ab269694ad0818b1bb326ef8d1fd
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
Make sure that each API request per file is delivered once. If the
file appears more than once on the page, the API request for
scalable details will be sent once and cached so there aren't
multiple API requests per image.
Change-Id: I68507a8ceb31b77dbf33d1074939ce6219cf076e
> JQMIGRATE: jQuery.fn.error() is deprecated.
While at it, also avoid using the overloaded .load(). It has
quite a few different signatures (one of them is to load $.ajax
by url and replace the contents of the element, completely
unrelated), and calling .on() directly is quicker as well.
Change-Id: I139b0c603577b5a0102d2ff679bd86b792830e3e
Note that I reported Bug 64655 for Chrome but upon refactoring
this test I find the buggy behavior now in Firefox but Chrome
is fine. Browsers are weird, and the Links inspector is too.
Change-Id: Ibd90a33bb43342dc1d7410d621f01875e1c177bf
possibly WIP
These changes make the test pass, still thinking about whether we
should test the workflow changes, which are cognitively different
than before
Change-Id: I85955836f0eeedcb55e7a5260101339d2f73d2e6
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
Get rid of all hard-coded values for both the target page
and also the text on the target page, which is now all set
in the .feature file.
Note that we're deconstructing the @make_selectable hook
by doing this. @make_selectable may become obsolete when
all the tests are refactored to use APIPage
Change-Id: Iad1b160d9d0274effb8504f276bd4816932d299c
Also adjust calls to InputWidget methods changed in
I324dfc2 in OOUI.
New changes:
9da32d7 Update OOjs UI to v0.1.0-pre (e6edd86d37)
b6aa671 Localisation updates from https://translatewiki.net.
1cba6e0 Update OOjs UI to v0.1.0-pre (9a6c625f5f)
94629f9 Localisation updates from https://translatewiki.net.
Change-Id: Id58d199c7ce3332a104ab2a5c395561ab94ae060
Using @edit_user_page hook is a workaround that avoids the
problem where Selenium brings up Firefox with the cursor in the
address bar
Change-Id: Iba42cbb74378952760db3db68130ac74219cde9b
this.transclusionNode doesn't exist. Also remove instanceof checks
as they are already done in #get(Selected|Reference)Node.
Bug: 64717
Change-Id: I7ff0133d1ad45edda8de2cbad459706dbaceb5f2
In two cases we were using fragment.getSurface().getFragment() which
creates a new fragment from the current selection instead of using
the range of the original fragment.
Change-Id: Ib41efe2ceb670a125c0c306d143e56f9b9c349e7
Adding a template by clicking the button without dismissing the lookup
menu first was leaving the menu open and inserting a template with the
query instead of the match.
Changes:
* If the lookup menu is visible, choose the selected item before using
the value of the lookup input
Depends on I3aa4e87 in OOUI
Bug: 64334
Change-Id: I22e04bd2d3628f03060d3734f9774b811c82f73b
* Move description to a popup behind a little info icon button
* Make required indicator generic status indicator (required/deprecated)
and move to left of the field
* Move param name and actions to above the field
* Show deprecated status and description
Bonus:
* Use auto-focus on CitationDialog (whoops!)
* Make pages that aren't meant to scroll not scroll (whoops again!?)
Depends on I59211b2 in OOUI
Bug: 53612
Change-Id: I3b968ad14aa6c43b6484e2565a9367d2ebc72fc5
At some point getTitle was changed to updateTitle but the caller was still
assuming it would return a string. Also, we removed the transclusion
dialog title message, but were still trying to use it.
Changes:
* Change the logic so we use the parent method for updateTItle correctly
* Bring the transclusion title message back
Bug: 64671
Change-Id: I3beb8b1d4304ba73c428868b9ac2d0f6a1cc9944
When MWReferenceDialog was modified to inherit from ActionDialog the
search select method didn't get changed to call applyChanges. But really,
you can't just call applyChanges because you need all the promise setup
stuff that onApplyButtonClick does. The API for ActionDialog needs to be
improved, but this works just fine in the mean time.
Bug: 64677
Change-Id: Ib38a624811dc26ead7b9de64cb41aff642820452
Update VE core submodule to master (109a3cf):
* 109a3cf ve.ce.Surface: Remove font-size: 1em;
Follows-up I5818dce6265.
* When applied to ve-ui-surface, it applies to both of its children,
namely ve-ce-surface and ve-ui-surface-overlay. The latter
(containing things like context menu and inspectors) should not
inherit styles intended for rendering of wikipage content by
the skin.
* Move mw-content-{ltr,rtl} from an outer parent to a slightly
deeper parent of the actual content. It's now on documentNode.
Still high enough to apply to all content. This was to ensure
it remains a child of mw-body-content, like in MediaWiki core.
* Updated padding/margin hack again. Since now the font-size
applies on the surface, this once again means that now 1em
on the surface != 1em on the documentNode, so we need the
calculation again. Brought it back and this time documented
what it is based on.
Bug: 64599
Change-Id: I9ee4582a6a0ec9e128f5c36a6dbf2adbd0b216a1
Also get rid of checking for NS_MEDIAWIKI explictly and use
MWNamespace::getRestrictionLevels instead
Bug: 50783
Change-Id: I5986ddb9b6f17e4a2aca12dbb551cce4a6cfd663
