MediaWiki talk:Common.js/Archive 12

Log page field labels

Perhaps there have been more people than me feeling that the field labels on the Special:Log doesn't always fit. I propose following script, that will update the field names according to the wanted action, at the moment, only for block is changed, but it's easy to update for the other actions also. _→AzaToth 01:18, 2 November 2007 (UTC)

if( wgCanonicalSpecialPageName == 'Log' ) {
	var form = document.forms[0];
	var labels = form.getElementsByTagName( 'label' );

	// Save the given text from the beginning, first one is the "user" field, and the nect one is the "page" field;
	var old = {};
	old.user = labels[0].textContent;
	old.page = labels[1].textContent;
	var logLabelCallback = function logLabelCallback( event ) {
		var form = event.target;
		var value = form.type.value;
		labels = form.getElementsByTagName( 'label' );

		switch( value ) {
		case 'block':
			labels[0].textContent = 'Blocker:';
			labels[1].textContent = 'Blockee:';
			break;
		default:
			labels[0].textContent = old.user;
			labels[1].textContent = old.page;
			break;
		}
	}

	// We add an event listener to the callback in the form element
	form.addEventListener( 'change', logLabelCallback, false );

	// to make it "pop up" on load, we initiate an change event
	var evt = document.createEvent( "Event" );
	evt.initEvent( 'change', true, true );
	form.dispatchEvent( evt );
}

1) I don't think it's important enough to warrant a script; 2) this would break interface for users with custom language in preferences; 3) stop trying to make Common.js IE-incompatible, you've yet to come back and fix Sysop.js :) ∴ AlexSm 04:22, 2 November 2007 (UTC)

Agree with Alex, this adds way to much code for such a minor fix. This sohuld just be fixed in MediaWiki instead. —Ruud 16:32, 2 November 2007 (UTC)

SVG support for old browsers

I've noticed a problem with the way SVGs are rendered for browsers that don't support SVG, e.g. IE6 under WinXP. When I right-click a JPG embedded in an Wikipedia article, the pop-up menu gives me the option to "Open in New Window". But for a SVG, that option isn't there: the browser hasn't recognised that there's a link to follow (even though I can left-click and follow the link). Is this something that could be fixed? --Dr Greg 12:45, 2 November 2007 (UTC)

For our browsers Mediawiki converts all SVGs into PNGs. The problem you described is due to "PNG transparency fix for IE6" which is implemented right here in Common.js (see old dicsussions above and in archives) ∴ AlexSm 13:31, 2 November 2007 (UTC)

It's a side-effect of the PNGFix script; PNG (and SVG rendered as PNGs) are converted to SPANs in order to display thransparency correctly, which affects the right-click menu. The link still works though. To open it in a new windows, shift-click the image. — Edokter • Talk • 15:27, 2 November 2007 (UTC)

The best solution here would be to upgrade to Internet Explorer 7 or use a different browser such as Firefox or Opera. Unfortunately, we can't fix the rendering bugs in IE6; we can only work around them with imperfect results. —Remember the dot ^(talk) 20:15, 2 November 2007 (UTC)

So, just for curiosity sake, will it be possible to fix this in the future? --Siva1979^{Talk to me} 14:35, 4 November 2007 (UTC)

Just so you know (and I'm not saying you don't), Remember the dot, there are many people who regularly view and contribute to Wikipedia using public access computers (myself included) that have IE 6.0 or earlier on them. The people using these computers usually don't have the necessary permissions to upgrade or switch to a different browser, and those that do usually lack the technical knowledge or inclination to upgrade the computers themselves. Therefore, just telling us to "upgrade or switch" is hardly an acceptable solution. --Dinoguy1000 ^Talk 19:16, 5 November 2007 (UTC)

Which is why we've implemented an IE6-specific workaround in the first place ;-)

The best solution would be to upgrade or switch, but since this isn't always possible, we've implemented a workaround. The downside to the workaround is that the right-click menu doesn't work as well as it did before. But, once you click onto the original image file itself, [1] for example, you should be able to download the file without trouble.

I don't know of any way to improve this behavior on IE6; it seems to be an unavoidable consequence of the workaround making the images display correctly in the first place. —Remember the dot ^(talk) 19:29, 5 November 2007 (UTC)

Perhaps a transparent element could be inserted so that IE6 will see there's a link? Shinobu (talk) 08:39, 17 November 2007 (UTC)

Could anyone look into fixing this once again? The need of some IE6 users for transparency of PNG images in Wikipedia is trivial compared to the ability to be able to browse conveniently with only a mouse.

PngFix change for customized security settings

It has come to light at Wikipedia:Village pump (technical)#One of Wikipedia's built-in scripts causes a JavaScript error that the PngFix workaround for IE6 causes an exception when the security setting "Binary and script behaviors" is set to "Disable". To fix it, I propose that the first line of the PngFix function be changed from:

    if (document.body.filters && !window.PngFixDisabled)

to

    try
    {
        if (!document.body.filters)
        {
            window.PngFixDisabled = true
        }
    }
    catch (e)
    {
        window.PngFixDisabled = true
    }
    if (!window.PngFixDisabled)

This ought to resolve the problem. I don't want to put the entire function body inside a try/catch block because then any errors that occur within the function would become invisible. Any thoughts? —Remember the dot ^(talk) 00:09, 17 November 2007 (UTC)

That would execute a try/catch block for each png image... I'm not sure I like the implications of that. I'm still not sure what exactly causes the exception (haven't found that option yet), but if it's the combination of 'document.body.filters' and 'windows.PNGFixDisabled', we should simply move the document.body.filters check to the version check below. — Edokter • Talk • 00:21, 17 November 2007 (UTC)

That will not execute try/catch for each image. I think the code is okay. Minor note: you don't have to use window.PngFixDisabled first two times, and personally I don't like when { } are used when they are not needed ∴ AlexSm 00:24, 17 November 2007 (UTC)

Oops! You're right. But I'd still like to find this option first before doing anything... If a simple switching oprands could fix the problem, we don't need a try/catch at all. — Edokter • Talk • 00:30, 17 November 2007 (UTC)

About using { } when they are not strictly needed: personally, I prefer it, so I'd rather just leave them in. —Remember the dot ^(talk) 01:14, 17 November 2007 (UTC)

We can't combine the document.body.filters check with the browser version check because document.body does not yet exist when the browser check is run. The document.body.filters check must happen later. —Remember the dot ^(talk) 01:14, 17 November 2007 (UTC)

Edokter, you have to stop jumping to conclusions. A simple switch of operands won't solve the problem, it was just a suggestion to prevent the exception from being thrown at all if window.PngFixDisabled was true. Anyway, I like the version above better because it doesn't place the try-block around all the code but just around the test, and because it sets window.PngFixDisabled it is guaranteed to result in the same behaviour which is a good thing too. I would again like to thank you all for looking into this: thanks a lot! Shinobu (talk) 08:36, 17 November 2007 (UTC)

 Done That setting must be an IE6 SP2 specific option, because I can't find it (IE6 SP1). — Edokter • Talk • 12:51, 17 November 2007 (UTC)

The error is gone now. Thanks again! Shinobu (talk) 14:21, 17 November 2007 (UTC)

Watchlist show/hide code

I've implemented new code that allows the watchlist show/hide function to be able to use multiple messages and be reset when needed. The actual code was written by User:Splarka; the relevant MediaWiki message is MediaWiki:Watchlist-details. The implementation is a little dirty; if any one can improve it, please don't hesitate to do so. --MZMcBride (talk) 18:13, 17 November 2007 (UTC)