MediaWiki talk:Common.js/Archive 21

Archive 15

←

Archive 19

Archive 20

Archive 21

Archive 22

Archive 23

Protected edit request on 28 February 2014

Hi again!

Could someone make this update too? Helder.wiki 21:59, 28 February 2014 (UTC)

Done. — Edokter (talk) — 23:00, 28 February 2014 (UTC)

Protected edit request on 28 February 2014

Hi!

Could someone implement a fix for the problem which causes "Uncaught TypeError: Cannot call method 'addMessages' of undefined"? This was reported in 2012... Helder.wiki 21:50, 28 February 2014 (UTC)

From jQuery docs for $.getScript(): "The callback is fired once the script has been loaded but not necessarily executed." In other word, it is no different then using importScript. Has this been tested? — Edokter (talk) — 23:12, 28 February 2014 (UTC)

I'm not sure I understand: if importScript is asynchronous, what guarantee do we have that a line of code put after it will be executed only after the script is loaded?

Anyway, $.getScript() is in use on pt:MediaWiki:Gadget-refToolbar.js since 2012 with no problems so far. Helder.wiki 15:53, 1 March 2014 (UTC)

Both methods are asynchronous, which is why I would like a code reviews first. — Edokter (talk) — 16:02, 1 March 2014 (UTC)

@Krinkle, Matma Rex, and TheDJ: ^. Helder.wiki 16:31, 3 March 2014 (UTC)

@Edokter and Helder.wiki: importScript is definitely always asynchronous and has no callback, so it is definitely a bad choice here. The situation with $.getScript's callback is rather complicated at a glance and I really don't feel like digging through hundreds of lines of code right now to find out what exactly happens (Krinkle knows jQuery internals better than I do), but it is also definitely better here than importScript since it has at least some chance of firing only after the script was executed :)

The proper way to solve this, of course, would be to convert these scripts to default-enabled gadgets which will let you sanely specify dependencies between them and other modules. Matma Rex talk 19:03, 3 March 2014 (UTC)

Protected edit request on 15 March 2014

Could someone apply these changes to MediaWiki:Common.js/watchlist.js to stop the warnings on Special:Watchlist:

Helder.wiki 13:28, 15 March 2014 (UTC)

Done. — Edokter (talk) — 14:40, 15 March 2014 (UTC)

CodeEditor Feedback desired

Please read and give your input about what you are looking for in the CodeEditor toolbar —TheDJ (talk • contribs) 00:14, 26 March 2014 (UTC)

Protected edit request on 14 March 2014

Could someone apply some changes to the "Collapsible tables" code to make it more similar to the version which is currently on mediawiki.org? This will make it easier for us to keep these two copies, and the other forks (more or less) synced. I made a related suggestion at mw:MediaWiki talk:Gadget-collapsibleTables.js#Update, to add some updates which were made on English Wikipedia but are not on mw.org yet. This new version deprecates the global window.collapseTable. I tested the code on testwiki:Sandbox, and it works exactly as it does on Help:Collapsing. Helder.wiki 14:49, 14 March 2014 (UTC)

Needs some cleanup; tabs and spaces for indenting are mixed all over the place. Did you mean "which is on test.wikipedia.org", seeing request on mediawiki.org is still pending? Also, how about throwing the whole thing away and finally start using mw-collapsible instead? — Edokter (talk) — 15:09, 14 March 2014 (UTC)

I clarified the text above. As for the indentation, I suggest making an edit to MediaWiki:Common.js to replace spaces by tabs, since this is what CodeEditor uses.

About the migration to mw-collapsible, I think we should really do that as soon as possible, and stop sending more this code to our readers, because MW already sends jQuery Collapsible plugin by default and that won't be changed. I suggested something like that before, but so far most templates are still using this old script. Previous topics on this issue:

• August 2011: WP:Village pump (technical)/Archive 92#Deprecation of Collapsible tables and NavFrames
• August 2011: MediaWiki talk:Common.css/Archive 14#Add selectors for mediawiki collapsible plugin
• March 2012: MediaWiki talk:Common.js/Archive 20#Do not create NavFrame buttons if the new class "mw-collapsible" is used)

