MediaWiki talk:Common.js

From Wikipedia, the free encyclopedia

	This talk page is automatically archived by Werdnabot
	Any sections older than 31 days are automatically archived to MediaWiki talk:Common.js/Archive Apr 2007. Sections with less than two timestamps (that have not been replied to) are not archived. An index of the archives may be found at MediaWiki talk:Common.js/Archive index.

Archives
June 2004 - July 2006 August 2006 - January 2007

[edit] vandal problem

Is there any way to make changes that would stop this working in the short term (ie untill they chnaged the code):

http://en.wikipedia.org/w/index.php?title=Special:Undelete&target=User%3AIsikop%2Fmonobook.js&timestamp=20070128094554 Geni 11:06, 28 January 2007 (UTC)

I don't get what you mean. The user has been blocked already, so he/she can't edit anyway. —Mets501 (talk) 15:15, 28 January 2007 (UTC)

We are seeing a number of accounts to use the code to vandalise. IS it posible to make small changes to this page so the code wont work until we come up with a longer term fix.Geni 17:26, 28 January 2007 (UTC)

Seems unlikely without too many damaging side effects. How bad is this problem? If it's really really bad then we can think harder... —Mets501 (talk) 17:33, 28 January 2007 (UTC)

not to bad yet.Geni 17:55, 28 January 2007 (UTC)

Any changes we could make here would be fairly easy for the vandal to work around. It would probably be more effective to get the anti-vandalism bots to automatically revert such edits and report the users making them. It's not as if detecting them should be hard, given that we have the source for the script that makes them. —Ilmari Karonen (talk) 00:23, 1 March 2007 (UTC)

[edit] Collapsible tables

Some times I have an error from that function:

Error: Header has no properties
Source File: http://en.wikipedia.org/w/index.php?title=-&action=raw&smaxage=0&gen=js
Line: 240

Perhpas add a test if Header exist. _→AzaToth 17:11, 6 February 2007 (UTC)

On which page does this happen? —Ruud 17:37, 6 February 2007 (UTC)

Tables without a header shouldn't have the class "collapsible" as this is where the show/hide button is placed. —Ruud 19:38, 6 February 2007 (UTC)

I have added a test for whether any header row exists: HTH HAND —Phil | Talk 11:02, 9 March 2007 (UTC)

[edit] Collapsible sections

I was wondering whether it would be possible to adjust the collapsible table code a little to allow a table to be collapsed section-by-section? What I was thinking was that you could have a table like this:

where clicking the [hide] link in the caption hid the entire table whereas the corresponding link in each header-row hid the rows from there up to the next header-row.

Would it be difficult to arrange that the intermediate rows, those to be hidden, could have "header cells" in the first column?

This would be helpful in quite a few places, like in some infoboxes, where it would be helpful to have much of the information hidden until required. HTH HAND —Phil | Talk 16:23, 1 March 2007 (UTC)

[edit] Placing the cursor after the section name

A long time ago, Quarl and I discussed some user scripts and made a little snippet of code that, when you press tab to go to the Summary field, puts your cursor after the section name, so you can just start typing. It's a tremendously helpful little tweak, and now that I've removed Quarl's code from my monobook.js, I miss it. :-) It would be a good thing to implement site-wide, though. This was my version, though I think he improved on it in his Power Tools scripts:

/* When the summary box is clicked, select only the part *after* the section title/place the cursor after the auto summary */

addOnloadHook(function () {
    if (document.getElementById('wpSummary')) {
        summary = document.getElementById('wpSummary');
        function selectSummary() {
            section = summary.value.match(/(?:\/\*(?:.*)\*\/)?\s*(?:«(?:.*)»)? ?/);
            if (section) {
                sectlen = section[0].length;
                end = summary.textLength;
                summary.setSelectionRange(sectlen,end);
            }
        }
       summary.onclick = selectSummary;
    }
});

I don't know enough about JavaScript to follow his code, but I think this is equivalent:

// auto focus
$autosummary._focusSummaryEvent = function(event) {
    var sumField = document.editform.wpSummary;
    if (sumField.value.match(/^(?:\/\*.*?\*\/)?\s*(?:«(?:.*)»)? ?/)) {
        var n = RegExp.lastMatch.length;
        var m = sumField.value.length;
        // apparently you can't setSelectionRange in an onFocus handler, but
        // you can set a timer to do it 0 seconds from now.
        setTimeout(function() { sumField.setSelectionRange(n, m) }, 0);
    }
}

Found on http://www.cubewano.org/wpt/scripts/COMBINED.js

— Omegatron 00:13, 2 March 2007 (UTC)

