ebooksgratis.com

See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
MediaWiki talk:Common.js - Wikipedia, the free encyclopedia

MediaWiki talk:Common.js

From Wikipedia, the free encyclopedia

Meta | Commons | Wikibooks | Wikiquote | Wikisource | Wiktionary | Deutsch | Français | Nederlands
This interface message is documented on its manual page.
The page forms part of the MediaWiki interface, and can only be edited by administrators. To request a change to the page, add {{editprotected}} to this page, followed by a description of your request.
Notice MediaWiki:Common.js imports several other messages:

June 2004 – July 2006
August 2006 – January 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
December 2007 – March 2008
Archive index (incomplete)

Contents

[edit] class,IPA

The {{IPA}} template which is based on class.IPA forces Firefox to display the IPA correctly, but adding to a table class="IPA" or class="IPA wikitable", which are based on the same class, does not. Instead, it displays with Arial Unicode, which is defective in its IPA range. How do we fix this? kwami (talk) 07:06, 3 January 2008 (UTC)

The IPA class is never intended to be used directly; It should only be used by the several Unicode templates in order to display Unicode characters. — Edokter • Talk • 13:52, 3 January 2008 (UTC)
So are you saying it cannot work as a custom HTML class in tables? kwami (talk) 16:47, 3 January 2008 (UTC)
That is correct. — Edokter • Talk • 17:11, 3 January 2008 (UTC)
I was under impression that IPA class is here only to fix IE shortcomings. I wish someone could write a detailed help page on this topic ∴ AlexSm 01:36, 7 January 2008 (UTC)
There are two problems in FF: One, if you don't format all IPA with a specific font, you get the browser's default font for letters it covers, which often doesn't match and looks very unprofessional. Two, whenever the font includes replacement pairs, such as IPA tone letters or Indic akshara, a simple class="wikitable" table doesn't force them to combine. However, a class="wikitable" style="text-align:center" table displays them properly. I have no idea why the behavior is so odd, but suspect it's a bug in Wikipedia coding. kwami (talk) 02:02, 7 January 2008 (UTC)
I was able to compensate by adding ".IPA { font-family: Gentium, Charis SIL !important; }" to my monobook.css, but something like this should be automatic. kwami (talk) 19:42, 26 May 2008 (UTC)
The problem with decomposed ligatures and akshara was due to setting my prefs to justified text. Once I aligned it left, the issue disappeared. So there is a bug in the code. Is it possible to have proper ligature rendering and justified text? kwami (talk) 19:44, 26 May 2008 (UTC)

[edit] Modernista referrer

I put in this notice as prepared by Random832, and it seems to do the job nicely, except for one thing. It's placed above the title so as to appear distinct from the article, which I think is a good thing, but it also means that part of the notice is obscured by the Modernista navigation frame. Could somebody fix the notice so it's just a bit lower down? --Michael Snow (talk) 23:50, 19 April 2008 (UTC)

The code was removed since then. —AlexSm 18:42, 6 May 2008 (UTC)
Right, it was removed with a comment, "as it's not legal for them to do what they do, report them instead", which makes no sense to me. What's that supposed to mean, report them? To whom? I've restored the notice. --Michael Snow (talk) 16:56, 16 May 2008 (UTC)

I don't agree with this addition. It goes against the spirit of Wikipedia:No disclaimers in articles. I also don't see why this site is getting special treatment. Who cares if they display Wikipedia in a frame? Really, why does it matter? --- RockMFR 19:17, 16 May 2008 (UTC)

I also don't like this addition. Let's just worry about making the encyclopedia and not bloat the code worrying about how other people re-use it. —Remember the dot (talk) 00:08, 17 May 2008 (UTC)
Agreed. It is bloat and should be removed. Such cases are much better handled using referrer filtering (but that requires a dev tinkering with Apache). — Edokter • Talk • 08:52, 17 May 2008 (UTC)
OK, I've removed it again. —Remember the dot (talk) 17:36, 17 May 2008 (UTC)
It was approached in this fashion specifically because a developer said any administrator could take care of the issue, which is what we did. It has the same effect as referrer filtering. Is it somehow more bloating to do it here than in Apache?
Regarding "Let's just worry about making the encyclopedia" - this doesn't affect the encyclopedia in any way. It's not a disclaimer about an article, on Wikipedia the article displays normally, it's specifically about the Modernista site and only displays there. Regarding "Who cares if they display Wikipedia in a frame?" - the use potentially confuses visitors to their site about the source of the text, obscures the Wikipedia trademark and logo, and objections have been made to the company and on Talk:Modernista!. For who cares, I could give you Florence Devouard, Jimmy Wales, and Mike Godwin, to start with. --Michael Snow (talk) 04:08, 19 May 2008 (UTC)
Since nobody has presented an alternative, and the objections are unpersuasive ("I don't like it", as opposed to actually rebutting the need for this), I've restored the referrer code. --Michael Snow (talk) 19:36, 23 May 2008 (UTC)

