Jump to content

MediaWiki talk:Common.js

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Edokter (talk | contribs) at 21:15, 13 June 2011 (→‎Kill it?: Bug filed). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Location of Common.js on the file server

Does this file live in the root of the Wiki? AGrobler (talk) 12:09, 13 April 2011 (UTC)[reply]

No. Amalthea 13:01, 13 April 2011 (UTC)[reply]
To be more precise: it lives in the database. — Edokter (talk) — 14:37, 13 April 2011 (UTC)[reply]
Thanks, I'll have a look! AGrobler (talk) 10:55, 12 May 2011 (UTC)[reply]

Small text custom button

The graphic for the Small Text custom button makes no sense. It's the same as the superscript button just with a bigger 'x'. How is that supposed to represent 'small text'? Kaldari (talk) 21:39, 15 April 2011 (UTC)[reply]

Yeah it doesn't represent small at all. Although I suspect most people are using the new toolbar by now, mostly because they are forced to. Personally I'm not using any toolbar at all so I didn't notice this until you mentioned it. I disabled the toolbar a year or two ago, and I don't think there was a small button back then? I assume it was added recently and since it needed an image, someone just modified an existing one. Gary King (talk · scripts) 18:23, 16 April 2011 (UTC)[reply]
Is there really even a need for the small text custom button? We don't have a large text custom button, and I can't think of any cases in which it would be useful for editing wikitext. It seems like cruft to me. Kaldari (talk) 19:44, 16 April 2011 (UTC)[reply]
Where is the page that controls the buttons? Gary King (talk · scripts) 03:58, 17 April 2011 (UTC)[reply]
MediaWiki:Common.js/edit.js Kaldari (talk) 05:37, 17 April 2011 (UTC)[reply]
Small was apparently already in the first revision. Gary King (talk · scripts) 07:26, 17 April 2011 (UTC)[reply]

Map toggle for geolocation in infobox

I have brought this question here after getting a little advice on VPT, [1]. I will repeat the inquiry and then add additonal questions.

On the French wikipedia page fr:Longford and many others using that infobox, there is a map within the infobox which can be toggled via a link beneath it, administrative to topographique. On the French site, I see that the infobox fr:Modèle:Infobox Ville d'Irlande gets the maps from fr:Modèle:Infobox/Géolocalisation multiple, which uses the custom ".img_toogle ul" CSS class.

It has been explained to me that the script lies in fr:MediaWiki:Common.js as * Script pour alterner entre plusieurs cartes de géolocalisation. To continue the discussion, I would first like to say that I think the feature as enabled for maps is very useful, there are also other "before and after" uses for images that I can envision. It seems there is a CSS class that is also required for it to work on the French site; I am not seeing any advantage to my own hit or miss investigation of this and would like to know what editors of the script here have to say about it. Would it be a major change, major pain, etc. to include this functionality? Is there some advantage to adding it instead to the entire MW suite as an extension, as for example mw:Extension:Imagemap was added by Tim Starling? I would prefer not to wait for a full upgrade of the software so I assume this is the place to propose adding toggle of maps to infoboxes via this French method. Please I would like to hear from a few people if possible regarding such an addition of functionality. Thank you, Sswonk (talk) 22:16, 23 April 2011 (UTC)[reply]

This is easy added via js (I doubt an extension is warranted). (As an aside, frwp has some nice custom js/css in general.) I suspect that this js would be quite flexible if adapted for use here—click a link to show something, and click it again to show the original thing. People would go crazy with it on userpages. IMO, it's not a big deal and I wouldn't mind adding this js to enwp if it's not abused, but let's see what the community thinks. /ƒETCHCOMMS/ 19:13, 24 April 2011 (UTC)[reply]

Edit summary dropdown of common summaries, via Javascript

I'm thinking someone watching this page might be able to answer the question I've asked at Wikipedia:Village_pump_(proposals)#Now_what. Anyone? Rd232 talk 23:47, 5 May 2011 (UTC)[reply]

secure.js and Etherpad domains

MediaWiki:Common.js/secure.js needs exemptions for the domains etherpad.wikimedia.org and eiximenis.wikimedia.org. Examples of currently broken links are at [2] and [3].

Regards, HaeB (talk) 22:39, 20 May 2011 (UTC)[reply]

And another one: static.wikipedia.org. (An example of a currently broken link is at [4].) Regards, HaeB (talk) 15:24, 21 May 2011 (UTC)[reply]
done —TheDJ (talk • contribs) 22:16, 3 June 2011 (UTC)[reply]

Unacceptable performance impact

It is unacceptable for the perforance impact [5] has on a user's browser let alone our server farm to serving two 404 pages per page. The summaries should be more descript and not just a URL to a discussion without a beginning. In any case the effect can done with {{DISPLAYTITLE:<span style="display:none;">{{FULLPAGENAME}}</span>}} (it's already a template too). — Dispenser 22:18, 3 June 2011 (UTC)[reply]