Please check that code on multiple browsers; I think I remember something about selection code being different on IE and FireFox. --ais523 11:21, 9 March 2007 (UTC)

I don't know enough to check it for compatibility with all browsers and situations. I'm just proposing that someone with the knowledge include it site-wide. — Omegatron 03:59, 10 March 2007 (UTC)

Your version is a syntax error in IE6. Code shouldn't be added to the site-wide JS unless it works on all browsers! --ais523 14:45, 12 March 2007 (UTC)

[edit] Access key for project page: why change it?

Why is the access key for a Wikipedia: namespace article now A instead of C as it is in all other namespaces? This is inconsistent and irritating. Can this please be changed back? Grouse 00:46, 2 March 2007 (UTC)

Done. Since several weeks MediaWiki ships with default accesskeys so they no longer need to be defined here (except for links not part of the default interface.) Those defaults seem to be not fully consistent with the old accesskeys. —Ruud 00:13, 3 March 2007 (UTC)

Thanks Ruud! For the explanation and the fix. Grouse 16:19, 3 March 2007 (UTC)

[edit] escape() and replace() in importScript function

I read this December discussion about import module but I still don't see why escape() is there in the first place. Can you please give me an example when it's really needed? As far as I can see, it doesn't work for 2-byte Unicode characters anyway, so in ru:MediaWiki:Common.js we had to remove it so far. Same question for replace(): everything seems to work fine without it, even with spaces in the script path. — Alex Smotrov 20:48, 3 March 2007 (UTC)

The only reason for escape() to be there is to avoid problems with ampersands and percent signs. You're right that escape() produces weird results with non-ASCII Unicode (e.g. "Б" becomes "%u0411", which makes Apache choke). It looks like the appropriate function may actually be encodeURIComponent(). Using that function instead of escape(), "Б" is encoded as "%D0%91" instead of "%u0411", which Apache and MediaWiki interpret correctly as the UTF-8 encoding of "Б". (Tested on Galeon/Mozilla 1.7, Firefox 2.0, and IE 6.0) Mike Dillon 21:02, 3 March 2007 (UTC)

Thank you for the answer. I've yet to see any real users with & or % (and they can always specify the correct way to call their modules in their documentation). But since our version of importScript() can import from other Wikipedias, I guess it's better to be consistent and I'll recommend our admins to use encodeURIComponent as well. Still page.replace was not and is not necessary unless there is slight perfomance difference for Mediawiki servers or we're simply willing to save 2 bytes in URL ( _ vs %20 ). — Alex Smotrov 00:11, 4 March 2007 (UTC)

I may avoid a HTTP redirect from "Page%20name" (from the escaped/URI-component encoded "Page name") to "Page_name". I'm not entirely sure yet which mechanism is used to rewrite those URLs, but the performance gain/loss of the replace is very likely insignificant. —Ruud 00:50, 4 March 2007 (UTC)

You're correct that it avoids an HTTP redirect. I just tested it. Mike Dillon 17:28, 5 March 2007 (UTC)

[edit] Optimizing Mediawiki:Edittools

Please revert «optimization» and let's discuss it first. And most importantly, let's test new solutions in different browsers. — Alex Smotrov 21:21, 6 March 2007 (UTC)

Second. It's pretty uncool to simply add this with no discussion. Mike Dillon 21:23, 6 March 2007 (UTC)

I reverted it because of the discussion above and discussion at the village pump. It seems to cause issues in Firefox. I have also left a message with User:Misza13 explaining my actions. If they weren't appropriate, another admin should feel free to revert me. --PS2pcGAMER (talk) 21:32, 6 March 2007 (UTC)

Also you have to revert: MediaWiki:Edittools. And btw that's where the discussion happened in the 1st place, guess I should have watched that page as well. — Alex Smotrov 21:36, 6 March 2007 (UTC)

Got it. I'll let Misza13 sort out where s/he wants to go from here. At least the edit box is there now for everyone. --PS2pcGAMER (talk) 21:53, 6 March 2007 (UTC)

From a usability standpoint, I think this is a step backwards. Now in order to use the edit box, two clicks are required -- Open editing toolbox; click on desired symbol. Plus, there's a wait/lag in the middle. To me, this is a bad (mis-)use of AJAX. Plus, doesn't it bypass the "Show edit toolbar (JavaScript)" option in Preferences/Editing? –Dvandersluis 21:48, 6 March 2007 (UTC)

It was working, so I didn't want to revert this page back again. Although User:Ruud Koot has since reverted everything back to its original state. --PS2pcGAMER (talk) 22:01, 6 March 2007 (UTC)