Helder.wiki 15:33, 14 March 2014 (UTC)

Question: Couldn't it be set to be an independent script on mediawiki.org or meta and then just loader loaded on all other wikis? This would then allow all of the updates to that code to happen in one place all at once instead of having to bounce around all of the various wikis trying to get forks updated. — {{U|Technical 13}} ^{(t • e • c)} 15:29, 14 March 2014 (UTC)

Yep, at the cost of one (or two, if the CSS is in a separated page) extra HTTP requests. Helder.wiki 15:33, 14 March 2014 (UTC)

Question: Helder, would the 0.15-0.7 extra second for these one or two extra requests be that big of a deal? Either way Mr. S, I do not oppose this changes as the JavaScript looks sound to me. — {{U|Technical 13}} ^{(t • e • c)} 14:41, 30 March 2014 (UTC)

I'm not sure why I'm being pinged here. I'd prefer to leave this request to someone who can actually check the code. — Mr. Stradivarius ^{♪ talk ♪} 15:00, 30 March 2014 (UTC)

Not for me. Helder.wiki 15:56, 30 March 2014 (UTC)

Code updated, but removed the deprecation log; it would load at every page load. — Edokter (talk) — 16:31, 30 March 2014 (UTC)

Edokter, actually the warnings would only be loaded in the console if the user's scripts (or gadgets) are calling the deprecated global collapseTable. Otherwise, there will be no warning. This is the expected behavior. Helder.wiki 19:13, 30 March 2014 (UTC)

Oh well, my bad. Anyway, we all know it's there. — Edokter (talk) — 19:21, 30 March 2014 (UTC)

The point is to warn anyone who are still relying on this that it will be removed from the window object at some point. This would just remind people to fix their scripts. Helder.wiki 19:30, 30 March 2014 (UTC)

Meaning it will be removed here? What would be the best way to switch over anyway? Is there a way to map all classes and function to mw-collapsible? — Edokter (talk) — 19:54, 30 March 2014 (UTC)

Protected edit request on 7 April 2014

Could someone apply these changes to MediaWiki:Common.js/edit.js? Whithout it, users who disable the toolbar are still downloading the code of the refToolbar. Helder.wiki 23:14, 7 April 2014 (UTC)

That diff is a mess! I gather the only change is:

if( !mw.user.options.get( 'showtoolbar' ) || window.refToolbarInstalled || $( '#wpTextbox1[readonly]' ).length ){
	return;
}

Correct? — Edokter (talk) — 23:32, 7 April 2014 (UTC)

Yes, sorry. The diff was clearer using the gadget wikEdDiff or Meld, but this is what I changed:

• I replaced the wrapping "if( cond ){ ... }" by an earlier "if( !cond ){ return; } ..." (this caused most of the indentation changes which confuses MW diff engine)
• I added the test !mw.user.options.get( 'showtoolbar' )
• window.refToolbarInstalled === undefined was replaced by window.refToolbarInstalled
• $( '#wpTextbox1[readonly]' ).length === 0 was replaced by $( '#wpTextbox1[readonly]' ).length

Helder.wiki 23:51, 7 April 2014 (UTC)

Done. — Edokter (talk) — 00:51, 8 April 2014 (UTC)

Helder.wiki, see Wikipedia:Village pump (technical)/Archive 125#Cite menu on toolbar missing!. If this edit changes the behaviour of the toolbar preferences, it should be reverted. Can you investigate? — Edokter (talk) — 11:43, 8 April 2014 (UTC)

Edokter, hmm... It seems this loader is using mw.user.options without declaring it depends on module "user.options" (but it was already doing that before my changes). You can try to change

$( initializeRefTools );

to

mw.loader.using( 'user.options', function () { $( initializeRefTools ); } );

to make sure this is loaded (the gadget version will have this dependency declared in its definition). The other alternative would be to create the loader gadget we are discussing in the section above. Helder.wiki 12:55, 8 April 2014 (UTC)

Never mind. According to TheDJ, it is actually behaving correctly now. Seems the reftoolbar was loading even with Enhanced Toolbar disabled in the preferences, which is now fixed. (PS. I think user.options is loaded by default, so no dependency needed.) — Edokter (talk) — 12:59, 8 April 2014 (UTC)

I believe indicating the dependencies explicitly is better than making assumptions on the loading order of the modules, and then having to investigate/fix bugs in the future because of some MW update which changed our assumptions... (but yeh, Krinkle commented in a patch sometime ago that this module in particular is loaded before other modules)

If this is not broken now, we could simply postpone this to when we define the new gadget. Helder.wiki 13:11, 8 April 2014 (UTC)

BTW: I requested more docs about modules loaded by default on bugzilla:63674. Helder.wiki 13:22, 8 April 2014 (UTC)

That's what I meant; mw.user is a core module, just like mw.config. But yes, I would love a list of modules that do not need to be listed as dependencies. — Edokter (talk) — 13:50, 8 April 2014 (UTC)

Edokter: That sentence ("mw.user is a core module, just like mw.config") sounds rather wrong and is result of confusion in a few different ways. Let me clarify. There's three things at play:

• The mediawiki base module ("mediawiki"). This one can't be declared as dependency (and doesn't have to be) because it is the base module that actually defines mw.loader itself. If memory serves, it currently defines mw.Map, mw.config, mw.messages, mw.Message, mw.loader, mw.html, mw.hook and a few miscellaneous methods. None of these have their own module (it's not that you can't or shouldn't depend on it, they simply don't exist as a module, e.g. there is no such module as mediawiki.config or mediawiki.html, it would throw "Unknown dependency" if you try).

  Let me also note that the jquery module behaves in the same way. These two are the only ones you shouldn't (and even mustn't) explicitly specify as dependencies. Matma Rex talk 18:22, 9 April 2014 (UTC)

• Page modules: There are various modules that are loaded by default on a page (either because the Skin needs it, or because we use it for enhancing page content, or because an extension added it to the load queue etc.). This usually includes mediawiki.user, mediawiki.legacy.wikibits and others. Though these are loaded by default, they absolutely must not be assumed as being available at all times. If you use mw.user, you *have* to declare that dependency. Two reasons for this:
  1) The default list can change (either in general or for some pages). There is nothing that says they will always be loaded, they are loaded because some part of the application uses them (just like your preferences panel will add a gadget if you tell it to, and if that gadget is on every page and loads mw.Title then that module will be on every page, but that's just a coincidence). They are not part of the "this is always available, use freely" and never have been.
  2) While they are loaded by default, even now things load in parallel (this is by design). If you want your code to execute after "mediawiki.user" has finished loading, you have to indicate this through a dependency or else there will be race conditions where mw.user is still undefined and your code will fail.
• Globally embedded page modules. These modules (such as "user.options") are embedded within the page for security and/or performance reasons. Since they execute synchronously and are embedded before any load queue, these not only load by default but also "finish" loading before any module, gadget or otherwise starts loading. Which means technically you can get away with not specifying user.options as a dependency because it's impossible for them not to be there. However, once again, do not rely on the arbitrary implementation detail that this particular module is being embedded right now.

In short: Just declare all your direct module dependencies (either inline with loader.using or with gadget[dependencies=]) and let ResourceLoader do its job. Krinkle (talk) 17:53, 9 April 2014 (UTC)

I copied this reply to Template:Bug, awesome. Matma Rex talk 18:22, 9 April 2014 (UTC)

Krinkle In short... confusion galore. The naming conventions doesn't help. I thought user.options was part of mw.user (confusion nr.1) and mw.user was stated to be part of mw.map, but not anymore (since today, confucion nr.2). Lastly, there are the base module and page modules, both starting with mediawiki. (or .mw?), which creates more confusion. For instance, I do not need to declare mw.config, but I do need to declare mw.util! That is why we want a simple list of which of these mediawiki. modules are part of the base module and should not be declared. Then I can happily declare everything else. — Edokter (talk) — 21:46, 9 April 2014 (UTC)