Michael, I'd appriciate if you didn't go interpret our silence as a "agree by non-resistence", because it's not. Our arguments are valid; we don't need this code bloating up the main script repository that handles the entire site; It slows down page loading and is only used in maybe 0.0001% of all page loads. Plus it is not effective in any way... if you want to be effective, we'd redirect the referrer page to Internet fraud or something like that. — Edokter • Talk • 23:02, 23 May 2008 (UTC)

All of our content is either freely licensed or fair use. This means that Modernista has the right to do whatever it wants with it. Why are we adding a disclaimer when people do something that we've tried so hard to enable them to do? —Remember the dot (talk) 02:11, 24 May 2008 (UTC)
It is one thing to use our content freely, but to copy an entire site pretending to be Wikipedia is infringing trademark. If there is to be any code, it should be effective. — Edokter • Talk • 08:26, 24 May 2008 (UTC)
They don't pretend to be Wikipedia as far as I can tell...they just show Wikipedia with a Modernista banner laid on top. —Remember the dot (talk) 20:52, 24 May 2008 (UTC)
The issue, from what I've been told / read, is that their "logo" is covering Wikipedia's. I have to say that I sort of agree with Michael here, if only slightly. Really, getting caught up in every byte is a bit silly. The one thing that will not happen is an edit war here. What it looks like right now is that more outside opinions are needed. Perhaps post to a pump or noticeboard asking for input? Else, I'd suggest leaving the code. --MZMcBride (talk) 00:48, 25 May 2008 (UTC)
It's really not that bad - take a look at their site and you'll see that the Wikipedia logo is very clearly visible despite the Modernista banner.
I'm not trying to remove every byte possible from common.js; that would make the file unreadable. I just prefer to keep the common JavaScript to a minimum for reasonable performance and clarity, and also (though this doesn't apply to this thread) because I don't like having to use JavaScript to fix issues that would be better fixed by configuration changes etc. —Remember the dot (talk) 01:28, 25 May 2008 (UTC)

I'm against this code in Common.js. It's unreasonable to append this code just for a very tiny percentage of visitors (which was even lower before someone brought our attention to this "issue"). If another small company does the same trick, are you going to add the second warning for referrers from another website? —AlexSm 02:47, 25 May 2008 (UTC)

I'm not interpreting silence as consent, but nobody has presented an alternative. The discussion has a variety of guesswork about whether this is a legitimate trademark concern (Wikimedia officials in a position to judge that have indicated that it is) and about whether the "bloat" is a significant detriment (considering that a developer said this was something any administrator could handle, it seems like they had this page in mind; if someone who actually deals with system resources came and said it's a problem, then I'd look at it differently). The decision should be based on information, not speculation and opinion. I would be happy to find there's some other option, but this is already a compromise from someone's earlier attempt to have the notice directly in the article itself. --Michael Snow (talk) 17:56, 25 May 2008 (UTC)
Who said it was a trademark infringement, and if it is, why aren't we just blocking access to the site entirely until they stop the infringement? —Remember the dot (talk) 16:27, 26 May 2008 (UTC)
Mike Godwin said it was a trademark issue. As for what steps to take in response, as you pointed out yourself, the text is freely licensed, so there's a balance to be struck in dealing with this. If you think we should block Modernista's access entirely, feel free to persuade the people who would need to implement that. --Michael Snow (talk) 04:57, 28 May 2008 (UTC)
We could use the exact same kind of JavaScript to blank every Wikipedia page viewed through Modernista, leaving behind only a message about trademark infringement. But before we do that, could you point me to what Mike Godwin said about the issue? —Remember the dot (talk) 01:14, 29 May 2008 (UTC)
No, I can't point you there, it comes from an email discussion. --Michael Snow (talk) 22:14, 29 May 2008 (UTC)
Should I just e-mail Mike Godwin and ask him to repeat his response for me? I'd like to hear all the gory details of why this is a trademark infringement. —Remember the dot (talk) 00:39, 30 May 2008 (UTC)
He didn't give a lot of gory details, he simply encouraged Jimmy Wales in contacting Modernista to object to this particular use because it raised trademark issues. As they've failed to respond appropriately, that leaves us to find alternative ways of protecting Wikipedia's brand. You're welcome to email Mike and see if he would like to give a more elaborate explanation. --Michael Snow (talk) 16:10, 30 May 2008 (UTC)
If we're going in that direction, it would probably be better to just bust out of the Modernista iframe rather than to blank the page. But I'm not really convinced either is a good idea; if they want to use Wikipedia as a backdrop for their site, why not let them? It's not like they're making it hard to get rid of the banner, anyway. —Ilmari Karonen (talk) 22:45, 29 May 2008 (UTC)
So, you'd also like to simply eliminate the Modernista code? —Remember the dot (talk) 00:39, 30 May 2008 (UTC)
I don't really mind having it there if others feel it's needed, but no, I don't personally see much point in it. You may put my opinion down as a resounding "Meh." —Ilmari Karonen (talk) 02:43, 30 May 2008 (UTC)

