Goes along with MobileFrontend changes: https://gerrit.wikimedia.org/r/28434
Adds 'targets' option to module definitions, defaulting to 'desktop'.
Only a couple more modules are whitelisted into both desktop and mobile for now.
Startup module takes a 'target' parameter (defaults to 'desktop') to filter
the resource module registration list. Only modules matching the filter get
registered, and thus will be loadable from client-side RL.
Change-Id: Ifb772d4995b8e2ec4b63776fe0bb5b0214f82e04
Added jquery.delayedBind as dependency for jquery.collapsibleTabs
as it's used on line 29.
This wasn't causing errors (at least I'm not aware of it causing errors),
but still it's better to have all dependencies declared.
Change-Id: Iaff2ee952822d1be9a91fc7b8634a63ac61f8252
* adds $wgResponsiveImages setting, defaulting to true, to enable the feature
* adds 'srcset' attribute with 1.5x and 2x URLs to image links and image thumbs
* adds jquery.hidpi plugin to check pixel density and implement partial 'srcset' polyfill
** $.devicePixelRatio() returns window.devicePixelRatio, with compat fallback for IE 10
** $().hidpi() performs a 'srcset' polyfill for browsers with no native 'srcset' support
* adds mediawiki.hidpi RL script to trigger hidpi loads after main images load
Note that this is a work in progress. There will be places where this doesn't yet work which output their imgs differently. If moving from a low to high-DPI screen on a MacBook Pro Retina display, you won't see images load until you reload.
Confirmed basic images and thumbs in wikitext appear to work in Safari 6, Chrome 21, Firefox 18 nightly on MacBook Pro Retina display, and IE 10 in Windows 8 at 150% zoom, 200% zoom, and 140% and 180%-ratio Metro tablet sizes.
Internally this is still a bit of a hack; Linker::makeImageLink and Linker::makeThumbLink explicitly ask for 1.5x and 2x scaled versions and insert their URLs, if different, into the original thumbnail object which (in default handler) outputs the srcset. This means that a number of places that handle images differently won't see the higher-resolution versions, such as <gallery> and the large thumbnail on the File: description page.
At some point we may wish to redo some of how the MediaHandler stuff works so that requesting a single thumbnail automatically produces the extra sizes in all circumstances. We might also consider outputting a 'srcset' or multiple src sizes in 'imageinfo' API requests, which would make ApiForeignRepo/InstantCommons more efficient. (Currently it has to make three requests for each image to get the three sizes.)
Change-Id: Id80ebd07a1a9f401a2c2bfeb21aae987e5aa863b
The module has been broken for a while now, but nobody noticed
because in plain core it is disabled by default, and in the
bundle we ship with Extension:Vector (and its SimpleSearch).
This commit removed the mediawiki.legacy.mwsuggest module (and
related components that become obsolete with its deletion) and
replaces it with the new mediawiki.searchSuggest module, which is
based on SimpleSearch from Extension:Vector (where it will be
removed soon).
The following and all references to it in core have been removed,
I also made sure that they weren't used in any of extensions/*.
Only matches in extensions/Settings and some file that dumped the startup module, and in extensions/Vector which are addressed in
I1d5bf81a8a0266c51c99d41eefacc0f4b3ae4b76.
Had to make a few updates to jquery.suggestions to make it work
in other skins. So far it was only used in Vector, but now that
it is used in mediawiki.searchSuggest, I noticed several issues
in other skins. Most importantly the fact that it assumed the
default offset was from the right corner, which isn't the case in
Monobook where the search bar is on the left (in the sidebar).
It now detects the appropiate origin corner automatically, and
also takes directionality of the page into account.
It also uses the correct font-size automatically. Previously it
used font-size: 0.8; but that only works in Vector. Every skin
seems to have its own way of making a sane font-size. In Monobook
the <body> has an extra small font-size which is then fixed in
div#globalWrapper, and in Vector it is extra large, which is then
fixed as well deeper in the document. Either way, the size on
<body> can't be used, and since this suggestions box is appended
to the <body> (it is a generic jQuery plugin without knowledge of
the document, and even if we could give it knowledge inside
the configuration, it'd have to be per-skin). So I removed the
Vector specific font-size and let it handle it automatically.
This was needed because it is now used in all skins.
Removed modules:
* mediawiki.legacy.mwsuggest:
> Replaced with mediawiki.searchSuggest.
Removed messages:
* search-mwsuggest-enabled
* search-mwsuggest-disabled
> No longer used.
Removed mw.config.values:
* wgMWSuggestTemplate
> Obsolete.
* wgSearchNamespaces
> Obsolete.
Removed server-side settings:
* $wgEnableMWSuggest
> Suggestions are now enabled by default and can be disabled
through the user preference `disablesuggest` still.
They can be disabled by default site-wide or hidden from
prefs through the standard mechanisms for that.
* $wgMWSuggestTemplate
> Obsolete.
Removed methods
* SearchEngine::getMWSuggestTemplate()
> Obsolete.
Filters:
$ ack mwsuggest -i -Q --ignore-dir=languages/messages
$ ack wgSearchNamespaces -Q
Message changes:
* vector-simplesearch-preference
> It was wrong, it didn't activate search suggestions, that
was handled by the Vector extension. This preference in
MediaWiki core controls whether the SimpleSearch bar HTML
and CSS will be used (e.g. the rectangle search box with
the magnifying class instead of the browser-default input
field with the plain submit buttons).
* searchsuggest-search
* searchsuggest-containing
These come from Extension:Vector message and should be imported
by translatewiki:
- vector-simplesearch-search
- vector-simplesearch-containing
Change-Id: Icd721011b40bb8d2c20aefa8b359a3e45413a07f
With all the recent improvements, it's time this module got
promoted away from legacy. Its no longer just an old script to
that provides preview functionality and is minimally
maintained within "legacy", its reborn!
Minor clean up follows-up:
* e75054174c
* b12dc64a11
Change-Id: I85ca97a1d8df25a09baad78030d6da379a06c0f1
* "mediawiki.user" depends on "user.options" and "user.tokens"
* "mediawiki.action.view.dblClickEdit" depends on "mediawiki.page.startup"
Change-Id: I5ef5e4ab68ff1a472d2aebcea474e3fd76e510fe
We have a data driven plural rule evaluation system in core now.
See I1aa3b081
Added more tests
(This was I4451fc7d and reverted because javascript references
were not removed from Resources.php)
Change-Id: I57c3c238c0717664384da50aa2cbfa74369d7a55
Notes:
* JSHint stuff
* Code conventions
* jQuery best practices
* mediawiki.debug:
- Append a text node instead of html. Though .append()
does check if it looks "like" not-html and creates a text
node, this is not more a sanity/security thing than a
reliable documented feature. http://api.jquery.com/append/ :
"HTML string, DOM element(s) or jQuery object".
While at it:
* Update .jshintignore to also cover:
- resources/mediawiki.libs/CLDRPluralRuleParser.js
* Update .jshintrc to set onevar back to true (was set to false
temporarily but not removed).
* Fix files in resources/mediawiki and resources/jquery as well.
These dirs where already covered, perhaps these were missed or
recently introduced, again.
* Add missing dependencies:
jquery.highlightText -> jquery.mwExtension ($.escapeRE)
jquery.tablesorter -> jquery.mwExtension ($.escapeRE)
mediawiki.page.watch.ajax -> jquery.mwExtension ($.escapeRE)
Change-Id: I30a55717d0963ce23e51cef1f1df9e549e4c232e
- Support for multiple messages instead of just one is included.
- Persistent messages are also supported.
- Tagged message replacement is supported so that only one message of a type will show up at once.
- A light flood protection is included to stop all the notifications from disappearing at once.
- Watchlist uses it's own tag now.
- Legacy jsMessage messages still replace each other by using a tag: 'legacy' option
- #mw-js-message was an old id used for something with a completely different style. So rather than re-using it that id is being dropped. Skins can now style the new notifications.
- Core is no longer using messageBox and no extension uses it so instead of making a compatibility layer for it that module is just being dropped.
This is a follow up to I41c70d78.
Change-Id: I2b3d9cbce6d1514d754b4403ec878d89ea6af29d
Adding jStorage from http://www.jstorage.info/ to MediaWiki
It's MIT-style licensed and useful for local caching of data.
Adding to .jshintignore since it is a third party library.
Change-Id: I2343744304191d5846cf346e4ac6ca083a6414b3
The JavaScript code of the parser was written by Santhosh.
The original project is hosted at GitHub:
https://github.com/santhoshtr/CLDRPluralRuleParser
Introduces resourceloader modules: mediawiki.cldr and
mediawiki.libs.pluralruleparser.
hi.js and ar.js removed since it has only convertPlural method. More [lang].js
needs to remove convertPlural, but not done in this commit.
The actual rules will be taken straight from CLDR and they are not
integrated in this commit yet.
Change-Id: I1aa3b081f4dad68515fd6cd46e4ab2dbdb3291eb
* Also deprecate name() and anonymous()
in favour of getName() and isAnon() (to match User.php), just
like getRights and getGroups are now as well.
* Added unit tests for all.
Change-Id: I5970be9e8593589018152f4878f168b9b85ca5d5
Doesn't properly work on Special:EditWatchlist, some of the titles being unwatched are not fading out and staying behind.
There's also a small code quality issue unaddressed. Please re-submit for further review.
This reverts commit b46ec8fde5
This patch makes the watchlist editor to use pagination. That would
avoid old browsers crashing (bug 20483).
Patch also add some AJAX operations to the editor, for example to remove
items from watchlist (bug 32151).
The AJAX support is an ALTERNATIVE to the form based method, to keep
support for non javascript users.
This change contains a required change in the API for watch operation,
to allow batch operation, by support titles parameter. The old title
(single page) parameter is still used to keep backward compatibility.
Change-Id: I1d8c66db9ba6456858ef655397935a2b3a421632
* Several methods were added here recently during 1.20 development
that should not have been public methods.
* Also in the creation of this new module (replacing the old
mwCustomEditButtons) a design flaw was made. Instead of using
a key-value pair object, the signature was changed to a tentacle
function with 7 (for callers, unnamed) arguments.
* Changed it back with the compatibility fix the other way around.
So everything is backwards compatible.
* Moved to local scope:
- buttons queue
- $toolbar
- insertButton
These were recently introduced during 1.20 development but not
meant to be public. When used too early or too late from outside
the module it will break or be ignored. For example $toolbar is
false before dom ready, buttons queue is ignored after domready,
insertButton will break if called before dom ready because the
target element doesn't exist yet. These are not bugs, but result
of calling internal methods before they are initialized.
The public API takes care of these state differences by using
the queue and the dom ready handler.
Scripts should (and do) only use the addButton API.
* Kept:
- addButton
- insertTags
- init (empty b/c function, was already there)
* Improved:
- addButton: Now takes an object as well, just like
mwCustomEditButtons used to do.
- Cache Array.prototype.slice instead of re-grabbing from
a new dummy array.
- Store buttons[i] in a local variable in both cases, not just
for legacy. Saves 2 property lookups. Minor gain, but
in this case it was already going to be stored in a local
variable, so might as well do it in the other case.
* Fixes:
- Clear queue array after it has been used. Though in practice
it should never happen that it is iterated over twice, just in
case.
- Added comment to init() function explaining where it is used.
- Updated closure arguments per code conventions.
- Made it a position-top module so that it actually can be used
before the document is ready.
* Example usages tested:
<code>
// Legacy way from wikibits.js:
// Has to be done before document ready
window.mwCustomEditButtons[window.mwCustomEditButtons.length] = {
imageFile: 'http://placehold.it/23x22',
speedTip: 'tool tip',
tagOpen: 'x-',
tagClose: '-y'
};
// mw.toolbar: List of arguments
mw.toolbar.addButton( 'http://placehold.it/23x22', 'tooltip', 'x-', '-y' );
// mw.toolbar: Object
mw.toolbar.addButton({
imageFile: 'http://placehold.it/23x22',
speedTip: 'tool tip',
tagOpen: 'x-',
tagClose: '-y'
});
</code>
Change-Id: Id19819707c937c2c3144ad8177b75baa46f5073c
* Follows-up f47dfe9939, which forgot
to remove the deleted files from the module definition as well.
exception 'MWException' with message 'ResourceLoaderFileModule::readScriptFiles: script file not found: "~/Development/mediawiki/core/resources/mediawiki.language/languages/nl.js"' in ~/Development/mediawiki/core/includes/resourceloader/ResourceLoaderFileModule.php:564
Stack trace:
Change-Id: Ib40d09071ba315da6b17fc94cca5746ed4c26342
method in mw.page.watch. Update method to toggle watch, unwatch
list item id attribute.
Patchset 2- Expose method with less code duplication, restore
comments, cleanup whitespace.
Patchset 3-5 Whitespace cleanup
Patchset 6 - Trigger a watch event on the updated li
Patchset 7 - Only trigger watch event if not updating
state, announce opposite of icon action, to properly
indicate action taken.
Patchset 8 - Cleanup spacing and comments issues,
change event namespace.
Patchset 9 - actually add the change
Change-Id: I591f9f847db391c5d1477dc2ed41de54ec266261
Splitted from https://gerrit.wikimedia.org/r/4554
Grammar rules ported to js based on the php code.
Depends on the javascript Grammar parsing support by jqueryMsg
Change-Id: I701954a623467bf6c9abd3160e239c59cab567e9
* Previously mediawiki.language.data depended on mediawiki.language,
making any module using langauge data having to explicitly define
it as a dependency. This is not good. We should abstract the data
generation part and for the users of the module.
mediawiki.language should take care of having the required data.
* So, reversing the dependency so that mediawiki.language depends on
mediawiki.language.data. Then a simple dependency declaration with
"mediawiki.language" is enough to have associated data available.
This supersedes change set I810fb0a5
Change-Id: Iede836bb3e2fd700cb7c58caeebe9ec2e0043dfb
Apparently iPhone and iPad use 980px width and the new layout doesn't
give enough room to the content area according to Heather.
Patchset 2: adjusting per comment
Change-Id: Ie6b0474f285366d0bfedb6393d1d6f65b55fc604
This patch adds a high definition (HD) style sheet for vector which adjusts
various margin and padding properties to give the page a less crammed-
together feel. All properties transition over 250ms and only activated if
the browser is 900px wide or greater. This size should work well for 1024px
wide screens sans scroll bar, window borders, space around browser, etc.
Change-Id: I85fc70e324b3b93c943efcc827eefdfb3bda7fdf
This add GRAMMAR support to the mediawiki.jqueryMsg module:
1. make jqueryMsg understand GRAMMAR(case insensitive)
2. mw.language get convertGrammar, can be overridden per language as in
php
3. Introduce resourceloader module ResourceLoaderLanguageDataModule
4. Language.php get a method to filter wgGrammerForms for the current
contentLanguage.
5. Qunit tests
6. This code was originally written in jsgrammar branch of svn and had
reviewed during the last slush time.
Change-Id: I90dd0b2f0cb30fd30539896c292829adc4fc7364
* Re-order special modules and add a few comments
* Single quote in QUnitTestResources.php
* Space in ResourceLoader.php
(Separated from another commit while skimming code)
- Fix dependency issue. In practice not an issue due to user.tokens being in the HTML output before the first mw.loader.load()
- Follows-up r107969, r107350