TheDJ already reverted it. — Edokter (talk) — 22:25, 3 June 2011 (UTC)[reply]
Yeah, not the best idea indeed. If they just want to hide the title on a limited set of pages, Dispenser's suggestion is probably best. If they need more CSS for a 'set' of pages, they can give those pages the same prefix, and we can add a conditional loader based on pagename prefix, to load something like MediaWiki:Common.css/ACP.css. But above all, discuss the ideas before implementing them, because this page is way to critical to just slam your random ideas into it. —TheDJ (talk • contribs) 22:41, 3 June 2011 (UTC)[reply]
Sorry about that. My bad. I shoud have checked for more subpages. But I am glad you had a solution to the problem. I actually looked around on my own and asked around among some of the staff, and they did not know about that template. But it may be the easiest way to solve this.//Hannibal (talk) 22:45, 3 June 2011 (UTC)[reply]
If you need something that cannot be done with local CSS on a page, and more so when you need JS, then please come here, explain what you want to do and the guys watching this page can help make it true. This is our biggest wiki, and there is lots of experience here with making 'hacks' as efficient and unobtrusive as possible, but it is also one wiki, where such hacks really do need to be as unobtrusive as possible. Just ask —TheDJ (talk • contribs) 22:51, 3 June 2011 (UTC)[reply]
Thank you for the offer. For the moment, this is the only thing that I need help with, but I will definitely come back.//Hannibal (talk) 23:02, 3 June 2011 (UTC)[reply]

How to use?

Where do I put this on my own wiki? Anywhere? -B1KWikis (talk) 20:44, 7 June 2011 (UTC)[reply]

Nevermind, I checked for the page "MediaWiki:Common.js" and there was a message there that said the changes apply to all users, indicating that I used the right page -B1KWikis (talk) 20:56, 7 June 2011 (UTC)[reply]

IE6 seriously broken

I've been playing with my old PC running W2K/IE6, only to notice it refuses to run any javascript, regardless of skin or login status. Only when I do a CTRL-F5 to fully reload a page, do all scripts run. Any other time, the error "mw.util.addPortletLink is null or not defined" is given and all scripts are aborted.

I seriously think the first line in Common.js is to blame: window.addPortletLink = mw.util.addPortletLink;

Is this line really necessary, or can it be removed and let wikibits handle old calls? — Edokter (talk) — 15:11, 11 June 2011 (UTC)[reply]

Removing the line only results in the next instance on 'mw.util' throwing an error. If we want to keep IE6 supported, we need to find out a way to guarantee that mw.utils is loaded first. Otherwise, we may as well ditch all IE6 related javascript, because there really is no point in having javascript that keeps crashing. — Edokter (talk) — 16:57, 11 June 2011 (UTC)[reply]
Per Wikimedia Analytics - User Agent Breakdown by Browser IE6 use is now under 3%. At what point do we drop support? ---— Gadget850 (Ed) talk 01:19, 12 June 2011 (UTC)[reply]
Usually below 1% as I understand it. However, this also blocks user scripts, so investigating this may be warranted. — Edokter (talk) — 01:20, 12 June 2011 (UTC)[reply]
Some further investigating reveals the trouble started with this edit by Krinkle. Obviously, no impact analysis was done. I don't know what the core cause is; it could be resourceloader, but Monobook is also affected (which does not use it). Since a hard reload does work, but normal loading does not, it must be a dependency issue, but I have no idea how to trace this. At this point, I am inclined to revert the migration to mw.utils until IE6 really drops below 1%. — Edokter (talk) — 01:29, 12 June 2011 (UTC)[reply]
This has worked in the past and if it doesn't, then there is an issue that needs to be solved. Your assessment that no impact analysis was done is false btw. Do you have mwEmbed enabled perhaps ? I've personally had a lot of issues with that thing enabled. —TheDJ (talk • contribs) 14:41, 12 June 2011 (UTC)[reply]
No, I don't have mwEmbed enabled. I tend to stay away from beta scripts. — Edokter (talk) — 15:13, 12 June 2011 (UTC)[reply]
(edit conflict) Hi,
When 1.17 was first deployed and ResourceLoader 1.0 made it's introduction (for which I didn't develop the loader), it was way beyond testing whether mw.util is correctly loaded on en.wikipedia.org, reason being that this was tested before deployment (as we always do). I also know for sure that the load order was correct at that point (even for IE6, even on en.wikipedia.org).
As you may or may not know, aside from major releases (such as 1.17) there are smaller deloyments almost every week, so it may very well be that due to some change somewhere by someone this somehow broke for IE6. I know I didn't change anything in ResourceLoader's loader structure recently that was deployed.
The edit to Common.js you are referring to does indeed make use of mw.util, I was doing so because both from documentation and personal experience I know the utilities are loaded before the site scripts. There is a certain abstraction point at which things should not require testing in every browser in the planet, simply because it's known to work. The loader order is one of those things.
The first line you are referring to may trigger an issue, but it's certainly not the cause. And there's a fair chance removing that (or even removing mw.util entirely from Common.js) wil not fix but simply move the issue to some other place it's referred to. If in IE6 mw.util is not loaded before the site scripts, please open a bug in bugzilla: and make sure you include steps to reproduce and set priority to High.
Thanks in advance, Krinkle (talk) 14:54, 12 June 2011 (UTC)[reply]
The only way to know for sure is to disbale/revert all calls to mw.utils temporarely. Would it be OK to do so? This should not break any functionality. — Edokter (talk) — 15:13, 12 June 2011 (UTC)[reply]
I think we should just forget about MSIE6 (and other old browsers). --Locos epraix ~ Beastepraix 20:57, 12 June 2011 (UTC)[reply]
Sometimes when I break one of my userscripts and I look in the error console of my browser the reported errors are not from my scripts but, instead, from js included by MediaWiki itself. So I think it is possible that the same think may be happening, and you are getting errors from mw.util. Last time I had to deal with something like this, I looked in the Call stack of Google Chrome Developer Tools and noticed that, although the error was happening when one line of the MW files was executed, the real problem was in one of my function calls to functions in those files and when I fixed my user script the problem stopped.
I'm not sure about what I'm going to say, but isn't the code "window.addPortletLink = mw.util.addPortletLink;" executed as soon as MediaWiki:Common.js is loaded? Would the same happen if the code was changed to something like
window.addPortletLink = function ( params ) { return mw.util.addPortletLink ( params ) };
If I understood correctly this way mw.util would only be used when someone calls "window.addPortletLink", which I think usually happens after "$(document).read()" (and maybe at that time the mw.util will be already loaded, and there will be no errors). Helder 21:04, 12 June 2011 (UTC)[reply]
Sounds like a good idea. One thing i don't understand... wasn't addPortletLink a core wikibits function ? I can see why it would be deprecated, but i'm lost on why it would not be defined anymore... —TheDJ (talk • contribs) 21:31, 12 June 2011 (UTC)[reply]
It is still defined; wikibits is fully operational. Krinkle just deemed it deprecated and replaced all calls to wikibits with mw.util calls, and remapped what was left. — Edokter (talk) — 21:37, 12 June 2011 (UTC)[reply]
It is not 'deemed' deprecated by Krinkle, it IS deprecated. —TheDJ (talk • contribs) 21:39, 12 June 2011 (UTC)[reply]
And yet we still need it in the painfull absence of a importScript replacement... — Edokter (talk) — 22:00, 12 June 2011 (UTC)[reply]