[edit] PngFix() breaking "no pictures" option

Looks like PngFix makes all PNG images to appear despite unchecked "Show pictures" option in IE6. In other words, it breaks the functionality for users who disabled pictures (usually to to save traffic). One possible way to fix this is to check .complete image attribute. —AlexSm 18:42, 6 May 2008 (UTC)

Got code? --MZMcBride (talk) 19:52, 6 May 2008 (UTC)
I don't have time, so I was hoping the code author could thoroughly test this or maybe have some better ideas. —AlexSm 20:54, 6 May 2008 (UTC)
Although I cannot image that anyone in 2008 would not want to see any images, I will have a look. But how does ".complete" into play? I cannot find any references to in online. However, if it only applies to IMG elements, it won't get us anywhere; PNG are converted to DIVs which may not have that attribute. — Edokter • Talk • 23:50, 6 May 2008 (UTC)
I found this property using JS shell, but here's an official link for you: http://msdn.microsoft.com/en-us/library/ms533688(VS.85).aspx ; as for convertion (into SPAN), that's the whole point: if an image is not "complete" by the time the script is executed, this might mean that all images are disabled, so you do not convert the image. Again, there might be a better way... —AlexSm 13:03, 7 May 2008 (UTC)
I already received a message on my talk page to "upgrade to IE7". Well, I don't use IE at all (except for compatibility testing) so I guess I'll explain how the issue started. We copied the PngFix code to ru.wp, and a couple of days ago one user complained that he cannot turn PNG images off on IE6. He is using GPRS, which is kind of slow, and he is probably paying for each megabyte of traffic. In any case, if this can be fixed easily, it should be fixed. And if you want all users to upgrade to IE7, then there is no need for IE6 fix (which all users have to download, by the way). —AlexSm 15:53, 7 May 2008 (UTC)
The IE6 fix is there to limit the problems IE6 causes. Unfortunately, we can't entirely eliminate them from our end. It'd be best if users just stopped using IE6. Users using GPRS and paying by the megabyte could actually save money by using a different browser because many web sites (including Wikipedia) have to send extra CSS files to Internet Explorer to make it work right. —Remember the dot (talk) 16:14, 7 May 2008 (UTC)
Partly I was hinting at the (failed for some reason) proposal to move the code into separate MediaWiki:IEFixes.js (as in ru:MediaWiki:IEFixes.js). —AlexSm 16:18, 7 May 2008 (UTC)
After I proposed that the comments made me realize that the HTTP header required to send an extra file would be significant compared to the small amount of IE-specific code we send out, so it's probably not worth it. —Remember the dot (talk) 16:22, 7 May 2008 (UTC)

My first thought was: why fix a problem here that only happens on ru.wiki? But then again, you have a point. Anyway, I tested the .complete check and it works without any performance hit. Change the following line:

if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.onclick)

to

if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && img.complete && !img.onclick)

Now, should we implement it here as well? — Edokter • Talk • 23:04, 7 May 2008 (UTC)