For start, many people (like myself) don't use the tools at all. Now if you scan the traffic between the server and your browser, you'll notice that the edit tools actually form the majority of traffic of edit pages, which is unacceptable, because the code doesn't get cached (with my solution, it would). Second, this generates a lot of objects with attached JS events, which causes major problems in Firefox, known for leaks in this department. Third, the option in Prefs is about the editing toolbar (above the edit box), not the editing tools below - the devs were for some reason reluctant to add a new option to the preferences (which would be a near-ideal solution). Миша13 22:05, 6 March 2007 (UTC)

Okay, I misunderstood the distinction (or even the fact that there was one) between the two elements. I guess it's not (easily) possible to just get a new checkbox in there, rather than go through this process? Is finding a solution through javascript the only option there is (save for an update by the devs)?

Do you understand my usability concern, though? If there is a low percentage of usage of this to begin with, adding in an extraneous action will further reduce the number.

–Dvandersluis 22:13, 6 March 2007 (UTC)

Yes, I do understand, but here's a clash of a usability problem of my own (as outlined in my reply below) where my Firefox doesn't handle so much JS leaks and needs a restart every like 10 pages edited (or less if preview is used), because memory usage becomes sky-high. Миша13 22:36, 6 March 2007 (UTC)

[edit] Reverted

I reverted the changes for several good reasons:

1. A similar solution has been rejected in the past.
2. The code was undiscussed, badly written, undocumented and untested. If we want to have this stuff a small multi-purpose and well-tested and documented AJAX framework should be written first.
3. I do not believe the usability problems caused by this particular solution to the problem described at User:Cyde/Saving bandwidth are an acceptable trade off. In fact, I believe the edit pages are sent in compressed form, so there might not be a problem at all.

—Ruud 22:12, 6 March 2007 (UTC)

For the record, I reverted because of usability issues. People reported (and I also experienced) error messages that said something to the effect of "Javascript is not enabled" which confused a lot of people, especially since they knew that they had JS enabled. I didn't see an urgency in leaving the code in place so I reverted until things could be clarified. --PS2pcGAMER (talk) 22:24, 6 March 2007 (UTC)

For the record, the code was tested, works fine on Firefox and I also saw it working on IE (it failed on my PC tho). Also, whether or not the code is compressed (not all browsers support compression), it generates lots of objects with attached JS and causes severe memory leaks on Firefox. That's verified: as long as one only browses articles, it's fine, but whenever a few pages get edited (God forbid to use "preview"!), the whole thing gets bogged down, memory exhausted and further browsing impossible. In that aspect, I have a serious usability problem with the current implementation and am desperate to find a solution. Миша13 22:33, 6 March 2007 (UTC)

I believe there are other, better, solutions are possible which need to be carefully considered first. I have not experience any problem with Firefox and editing pages myself? Are there any other users who are experiencing this? —Ruud 22:42, 6 March 2007 (UTC)

Also on the bandwidth side: I suspect common.js is load 100 times or more often than edit pages are, meaing that adding 1kb of code here would much worse than the 20kb saved on the edit paged. —Ruud 22:42, 6 March 2007 (UTC)

I think Edittools is more like 38 kbytes. Common.js could call a separate javascript file only for edit pages. — Alex Smotrov 22:56, 6 March 2007 (UTC)

I use firefox (and wikipedia) extensively, and have never experienced any sort of slowdown related to the edit box. If there actually is a problem, what if the event was set on a parent element, and event capturing was used? —Daniel Vandersluis^(talk) 00:53, 7 March 2007 (UTC)

[edit] An older proposal

I guess it's a good time to point to an older proposal of mine, MediaWiki talk:Edittools/Archive 3#Replacing charinsert with dynamic JavaScript. It does not use AJAX; instead, the list of characters is inlined on the Javascript file itself, which should be much more compatible (and after being loaded behaves exactly like the old implementation; the only disadvantage is a small amount of flicker). It was not accepted because there was no MediaWiki:Common.js at the time, which would be needed to make it work on all skins. --cesarb 22:27, 6 March 2007 (UTC)

I second dynamic Javascript proposal. I've been having this idea myself for some time.

For the reference: today's AJAX code could use functionality in ajax.js and use &action=rawrender (corrected later) instead of downloading the whole Edittools page.

Btw, any other comments on page compression?

— Alex Smotrov 22:37, 6 March 2007 (UTC)

See http://lists.wikimedia.org/pipermail/wikitech-l/2007-February/thread.html#29440. —Ruud 22:55, 6 March 2007 (UTC)

[edit] Fallback?

What are your proposals for fallback for those with JS disabled, or even for browsers without JS at all? Any solution without such plans is unacceptable. HTH HAND —Phil | Talk 07:05, 8 March 2007 (UTC)

Charinsert doesn't work without JS anyway. —Ruud 10:57, 8 March 2007 (UTC)

As Ruud just said, there is no need for a fallback, since the edit tools already do not work (and cannot work) without Javascript. --cesarb 14:06, 8 March 2007 (UTC)

[edit] Proposal: Editpage.js

Create another «common» javascript file MediaWiki:Editpage.js and «call» it from MediaWiki:Common.js (already implemented e.g. in pl:MediaWiki:Monobook.js and ru:MediaWiki:Common.js: search for "Onlyifediting.js")

if (document.URL.indexOf('action=edit') > 0 || document.URL.indexOf('action=submit') > 0)
  importScript('MediaWiki:Editpage.js');

Then move from MediaWiki:Common.js → MediaWiki:Editpage.js

• code «Extra toolbar options» (mwCustomEditButtons)
• code «fix edit summary prompt for undo»

— Alex Smotrov 20:47, 8 March 2007 (UTC)

[edit] Proposal: Edittools with Javascript

Replace all those <a … onlcick=InsertTags lines now generated from MediaWiki:Edittools with javascript code inside MediaWiki:Editpage.js. Sample version of this code: User:Alex Smotrov/createEditTools, see discussion page for instructions on how to test it. Advantages:

• ease of removing (not just hiding) unnecessary characters and adding your own
• Js code is about 10 times smaller
• Js code should be cached by browser because it's a separate file

— Alex Smotrov 20:47, 8 March 2007 (UTC)

Great idea! I like the js, but I have one idea. Once we're doing this, why don't we have a drop-down menu like at commons:? —METS501 (talk) 21:03, 8 March 2007 (UTC)

Question: What happens for users with javascript disabled? Prodego ^talk 19:23, 18 March 2007 (UTC)

The edit tools don't appear. Since clicking on them relies on JavaScript anyways, this is not a problem. It's actually better than the current situation since right now the tools show up if you don't have JS enabled, but they don't actually work. Mike Dillon 19:44, 18 March 2007 (UTC)

[edit] notcollapsed class in collapsible tables and navframes

Tables and navframes have collapsed and autocollapse classes, but what about a notcollapsed class that would specify to keep that specific table or frame open by default on a page, but still allow it to be closed. This would come in handy for the Climate Statistics box on Denver, Colorado (we could leave one of the boxes open by default, but have the other three collapse) and the behavior is not unprecedented (Table of Contents allows show/hide and defaults to open). --MattWright (talk) 18:36, 21 March 2007 (UTC)

Just give it the collapse class, without specifying collaped or autocollapse. —Ruud 10:31, 22 March 2007 (UTC)

Thanks for the reply Ruud. --MattWright (talk) 17:27, 22 March 2007 (UTC)

[edit] Tooltip for dismiss watchlist link

How about adding a "title" attribute to the dismiss watchlist link to create a tooltip:

ButtonLink.setAttribute( "title", "Hide watchlist message for one week" );

This way, normal users have a chance of seeing that "dismiss" will hide the message for one week, instead of blindly clicking on it (or avoiding it for fear of permanently dismissing the message). What would be really cool would be to make the message dismiss until the text was changed. This would be pretty easy to do if there was a built-in MD5 function or some other sort of hash or checksum derived from the message that could be used as the value of the cookie instead of "yes". That way the code could tell if the message that was dismissed was the same as the current message. Mike Dillon 14:09, 31 March 2007 (UTC)

Admins tend to tweak the message several times while it is displayed so that approach would likely not be very effective. Adding a unique id/class for each different message might work, though. —Ruud 16:37, 31 March 2007 (UTC)

[edit] Query strings

I have made a querystring function in my morebits.js, wonder if you think it should be included here? _→AzaToth 19:45, 1 April 2007 (UTC)

/**
* Maps the querystring to an object
*
* Functions:
*
* QueryString.exists(key)
*     returns true if the particular key is set
* QueryString.get(key)
*     returns the value associated to the key
* QueryString.equals(key, value)
*     returns true if the value associated with given key equals given value
* QueryString.toString()
*     returns the query string as a string
* QueryString.create( hash )
*     creates an querystring and encodes strings via encodeURIComponent and joins arrays with | 
*
* In static context, the value of location.search.substring(1), else the value given to the constructor is going to be used. The mapped hash is saved in the object.
*
* Example:
*
* var value = QueryString.get('key');
* var obj = new QueryString('foo=bar&baz=quux');
* value = obj.get('foo');
*/
function QueryString(qString) {
 this.string = qString;
 this.params = {};

 if( qString.length == 0 ) {
 return;
 }

 qString.replace(/\+/, ' ');
 var args = qString.split('&');

 for( var i in args ) {
 if( typeof( args[i] ) != 'string' ) {
 continue;
 }
 var pair = args[i].split( '=' );
 var key = decodeURIComponent( pair[0] ), value = key;

 if( pair.length == 2 ) {
 value = decodeURIComponent( pair[1] );
 }

 this.params[key] = value;
 }
}

QueryString.static = null;

QueryString.staticInit = function() {
 if( QueryString.static == null ) {
 QueryString.static = new QueryString(location.search.substring(1));
 }
}

QueryString.get = function(key) {
 QueryString.staticInit();
 return QueryString.static.get(key);
};

QueryString.prototype.get = function(key) {
 return this.params[key] ? this.params[key] : null;
};

QueryString.exists = function(key) {
 QueryString.staticInit();
 return QueryString.static.exists(key);
}

QueryString.prototype.exists = function(key) {
 return this.params[key] ? true : false;
}

QueryString.equals = function(key, value) {
 QueryString.staticInit();
 return QueryString.static.equals(key, value);
}

QueryString.prototype.equals = function(key, value) {
 return this.params[key] == value ? true : false;
}

QueryString.toString = function() {
 QueryString.staticInit();
 return QueryString.static.toString();
}

QueryString.prototype.toString = function() {
 return this.string ? this.string : null;
}


QueryString.create = function( arr ) {
 var resarr = Array();
 for( var i in arr ) {
 if( typeof arr[i] == 'object' ){
 var v =  Array();
 for(var j in arr[i] ) {
 v[j] = encodeURIComponent( arr[i][j] );
 }
 resarr.push( encodeURIComponent( i ) + '=' +  v.join('|')  );
 } else {
 resarr.push( encodeURIComponent( i ) + '=' + encodeURIComponent( arr[i] ) );
 }
 }

 return resarr.join('&');
}
QueryString.prototype.create = QueryString.create;

Looks great, but do we really need it? It's long, and each load is an unnecessary drain on the servers if its relatively unused. —METS501 (talk) 20:03, 1 April 2007 (UTC)

I don't know how much extra load it will generate to just load the script, but it won't execute anything unless used. _→AzaToth 20:05, 1 April 2007 (UTC)

I was referring to the load from loading it. It's 2,837 bytes, which means over millions of loads, it starts to add up. See [1] for the server breakdown: css and js eat almost as much bandwith as pure article views. —METS501 (talk) 20:10, 1 April 2007 (UTC)

That are only the static CSS and JS files, not ones editable on-wiki. No idea if those significantly contribute to the bandwidth usage as well? —Ruud 21:02, 1 April 2007 (UTC)

What does it do? At first glance it doesn't seem to have any use outside of other user-scipts (which can just as easily import it themselves.) —Ruud 21:02, 1 April 2007 (UTC)

Also, does Common.js really need OOP techniques? The smaller is the better, imho — Alex Smotrov 21:29, 1 April 2007 (UTC)

That's just a minor thing, the idea first is to only parse the query string once. second point is to use correct encoding, as some has been using wrong function for that (window.escape()), and to do it transparent. _→AzaToth 21:34, 1 April 2007 (UTC)

For something unlikely to be used often, wouldn't it be just as well to put the burden on the client side (extra parsing) rather than on the servers (extra bandwidth for longer code)? See below (obviously just an example). --Splarka (rant) 07:18, 2 April 2007 (UTC)

function queryString(p) {
    var re = RegExp('[&?]' + p + '=([^&]*)');
    var matches;
    if (matches = re.exec(document.location)) {
        try { 
            return decodeURI(matches[1]);
        } catch (e) {
        }
    }
    return null;
}

The above is basically from Lupin's popups, no? Or somewhere else before that, given the nature of much javascript code. Now, my opinion really doesn't matter here (not really that professional a javascript coder), but it might be useful to have one standardized function related to query strings, since a lot of scripts need them, and said scripts have their own query functions. So if those scripts are used together, you have (possibly) three or four query string functions altogether, which doesn't strike me as that efficient. Creating and getting query strings sounds useful; the rest, not as much. Gracenotes^T § 14:29, 2 April 2007 (UTC)

As WP:TW is probably the only script as of yet using QueryString (by some freak coincident), the number of calls to QueryString as of yet is 59 times. _→AzaToth 14:45, 2 April 2007 (UTC)