And IE6 IS deprecated :) →AzaToth 21:43, 12 June 2011 (UTC)[reply]

I ment that he deemed wikibits deprecated. While that may be, it is still fully operational. — Edokter (talk) — 21:45, 12 June 2011 (UTC)[reply]
Let me explain what "deprecated" means in software development. It means that a certain method is redundant or superseeded and is soon to be removed. It also means that it still works like it did before, else it would be "removed" not "deprecated". Wikibits is deprecated in favour of the mediawiki.js library. Depending on how smooth the transition goes, wikibits will either be removed or quarantined in a future version of MediaWiki. Krinkle (talk) 15:14, 13 June 2011 (UTC)[reply]
Edokter, can you test what happens on test wiki ? I replaced the Common.js there with our version minus the addportletlink bit. —TheDJ (talk • contribs) 21:41, 12 June 2011 (UTC)[reply]
Booting my old machine... — Edokter (talk) — 21:45, 12 June 2011 (UTC)[reply]
First load and CTRL-F5 load OK, normal reload and page clicks give "Object expected" (same as here). — Edokter (talk) — 21:56, 12 June 2011 (UTC)[reply]
Same problems on nl.wiki and Commons. — Edokter (talk) — 22:40, 12 June 2011 (UTC)[reply]

Kill it?

Personally, I have no interest in IE6 anymore. But it's use is still above 1%, which is the threshold for support (I forgot where I read that; meta? mediawiki?). The browser is now 10 years old, and if support is dropped, it should be official somehow. I am going to disable MediaWiki:Common.js/IE60Fixes.js; it is no longer functional after all. — Edokter (talk) — 22:40, 12 June 2011 (UTC)[reply]

Actually, that won't make a difference as fixalpha has been in MediaWiki for for a while (as are other IEFixes). This script was copied from en.wikipedia.org to other wikis, and somehow made it's way back here meanwhile it's been integrated into core. So fixalpha is in MediaWiki core and is loaded for IE6, and should be removed from en.wikipedia's scripts either way.
Aside from that, I think browser support is something the developers team and/or the foundation should decide, not the community of en.wikipedia.org Krinkle (talk) 15:03, 13 June 2011 (UTC)[reply]
I should note that the two scripts aren't the same tho. The one on en.wikipedia.org loops through all document images, whereas the core fix is just a simple fix for the logo. Krinkle (talk) 15:09, 13 June 2011 (UTC)[reply]
I know, I wrote the script. Note that even fixalpha is broken now. — Edokter (talk) — 15:17, 13 June 2011 (UTC)[reply]

Bug filed

I filed a bug, explaining the situation and asking wether IE6 should still be supported under Bugzilla:29384. Trevor promptly changed the title to "mw.util loads too late in IE6", so I believe there may still be a solution. — Edokter (talk) — 21:15, 13 June 2011 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js&oldid=434123910"