If there are no further objection, the .complete check is going in. — Edokter • Talk • 17:05, 16 May 2008 (UTC)
Fine by me (though I can't test it, not having IE available here). I thought for a moment it might break on slow connections where the images might not have finished loading by the time the code runs, but since it's deferred using window.attachEvent("onload") (rather than the usual addOnloadHook(), which somewhat confusingly runs earlier), that shouldn't be a problem: any images that are going to be loaded should be complete by the time the onload event fires. —Ilmari Karonen (talk) 17:13, 16 May 2008 (UTC)

[edit] Donation banner code changes

Using code written by Splarka, I've updated the donation banner code to detect the skin name and only work on Monobook. It's clear that the banners were laid out specific to Monobook, as they look God-awful in the other skins. Also, the new code moves the onload (making it more efficient). Let me know if there are any issues. Cheers. --MZMcBride (talk) 01:16, 7 May 2008 (UTC)

Hmm... what's wrong with using MediaWiki:Monobook.js for that code? —AlexSm 01:56, 7 May 2008 (UTC)
[skinname].js pages are deprecated. They still work in MediaWiki for backwards compatibility purposes. --MZMcBride (talk) 03:05, 7 May 2008 (UTC)
They're not deprecated at all! They're 100% appropriate for code that's actually skin-specific. --brion (talk) 19:28, 3 June 2008 (UTC)
bugzilla:4178#c17 is where it indicates that it was deprecated. Perhaps something changed or he was simply mistaken? --MZMcBride (talk) 20:19, 3 June 2008 (UTC)
Mistaken. I've removed the deprecation notices. :) While indeed it's possible to do skin-specific JS by adding checks for skin names, IMHO that's kind of lame as it forces everyone to load all skin-specific JS. --brion (talk) 20:38, 3 June 2008 (UTC)

OTRS has been receiving messages lately from unregistered readers that Wikipedia content sometimes gets replaced with a donation request. No browser information yet, and the "sometimes" makes it hard to reproduce too, but there were complaints about this last year as well. Is it the restored anontip[1] or the change[2] that's problematic? Is the use of writeln necessary? --Para (talk) 09:59, 29 May 2008 (UTC)

Ah. probably Safari users. I think writeln (just like document.write) can be dangerous on Safari. Better to use DOM editing. --TheDJ (talk • contribs) 17:35, 29 May 2008 (UTC)
TheDJ: Can you take a look at the code in the section directly below and see what needs to be changed, as I plan to make that code live sometime in the next week or two? Thanks! --MZMcBride (talk) 18:11, 29 May 2008 (UTC)
Of course. I'm about to run out, but i'll do that in an hour or 6. --TheDJ (talk • contribs) 18:40, 29 May 2008 (UTC)
I've removed the document.writeln. MSDN docs warn that at least on IE, use of write/writeln after the document is loaded can break, and requires blanking the entire page. This is consistent with the descriptions we've gotten (and finally a screenshot!) from people reporting that Wikipedia was "requiring donations to read" -- pages coming up, then blanking and showing only a donation request link.
This onload handler _should_ be getting run just before the completion of the <body> tag, but presumably there are mysterious circumstances where it's getting triggered late, or something. I haven't been able to repro it myself though. --brion (talk) 18:28, 3 June 2008 (UTC)
We were already preparing something like this. But thx brion. --TheDJ (talk • contribs) 18:43, 3 June 2008 (UTC)
In light of today, would someone please change the document.write(0 in MediaWiki:Common.js/watchlist.js to importScriptURI() ? --TheDJ (talk • contribs) 00:20, 4 June 2008 (UTC)

Ok, made one more tweak which works around the Internet Explorer failures. To summarize:

  • MSIE throws an "operation aborted" error dialog, then throws away the page when you click "OK" iff:
    1. the offending JS code is run from a <script> that's inside the <body> and right at the end of it </body>
      • worked around by moving the runOnloadHook() call outside of the </div> for globalWrapper
    2. there's some invalid HTML, especially unclosed tags
    3. you add new stuff to the end of an element it's confused about
      • appending to globalWrapper via appendChild() or innerHTML += blah would fail. document.writeln() worked, but could trigger other problems in some cases. Prepending into globalWrapper with insertBefore() appears to nicely avoid both issues.

So, with that change to the anonnotice insertion, at least that particular thing shouldn't be causing the "operation aborted" error anymore, even for people who'll get the old bad HTML in their caches (as long as they're getting the current JS).

Phew! Well let's hope nothing else horrible happens. ;) --brion (talk)

[edit] Merge donation banner with anon tips

I think merging the donation banner (above the tabs) with the anon tips (currently below the tabs) would be a good idea. I think having one randomized line above the tabs, with perhaps a slight bias toward the donation message, would be best. Thoughts? --MZMcBride (talk) 04:45, 7 May 2008 (UTC)

Follow-up: After a bit of discussion elsewhere, it has become clear that it would probably be best to merge the two messages in a month or so. The donation banner has been deactivated for four months – it should be more visible for a bit. When the new code is implemented, it will probably be what is proposed directly below. --MZMcBride (talk) 21:26, 7 May 2008 (UTC)

Proposed merged code for the two banners
I agree with this proposal. The upper-right anon message has been a source of frustration with respect to overlapping other elements on the page. --- RockMFR 19:03, 10 May 2008 (UTC)
This code is due to the report here.
Newer proposal code for the two banners
This makes sure that the code is inserted at the correct spot (wikEd and popups operate here as well), and it avoids using the innerHTML += construct which can sometimes be problematic on larger chunks of HTML, especially icw scripts. I did notice however that with a bias of 90 for donation messages, followed by another random, the chances of actually seeing one of the anontips is quite slim. I think the bias needs tweaking, or when we do the 2nd random, we should be forced to select a number between weight-limit and message.length, instead of between 0 and message.length. --TheDJ (talk • contribs) 10:42, 30 May 2008 (UTC)
I still strongly favor using one merged banner rather than two. If nobody objects in the next few days, I propose adding the code to Common.js, with a biasPercent=81.5. This will make it so that approximately 1 in 10 views hits an anon tip, while 9 in 10 views hit a donation message. (The number is 81.5 vs. 90 due to using a double random.) I also think pushing down the banner with a top:1px would be good. It's a small, but noticeable change in Firefox. My only remaining concern is using nowrap with IE; there are reports that IE6 (shockingly!) doesn't handle nowrap well. The original code used &nbsp;s, which was a major hit for legibility. So... we can use nowrap and hopefully it won't hurt IE6 users, we can restore the non-breaking spaces, or can just use regular spaces. If the screen is that narrow, it's going to hit the "Log in / create account" text anyway... --MZMcBride (talk) 19:17, 3 June 2008 (UTC)
This is JavaScript, right? We can fix that programmatically (warning: untested code, may have bugs):
// walk the DOM tree, replacing spaces with &nbsp;
// note: do this before attaching the branch to the full tree
var node = temp;
while (node) {
    if (node.nodeType == 3)  // TEXT_NODE
        node.nodeValue = node.nodeValue.replace(" ", "\240"); // nbsp = octal 240
    else if (node.firstChild)
        node = node.firstChild;
    else {
        while (!node.nextSibling && node.parentNode)
            node = node.parentNode;
        node = node.nextSibling;
    }
}
wrapper.insertBefore(temp.firstChild, wrapper.firstChild);
—Ilmari Karonen (talk) 08:14, 5 June 2008 (UTC)
Seems like a lot of code to be loading on every page load just to ensure that the words don't wrap. IE6 simply ignores nowrap, so I'm inclined to just allow the words to wrap for IE6 users. In fact, I'm trying to figure out why the words shouldn't wrap for everyone. But this is trivial in the greater scheme. There don't seem to be any objections to merging the two banners (at least not on-wiki). So, I'm going to go ahead and implement the updated version tomorrow. The final thing I was thinking about was moving it to a subpage and have it only load for anons. --MZMcBride (talk) 18:09, 6 June 2008 (UTC)
  • Strong Support. This small change will help out a great deal. Simplify, simplify. -- Quiddity (talk) 20:25, 3 June 2008 (UTC)

[edit] MainPageDeletedImage()

I removed the MainPageDeletedImage() function, which appears to be an anti-vandalism measure preventing compromised admin accounts from ruining the main page through deletion. As far as I can tell, this function doesn't serve a purpose anymore because the main page can no longer be deleted, so I've removed it. Please let me know if there is a reason why we should add it back. —Remember the dot (talk) 05:19, 7 May 2008 (UTC)

Hmm. The Main Page can still be deleted by any semi-competent admin. But it being deleted is a pretty rare occurrence, so... meh. --MZMcBride (talk) 16:44, 26 May 2008 (UTC)
The devs made it technically impossible to delete the Main Page after this fiasco, see [3]. —Remember the dot (talk) 16:52, 26 May 2008 (UTC)
/cough/ Link /cough/ "Semi-competent admin." --MZMcBride (talk) 17:07, 26 May 2008 (UTC)
Oh. Still, you'd really have to be trying, and the deletion would be immediately reverted anyway. —Remember the dot (talk) 17:21, 26 May 2008 (UTC)
Yowza! Now I know what to do if I ever want to go seriously rogue! Let's have some more people watching that interface message, shall we? —Ilmari Karonen (talk) 20:41, 29 May 2008 (UTC)

[edit] Broken

recent edits (last 20 minutes) have broken the code I am getting errors on every page load. please fix, its line 644. βcommand 2 21:07, 7 May 2008 (UTC)

I second this. This is because of the return statement being used on a non-function. —paranomia (formerly tim.bounceback)a door? 21:11, 7 May 2008 (UTC)
Give me a couple minutes and I'll have it fixed. —Remember the dot (talk) 21:13, 7 May 2008 (UTC)
OK, I was just about to do an {{editprotected}}. Thanks, —paranomia (formerly tim.bounceback)a door? 21:14, 7 May 2008 (UTC)

Why don't you make all changes in a separate file, then announce it here and wait one day for other users to review it? "Be bold" is not about this page. —AlexSm 21:17, 7 May 2008 (UTC)

Because the changes are mostly minor and incremental and with the exception of this stupid mistake, they have gone through correctly. I don't plan on making any more changes to this file for a while. —Remember the dot (talk) 21:22, 7 May 2008 (UTC)
Still, errors do happen, inevitably. If every Wikipedia admin is allowed one little error in this file, I may as well turn JS off in my browser. Why not do it the safe way from the start? —AlexSm 21:25, 7 May 2008 (UTC)
I'll make sure to check for script errors when previewing changes in the future. —Remember the dot (talk) 21:28, 7 May 2008 (UTC)
I just checked and (unlike personal monobook.js) the Common.js is not inserted inline on preview . In other words, you cannot test new code for errors using Preview button. —AlexSm 06:00, 8 May 2008 (UTC)


Proposed fix:

var page = 'm:MediaWiki:Wikiminiatlas.js';
if( !importedScripts[page] ) {
importedScripts[page] = true;
var url = 'http://meta.wikimedia.org/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400';
var scriptElem = document.createElement( 'script' );
scriptElem.setAttribute( 'src' , url );
scriptElem.setAttribute( 'type' , 'text/javascript' );
document.getElementsByTagName( 'head' )[0].appendChild( scriptElem );
}

—paranomia (formerly tim.bounceback)a door? 21:18, 7 May 2008 (UTC)

Issue is now resolved. —paranomia (formerly tim.bounceback)a door? 21:21, 7 May 2008 (UTC)

What's the purpose of if( !importedScripts[page] ... before importing Wikiminiatlas? Common.js is only called once anyway. —AlexSm 06:00, 8 May 2008 (UTC)
Umm...come to think of it, it probably doesn't do anything and can be removed. —Remember the dot (talk) 15:32, 8 May 2008 (UTC)
Good point. —paranomia (formerly tim.bounceback)a door? 18:42, 8 May 2008 (UTC)
Then again, a gadget might import the script for some reason before common.js executes. —Remember the dot (talk) 21:27, 8 May 2008 (UTC)

[edit] Edittools cleanup

I've posted here regarding the current Edittools situation. Thoughts and / or volunteers would be much appreciated. --MZMcBride (talk) 04:33, 12 May 2008 (UTC)

[edit] new importScript, importStylesheet, and family

Per rev:35064 and above discussions: #1, #2 (related to bugzilla:12773 and bugzilla:13232), importScript() is now supported in core, along with 4 other slight modifications to make script loading more dynamic.

importScript(page) - imports a local wiki page as a script.
 example: importScript('MediaWiki:Something.js');
importScriptURI(url) - imports a script from a remote location, such as another project.
 example: importScriptURI('http://test.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki%3ASomething.js');
importStylesheet(page) - imports a local wiki page as a stylesheet.
 example: importStylesheet('MediaWiki:Something.css');
importStylesheetURI(url) - imports a stylesheet from a remote location.
 example: importStylesheetURI('http://test.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=MediaWiki%3ASomething.css');
appendCSS(css) - appends style data directly to the document.
 example: appendCSS('#bodyContent { color:red; }');

These could be used, for example, to reduce the size of the scripts being loaded on Common.js to be more conditional (hint hint). Note that they have been tested in most major browsers for basic functionality, but secondary or tertiary loading of scripts and styles may be buggy in some browsers (although bugzilla:12773 should fix most of those problems). --Splarka (rant) 07:25, 20 May 2008 (UTC)

Wicked !!! --TheDJ (talk • contribs) 08:39, 20 May 2008 (UTC)
Yes! I've always wanted these in the core. This will make moving scripts across wikis much easier. —Remember the dot (talk) 02:15, 21 May 2008 (UTC)
The functions are now active in en.wikipedia (i had a check in my monobook.js that presented me an alert as soon as it would find the new functions :D ) --TheDJ (talk • contribs) 23:28, 21 May 2008 (UTC)
Great! I removed the redundant functions from common.js and everything seems to still be working fine. —Remember the dot (talk) 01:45, 22 May 2008 (UTC)

[edit] Overall performance improvement

I have an idea that will result in an overall performance improvement for Wikipedia visitors. I've given this quite a bit of thought and I am confident that it will be worth it.

Internet Explorer 6's market share is dwindling. As of April 2008, it's down to about 29% and is expected to continue to decline. We currently have about 8 KB of scripts that are specifically for IE6 users and no one else. This means that the majority of users have to download an extra 8 KB of code. Having been a dial-up user, I can tell you that 8 KB is quite significant on dial-up, resulting in a 1-2 second delay when loading a Wikipedia page when common.js has not yet been cached. It is also significant to mobile device users that have to pay for bandwidth by the kilobyte.

I know that it's a bad idea to just remove all the IE6 the code because we can't turn our backs on that 29% of our readers. However, I did some testing with Fiddler and discovered that it only takes an extra 900 bytes to make an extra HTTP request. Since web browsers, including IE, re-use TCP connections instead of creating a new connection for every request, this 900 bytes would be the only cost of the request.

This means that if we split the IE6 code off onto a separate page:

  • 71% of users would save the transfer time of 8 KB.
  • 29% of users would have to download an extra 0.9 KB.

The extra IE6 file would be downloaded right after Common.js, so it would execute at the same time as it would if it were still in Common.js.

Another benefit is that factoring out the IE6 code would put less strain on the Wikimedia servers, meaning that the servers would perform better in general for both IE users and non-IE users alike. —Remember the dot (talk) 21:39, 24 May 2008 (UTC)

I'm not sure this is something we should really be concerned with. There are many optimizations that could be made that would decrease the bandwidth used for loading this page, but we just don't do them. I'd recommend running this past a developer before discussing it here. --- RockMFR 21:51, 24 May 2008 (UTC)
Every optimization helps (provided that it doesn't make the code unreadable etc.), and input from Wikimedia developers is always welcome. What other optimizations did you have in mind? —Remember the dot (talk) 21:58, 24 May 2008 (UTC)
While I generally want to beat someone over the head when they point out this guideline to me, I think WP:PERF applies here. This was discussed a few sections above. Has anything really changed since then? --MZMcBride (talk) 00:52, 25 May 2008 (UTC)
Two things have changed since this was discussed last. First, the market share of IE6 has continued to dwindle and will continue its decline into the forseeable future. We can't leave the IE6 code in there forever. Second, I researched the problem more with Fiddler and determined that splitting the IE6 code off into its own page would not have a significant performance impact on IE6 users.
I'm proposing a way to gracefully phase out the IE6 code as users move to other browsers, and at the same time improve performance a bit. While there's generally nothing we can do about performance, the common JavaScript file is definitely an exception. I shudder to think how slow Wikipedia would be if the common JavaScript was sloppily written and bogged down with excessive scripts. —Remember the dot (talk) 01:15, 25 May 2008 (UTC)
Just as before, I support moving IE6 code into separate page (as I already did on another Wikimedia project). And I don't think WP:PERF applies here, because we are talking about some benefits for (non-IE6) users, not just servers. —AlexSm 03:06, 25 May 2008 (UTC)
I support as well. WP:PERF does not apply here. --TheDJ (talk • contribs) 08:48, 25 May 2008 (UTC)
OK, based on the comments above and below I've moved the IE6 code to Mediawiki:Common.js/IE60Fixes.js. For now, I've only split off the PngFix code because I'm pretty sure the "IE 6 Z-index bug workaround for anonnotice" is for all browsers, despite the title. Additional clarification about this script would be appreciated, but even with only the PngFix script split off there will still be a slight performance improvement. —Remember the dot (talk) 18:14, 25 May 2008 (UTC)

[edit] Functional breakdown by size

I've been intermittently working on breaking functional pieces out of the global wikibits.js to reduce load times for low-bandwidth users (this'll particularly affect dial-up and mobile devices). Of particular note is code that's used only on some pages, such as when editing, or searching, or on a particular browser.

The same would probably be nice to do here on English Wikipedia. Here's a quick breakdown of some things that can be easily broken out from MediaWiki:Common.js:

Bytes What
2129 Special:Watchlist tweaks
2451 Special:Search tweaks
3869 Internet Explorer tweaks
4129 displaytitle replacement (can be replaced by fixes to MediaWiki)
4318 edit page tweaks (toolbar, summary check)
16429 (everything else)
33325 Total current MediaWiki:Common.js

(Note that the actual transferred file sizes will in most cases be lower, as these will be sent compressed for most browsers.)

About half the total can be broken out and loaded up only when on that special action or on that particular browser, reducing the bandwidth impact for first-time visits. (There'll be an extra hit when you do go into edit, or search, or whatever, but if you don't you'll never see it, and once you do it too will be cached.)

You guys can probably do much of this with just a brief JS check and a conditional importScript() call, but if you want/need native support in MediaWiki for fetching extra JS on particular actions, we can talk. --brion (talk) 16:41, 25 May 2008 (UTC)

Thanks for your message! I've split off the IE6-specific code, see the above thread. It probably wouldn't be a good idea to split off the general IE code because the majority of our users use IE7, and we don't want the majority to take a performance hit. The other areas you pointed out, however, would be great to split off, as relatively few people use the special pages etc. —Remember the dot (talk) 18:41, 25 May 2008 (UTC)
OK, I split the editing scripts off to MediaWiki:Common.js/edit.js, the watchlist scripts to MediaWiki:Common.js/watchlist.js, and the searching scripts to MediaWiki:Common.js/search.js, which shaved off another 9 KB. What can be done to remove the need for the displaytitle script? —Remember the dot (talk) 23:37, 25 May 2008 (UTC)
Hmm, i'm on cable and even I can notice the difference if I clear my cache. Nice work Remember the dot. Although I have to say that you "undefined" the isIE variable, which I was using in a testscript that thus broke. Not sure if other people use it, but something to keep in mind for the next couple of days. --TheDJ (talk • contribs) 17:23, 26 May 2008 (UTC)
Perhaps move MediaWiki:Sysop.js to MediaWiki:Common.js/sysop.js for consistency? Or move the others to MediaWiki:Edit.js, etc. ... --MZMcBride (talk) 17:30, 26 May 2008 (UTC)
If we're going to move something then let's move MediaWiki:Sysop.js to MediaWiki:Common.js/sysop.js. I chose to make the scripts pseudo-subpages to keep them logically linked together. —Remember the dot (talk) 17:40, 26 May 2008 (UTC)
I'm not a fan of subpages; the naming is quite illogical ("common.js/IE60fixes.js"). I'd prefer moving them to their own pages under MediaWiki:. — Edokter • Talk • 18:45, 26 May 2008 (UTC)
Why is this naming illogical? —Remember the dot (talk) 18:47, 26 May 2008 (UTC)
You have an extension in the path (the double ".js" part), which just isn't very intuitive. Pages with extensions should not have subpages IMO. — Edokter • Talk • 18:50, 26 May 2008 (UTC)
Yes...I was hoping to keep all the common scripts linked together, rather than scattered throughout the MediaWiki namespace. —Remember the dot (talk) 18:56, 26 May 2008 (UTC)

(Deindent) How about names like MediaWiki:Common-sysop.js or MediaWiki:Common/sysop.js? — Edokter • Talk • 19:00, 26 May 2008 (UTC)

MediaWiki:Common-sysop.js would be fine, but I don't think it really matters. —Remember the dot (talk) 19:04, 26 May 2008 (UTC)
A subdir could also accomodate specialized CSS files. — Edokter • Talk • 19:08, 26 May 2008 (UTC)
Wikipedia doesn't have any of the subpage enhancements enabled, so I don't really think there's much point to subpaging them. And as Edokter mentioned above, having a .js in the path name seems kinda weird. I would say that MediaWiki:Common sysop.js would be the cleanest way to put it (along with the benefits of Special:Prefixindex/MediaWiki:Common. -- Prod (Talk) 04:46, 8 June 2008 (UTC)

[edit] Wikiminiatlas JS load tweak

I tweaked the Wikiminiatalas JS load to pull from secure.wikimedia.org when viewing through the SSL interface. Previously, Firefox 3 was considering the page insecure and showing a broken lock & plain background on the favicon (in addition to it simply being potentially open to man-in-the-middle attacks injecting evil JavaScript. :) --brion (talk) 17:58, 26 May 2008 (UTC)

Excellent, thanks! —Remember the dot (talk) 18:00, 26 May 2008 (UTC)
Except now it doesn't work. So, maybe not so excellent. -- ShinmaWa(talk) 22:42, 30 May 2008 (UTC)
The JS is still loading; something else must have stopped it from acting as expected? --brion (talk) 23:25, 30 May 2008 (UTC)
The problem is that the toolserver URL in the templates has changed (to toolserver.org), and is no longer on the JS's whitelist for things to put the globe icon next to. Wikiminiatlas JS needs to be updated with the new URL. --brion (talk) 00:25, 31 May 2008 (UTC)
Updated at least the form I see on San Francisco. --brion (talk) 00:29, 31 May 2008 (UTC)
After a purge, it now works for me. Thanks, Brion. --MZMcBride (talk) 00:32, 31 May 2008 (UTC)

[edit] Multiple watchlist dismisses

There is ongoing discussion about implementing multiple dismiss buttons for the watchlist notice here. Comments / input / etc. welcome. --MZMcBride (talk) 04:30, 4 June 2008 (UTC)

[edit] Poor error handling in "IPv6 AAAA connectivity testing"

The code added in this edit adds some web bugs to the footer, and then tries to access them via javascript without testing that they were actually successfully added. I noticed this because my ad blocker stripped out the webbugs. The code should fail gracefully, by checking if the getElementById calls returned successfully instead of blindly assuming they worked. Anomie⚔ 01:03, 9 June 2008 (UTC)

Easy enough to test. Though thats a pretty obnoxious adblocker... behavior like that going to actively wedge the future automagic detection of working IPv6 support. What are you using? The issue you saw should now be gone. --Gmaxwell (talk) 01:08, 9 June 2008 (UTC)
Privoxy with the standard "webbugs" filter. I've added a fix to my monobook.js that solves the js error for me. Why does IPv6 support need to be tested? Anomie⚔ 01:15, 9 June 2008 (UTC)
Some small number of clients believe they have IPv6 connectivity but actually do not. If DNS resolution returns a v6 address these hosts will attempt to use it and fail. For these clients any IPv6 enabled sites will appear non-functional. (There is no problem for clients which merely do not have IPv6 support enabled)
Getting a good handle on exactly how many broken clients are out there is the first step to dealing with it, and a pre-requisite for turning on IPv6 for the main sites. Special:Watchlist on EnWP is being used first simply because we know we'll get good reports related to corner cases like yours, and since the page already remote loads toolserver we didn't expect any major errors. Latter steps will involve running the test on all Wikimedia pages, and further steps may involve things like alerting users to their misconfiguration and helping them fix their systems. The statistics this is gathering can be seen at http://ipv6and4.labs.wikimedia.org/stats.html.--Gmaxwell (talk) 01:39, 9 June 2008 (UTC)
I don't suppose someone could add the results page URL to the code documentation, could they? I'd rather not have to track this discussion down every time I want a look at the statistics. —Dinoguy1000 17:51, 10 June 2008 (UTC)
I put the stats link in the description and cleaned up the page overall. --MZMcBride (talk) 18:18, 10 June 2008 (UTC)
Thanks! —Dinoguy1000 18:37, 10 June 2008 (UTC)

[edit] Common.js broken for Konqueror

Please remove the strange unicode char in front of __ipv6wwwtest_startTest(); (end of common.js). It breaks the javascript execution for Konqueror. --Dschwen 13:55, 10 June 2008 (UTC)

It looks as though there was a stray byte-order mark in the code. I've removed it. Try bypassing your local cache to see if that fixed it. Cheers. --MZMcBride (talk) 14:05, 10 June 2008 (UTC)
Yay, thanks, that did it. --Dschwen 14:28, 10 June 2008 (UTC)


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -