* Instead of inline global variable and lazy-loading, using ResourceLoader (using mw.config and mw.loader)
* Can't use OutputPage::addJsConfigVars / OutputPage::addModules because debug is called after those are handled, using ResourceLoader::makeConfigSetScript instead
* Previously $(document).ready(mw.util.init) was in module 'mediawiki.page.ready' (position: bottom). I've now moved this to 'mediawiki.page.startup' so that it'll be enqueued sooner.
* This making it more likely that if someone also enqueues in document-ready that mw.util.init ran before than and thus mw.util.$content populated
* Fixes bug 33711
* All this is still depends on the order in which the event handler queue is executed, which is risky. Bug 30713 will bring the solid "watertight" solution
* Introduces $wgPreloadJavaScriptMwUtil
* Instead of loading mediawiki.util as base module from the bottom, now loading it from queue position "top" if $wgPreloadJavaScriptMwUtil is true. And if false it'll remain in the bottom in practice as implied by other modules loading it as a dependency (i.e. mediawiki.page.ready depends on it)
* Fixes bug 33746
* The global object created by this legacy module is references from inline on-event attributes as well as from inline <script>'s by ProtectionForm.php
* Needs to be loaded before any of that happens
* Fixes bug 33660
* mediawiki.action.watch.ajax:
-- Depends on mediawiki.api.watch>mediawiki.api>mediawiki.util
-- But also uses mw.util itself, so adding it here as well. mw.Api might one day not use mw.util
* mediawiki.special.block: Uses mw.util.isIPv4Address / mw.util.isIPv6Address
* mediawiki.special.changeemail: Uses mw.util.validateEmail
* mediawiki.legacy.upload: Uses mw.util.wikiScript
* Uses mw.util.wikiUrlencode
Commit is inspired by and a superset of the patch provided by Rainer@Rillke.eu at bug 33760.
* Previously mw.log and mw.Debug both were in a fixed container on the bottom, overlapping each other. mw.log did increase the body's padding-bottom to account for the height so that all content is still visible, but it was still a problem when mw.Debug came along.
* This plugin adds a single fixed position element to bottom of the body, to which other stuff like mw.log and mw.Debug can append a non-fixed position container. That will take care of it.
* Method update() will re-check the padding and scroll position and fix where needed
* Reduces code a little bit
Changed written by Timo and reviewed by Hashar. This should be harmless.
To enable the feature:
$wgEnableJavaScriptTest = true;
Then head to:
[[Special:JavaScriptTest/qunit]]
* mw.config is the new way, and global config variable lookups are deprecated
* Based on two phase3-wide quick searches:
-- of " wg": http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=321&hash=81700bf7486e4fee3b7bc1f83eb9eba6
-- of "!wg": http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=327&hash=47c9d54a7a1d5d58a724dd834585f40d
Related changes:
* Changed some php comments mentioning "wg" variables to include the dollar sign, and a typo when the wf function prefix was meant.
* Removed TODO comment in wikibits.js and made it use the JS equivalent of wfUrlencode, which we have now, mw.util.wikiUrlencode
* SpecialUpload.php: use OutputPage::addJsConfigVars instead of creating a new script tag through OutputPage::addScript(Skin::makeVariablesScript(..))
* Renamed wgUploadSetup in upload.js and made it local. Not used anywhere in ./trunk/phase3 and ./trunk/extensions
* Fix OutputPage::addJsConfigVars so that it can actually be called with an array instead of two arguments for key/value
* Some minor whitespace/convention stuff around the same line
* add mediawiki.api.watch module
* mediawiki.api.parse.js: remove 'data && ' check to match the other modules. If data is not good, then the internal error handler will have already handled it and never call the ok-callback in the first place.
* mw.Api.errors: adding error codes by ApiWatch.php
* fix on-the-loose fixalpha() call
-- Calls should not be dangling loose like that
-- Removed local calls from skins and installer
-- instead calling from the IEFixes script (which is loaded raw by wikibits which is loaded from the bottom, as are all legacy scripts)
* Removing usage of 'skinpath' and 'skin' globals in wikibits.js, those aren't globals per se since introduction of mw.config and $wgLegacyJavaScriptGlobals
* Wrapping wikibits.js in closure to avoid leakage of "local" variables. This shouldn't break anything as it is loaded through resource loader which, in production mode, wraps it in a closure anyway.
* adding explicit posision=>bottom for wikibits. 'bottom' is default but repeating here since it must not change for legacy reasons.
Use this classname to raise the specificity of the sortHeader, so that it is more difficult to accidently override with local css. Followup to r98069
Move the css into a seperate file and move the images for it to the jquery directory.
- Stop hiding with display: none;, this hides our jump links from modern screen readers and users with motor disabilities (ie: nowadays, pratically everyone they are intended to help).
- Instead hide with an overflow that will make the links viable <tab> targets. This alone is enough to help screen reader users.
- Add in a script that will show the jump-links area on-focus for motor-impared users who can still see who have js enabled (this can't be done with css unfortunately)
* Move js/css/images from core into extension dir (kept svn history in tact)
* Removed from core:
** Messages
** Resource definition
** Default settings
* Recreated in extension:
** Messages with 'inlinecategorizer' prefix (instead of generic 'ajax' prefix).
** wgResourceModule definition
** Hooks for adding module to the page
** Setting wgAJAXCategoriesNamespaces kept (renamed to $wgInlineCategorizerNamespaces)
* Made minor adjustments to the messages:
** Fixed references to other messages (in /qqq) with the new message key
* Made minor adjustments to the javascript:
** Usage of mw.msg fixed to the new message keys
** Removed "@since 1.19"
** Removed "Relies on mw.user.getId" (because it didn't', and still doesn't)
** Object 'mw.ajaxCategories' -> 'mw.InlineCategorizer' (capitalized, since it's a constructor, per our conventions)
** Removed 'disableAJAXCategories' config, not needed.
Summary of justification for move out of core (again):
* Too many issues with the parsing logic (many cases still don't work yet)
* Almost untested and untestable because of mixing UI with logic code. Needs separation.
* See http://www.mediawiki.org/wiki/User:Krinkle/Extension_review/InlineCategorizer#Prequel
One day we might move it in, or if the "new parser" is ready and the "visual editor" we might not need it all together and it'd simply be a 10-20 line module in the visual editor (that, or it'd be part of the visual editor by default).
Anyway, I'm not against this module. if we can get this to an acceptable state soonish before any of the new parser / visual editor is ready, then I see no problem in bundling it with core and/or merging it into core.
* Html-escaping unescaped message in summaryHolder
* Check for errors in the API response
* Pass true for existence of redirect origin and value of 'exists' for target (instead of backwards)
* Comment fixes
* Renaming mw.uri to mw.Uri (since it's a constructor)
* Leaked global variable 'g' in _parse() fixed
* Removing unused local variable '_this' in getQueryString()
* Fix documentation (jQuery 'setAttr' should be 'attar')
* Making non-private variables with '@private' comment, private (or "local").
* Using strict undefined comparison (shorter and faster, [[JSPERF]])
* Moving Resources definition from MediaWiki Page section to MediaWiki main section (to reflect directory structure)
* Coding style conventions (mixed spaces and tabs, line wrapping, double/single quotes)
* Remove passing mediaWiki to mw argument (mw is a global alias)
* Passes JSHint
* Removing 404 errors from UploadWizard/test/jasmine/SpecRunner.html
(Follows-up r93781 's move)
* Originally they were a few prototypes on the native String object, however they were converted to be (static) members extending the jQuery object. Calling them prototypes is confusing. A grep search on /trunk/ didn't reveal any direct uses of this module (it's loaded by default through mediawiki.util's dependencies)
- Fixes (bug 27894) Move 'editondblclick' event listener down from body to
div#bodyContent
- Patch by Nik <niknyby@gmail.com>
- Changes since patch:
* Moved from OutputPage->headElement (where the bodyAttr-hack used to be) to addDefaultModules where other additions live
* Added dependency on 'mediawiki.util', it must be initialized before mw.util.$content can be used
* Whitespace conventions
* More natural messages
* Respect wgCaseSensitiveNamespaces
* Regex: Add possible whitespace between "[[Category:" and the category name. ( [[Category: Foo]] )
* Make nearly all functions publicly accessible
* Add "cancel all" button
* Submit on enter keypress
* Check for redirects
* Color links correctly based on existance of category page
* Add a summary of the changes done into the edit summary ('+Category:foo, -Category:Bar: Foo is not correct...')
* Add more error handlers
* Add more hooks ( afterChange/Delete/add ).
* Pass category names to the hooks
* Allow hooks to abort by returning false
* Handle sortkey correctly in all operations
* Move addCategory form below categories.
* Fix any known IE6 and IE7 bugs.
* Add more documentation
* Partial revert of r92264. mw.ajaxCategories has nothing to do with mediawiki.util.init, moved into separate initiation module, only loaded when ajax categories is enabled.
* Removing instantiation from the script. mw.ajaxCategories is now a public accessible constructor
* Fix Uncaught ReferenceError: wgUserGroups is not defined
($wgLegacyJavaScriptGlobals = false;)
* Renamimng stripIllegals() to clean(), adding '#' to the regex as those are not allowed either.
* Combining var statements by separating them with comma's ( var foo, bar, baz; ) instead of "var foo; var bar; var baz;"svn up
* Using dot.notation for objects instead of array-like['string'] keys
* Whitespace conventions
* Using inArray utility instead of indexOf (cross-browser support, mostly IE6)
** $.inArray uses Array.prototype.indexOf if available, otherwise fallback to a loop. mw.util.inArray is a wrapper around $.inArray to return a boolean value (since inArray/indexOf may return 0)
* Don't use $( '#bodyContent' ) (skin specific) but mw.util.$content
* Using mw.Title
* Re-using helper functions from the outer-closure instead of re-declaring them privately for every instance again (performance!)
Follows-up: r92112, r92151, r92264
- A cross-browser compatible way of getting a direct key/value object of attributes
- Will help making comparisons such as in r92113 easier and work cross-browser
* Split the byte length logic into a seperate method to allow it to be called directly on a string (easier to test and easier re-use)
* Added basic unit tests for it.
- Partial self-revert of r90982 (binding and triggering must not be chained, as the calling function refers to the variable we're setting)
- The Qunit tests pass now :)
Follows up: r90943 r90960 r90968 r90980 r90982
* based on an idea by Aaron on r90866
* comes with QUnit test
* expect the special 'all' namespace to be the first in the list
* function build on mediawiki.special form r90941
First step towards cleaning up mw.util.init and removing bugus dependancies on mediawiki.util which are just added there in order to load them on every page and do something on-load.
Introducing mediawiki.page.startup (in the head) and mediawiki.page.ready (on the bottom)
Moved the following to them:
* document.ready from jquery.cient
-- Shouldn't have been in the plugin itself in the first place
* jquery.placeholder
* jquery.makeCollapsible
* mediawiki.action.view.tablesorting
* jquery.checkboxShiftClick
(This also solves part of bug 26799)
* Based on UploadWizard/resources/mw.Title.js
* Refactored to use local scope and prototypes instead of re-declaring them per-instance in the private scope through 'this' (re-use by reference, faster instantiation and performance)
* Fix potential ReferenceError in the check for wgArticlePath (inline if statements will fail for undeclared variables, needs typeof undefined check). Using mw.config instead to avoid this problem.
* The following two methods were not ported from UploadWizard because they were or became redundant and/or merged with another method:
-- setNameText (redundant with the improved setName)
-- setPrefix (redundant wit the improved setNamespace)
* Ported all jasmine tests to QUnit. Left them exactly the same to make sure it's compatible with UploadWizard. Perhaps I'll expand or adjust the suite later to be less file-specific, but for now make letting this revision go through TestSwarm to be sure it's compatible and behaves exactly the same.
* Added getName() method instead, replacing direct access to '_name' This in order to check for wgCaseSensitiveNamespaces (bug 29441; r90234)
-- Prevents breakages on wiktionary and other wikis with case sensitivity. ie. on a Wiktionary:
new mw.Title('apple').toString()
> "Apple"
-- This fix will make it return 'apple' instead of 'Apple' (that is, if 0 is in wgCaseSensitiveNamespaces).
* There used to be a strip-bug in scenarios where a namespace-like string appears inside of a title. Imagine pagename: "Category:Wikipedia:Foo bar" (exist on several wikis; NS_CATEGORY= 14)
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
> "Category:Foo_bar" // Stripped "Wikipedia:" !!
In order to fix this:
-- Removed assumption that every title has a namespace prefix. UploadWizard/mw.Title has one initialization RegExp (which was ported as-is to "setAll"). In addition there is now a "setNameAndExtension" method (which doesn't extract or set the namespace). Now the above case:
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
> "Category:Wikipedia_Foo_bar" // Better, but now the colon is gone..
-- In order to fix that, "\x3a" was removed from the clean() function. Colons are valid in MediaWiki titles, no need to escape.
new mw.Title( 'Wikipedia:Foo bar', 14 ).toString()
> "Category:Wikipedia:Foo_bar" // Yay!
* Last but not least, another little bug fixed due to the previous point. It also fixed a thrown exception in case a colon is part of the title in the main namespace (not rare for movies and books):
new mw.Title( 'The Wiki: Awesomeness')
> Error: mw.Title> Unrecognized canonical namespace: the_wiki
This exception is thrown from setNamespace(). That exception would make sense if setNamespace() was called by the user direcly, but when called from setAll() it should gracefully fallback by putting the prefix in the name instead and assuming NS_MAIN (just like the server side does). To achieve this I added a try/catch around setAll() and fallback to the new setNameAndExtension().
* Passes JSHint.
* Additional feature: exists(). Return true/false if known, otherwise null. Extensions can populate this for titles they are interested in and the front-end can construct url's and UI elements with correct redlink-status. Gadgets can populate it as well but that would require an API-request to get the information. A bit of a stub for later use, although I think it works fine.
* Bugfix in jquery.qunit.completenessTest.js (first triggered by the introduction of mw.Title). Don't traverse the 'constructor' property (recursive loop, ouch!)
---
(bug 29397) Implement mw.Title module in core
* Reverts/re-do's r88794 and r88796.
** mediawiki.util.js no longer extends itself but is defined once.
** mediawiki.util.jpegmeta no longer extends mw.util but is installed as an object property of mw.libs
* Empty placeholder defined in mediawiki.js
* Removed the redundant 'mw' argument from the IIFE around mediawiki.libs.jpegmeta.js
* Fixed all usages in /mediawiki/trunk/*
** http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=205&hash=ddc0908eef111558816c9fe1c775f7c1
* Adding error capturing in case there is an error (either in the API or with the request itself). Right now if it fails it just keeps reading "Watching..." and no error is displayed.
This lack became visible when r88522 changed ApiWatch to require a token and POST.
* Added message 'watcherrortext'.
* Moved messages-array in Resources.php form legacy.ajax to action.watch.ajax (looks like this was forgotten in r78147)
* Switched it to make a POST request in preparation of making it work with the changed API backend as of r88522.
