Jump to content

MediaWiki talk:Common.js/Archive 18

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< MediaWiki talk:Common.js
This is an old revision of this page, as edited by MiszaBot II (talk | contribs) at 08:40, 26 July 2010 (Archiving 2 thread(s) from MediaWiki talk:Common.js.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 15Archive 16Archive 17Archive 18Archive 19Archive 20→Archive 23

Always secure Wikipedia

proposal it so add 

if(wgServer == 'https://secure.wikimedia.org')
importScript( 'MediaWiki:Common.js/secure.js')

This changes any http links to interwiki or diffs on a page to links for the secure server. The script is originally User:Anakin101/alwayssecurewikipedia.js. —TheDJ (talk • contribs) 20:45, 17 January 2010 (UTC)

Go for it, imo. If you're on the secure wiki, you should stay there until you leave it, not because you've clicked a random link. Ale_Jrbtalk 20:56, 17 January 2010 (UTC)
I found issues and suggestion with the script http:\/\/([^\/]+?)\. should be http:\/\/([^a-z0-9\-]+?)\., change (page ? page : 'wiki/') to (page || 'wiki/'), \/? is unnecessary since browser automatically add this in (I think), if (sub === undefined) continue; seems to be in the wrong place. There one question, should this be supporting old links? Wikibooks use to be en.wikibook.com (no s), wikipedia.com/wiki/ redirects to the English Wikipedia, meta-wiki was meta.wikipedia.org. — Dispenser 07:43, 18 January 2010 (UTC)
I wouldn't rely on all browsers always appending a slash to URLs like http://en.wikipedia.org. Better to be safe than sorry. However, I don't think the script as written will correctly handle such valid (or at least working) URLs as http://en.wikipedia.org?title=Foo. To fix it, you could replace "\/?(.*)$" with e.g. "(\/[^?#]*|)([#?].*|)$" in the regexps and append the value of m[4] to the fixed URL unconditionally. Also, there should be some way (e.g. setting window.disableSecureLinks=true in their monobook/vector.js) for users to turn this script off if they don't want it.
Anyway, the one problem we can't fix is that one could still end up back on the insecure site in two clicks via another Wikimedia project which doesn't run this script. That's why I wrote my version as a Greasemonkey user script. Of course, merely fixing things like diff links to en.wikipedia.org itself would probably be worth having this for. —Ilmari Karonen (talk) 16:36, 18 January 2010 (UTC)
Yes please add it, we need something like this. And here's some notes and links:
When I created {{sec link auto}} I also tested User:Anakin101/alwayssecurewikipedia.js. I noticed that the script doesn't handle all the cases that {{sec link auto}} handles. I'll see if I can dig up my notes or do the tests again, but here's what I remember:
  • I think it doesn't handle all the projects listed at Wikipedia:InterWikimedia links, especially it didn't handle links to oldwikisource:. "Old Wikisource" still handles many of the Wikisource languages, so it isn't really "old".
  • And it doesn't handle cases like wikt:pt:São Paulo the way I think they should be handled. The script sends you to the English Wiktionary with a secure link, then it lets Wiktionary resolve the "pt:" part to take you to the Portuguese Wiktionary, which sends you to the normal servers. {{sec link auto}} instead resolves both the "wikt:" and "pt:" parts and gives you a secure link directly to the Portuguese Wiktionary. Although I cheat in {{sec link auto}}, I let the humans manually feed "lang=pt" so my template doesn't need to know the site matrix.
I'm sorry that I don't know enough javascript, so I can't help out with the code. But taking a look at {{sec link auto}}, or more specifically its sub-template {{sec link/secure url}} might give you some useful hints about what to resolve.
--David Göthberg (talk) 17:48, 18 January 2010 (UTC)
I have made a whole set of improvements. Many more types of links should now be recognized (at least all valid links in User:TheDJ/Sandbox2). Feedback welcome. —TheDJ (talk • contribs) 21:31, 18 January 2010 (UTC)
This seems reasonable to me to implement. I wish there were a way for this to be implemented into core MediaWiki, but that doesn't seem very possible due to parser cache issues (at least for the time being). --MZMcBride (talk) 00:30, 19 January 2010 (UTC)

 Done code deployed. —TheDJ (talk • contribs) 20:44, 21 January 2010 (UTC)

JavaScript Loading

Up in the "WikiMiniAtlas" discussion it was mentioned that "(All our other special scripts are only loaded when needed.)." I'm getting ready to implement a lot of JavaScript on my Wiki and I was just curious if this was simply a reference to doing a quick getElementById existence check in addOnloadHook for each script, or if there is some other system in place that I don't know about. I'm basically just trying to make sure that if I have 100 scripts, I don't have to do 100 checks on every page load to see if any of them apply to that page.
--Cogniac (talk) 18:11, 29 January 2010 (UTC)

simply a reference to doing a quick getElementById existence check would be my answer. But there is a more advanced scriptloader system in the making by Michael Dale. Check the Wikitech mailing list archives for details.
--Dschwen 20:43, 29 January 2010 (UTC)
I tracked this down to here: http://www.mediawiki.org/wiki/JS2_Overview in case anyone else is interested. They seem to be developing this for the upcoming 1.16 release.
--Cogniac (talk) 19:16, 4 February 2010 (UTC)

Proposal to add "withJS" feature to Common.js

Wikimedia commons has the following function in their MediaWiki:Common.js. This is useful for doing feature preview links like timed text preview. Any objections to adding the following? 

/** &withJS= URL parameter *******
 * Allow to try custom scripts from MediaWiki space 
 * without editing [[Special:Mypage/monobook.js]]
 */
var extraJS = getParamValue("withJS");
if ( extraJS && extraJS.match("^MediaWiki:[^&<>=%]*\.js$") ) {
  importScript(extraJS);
}

mdale (talk) 22:42, 4 February 2010 (UTC)

Its usage will probably be pretty limited, since for security reasons it seems to be limited to only load scripts from the MediaWiki space. I think I slightly agree with this addition, but I have doubts since its usage is so limited and the code will be loaded by all users and most of those that "need" this functionality can just as well edit their personal /monobook.js. Although I see that this function can be useful for demonstration purposes when testing new scripts.
Platonides isn't the maintainer here, unless you have asked him. Here's a cleaned up version of the code: ( above )
Could someone who understands the code in the .match() part check what that code means and that it only allows loading scripts from MediaWiki space?
--David Göthberg (talk) 16:17, 5 February 2010 (UTC)
Is alert() preferred to a silent failure? --MZMcBride (talk) 16:35, 5 February 2010 (UTC)
I think the alert is useful, but not especially necessary. The alert is only shown when an invalid script name like "User:Example/myscript.js" is used. Unfortunately the alert does not show if the name is a correct but non-existing MediaWiki file name, then it silently fails which is slightly confusing.
But MZMcBride has a point. This will probably be a seldomly used function and all users always load those lines of code, so let's remove the alert to save some lines of code. I have updated my above code.
And I have read up on regular expressions and done some testing, the code in the .match() part does exactly what it should.
--David Göthberg (talk) 17:08, 5 February 2010 (UTC)
I agree with the removing the alert ( its of little value ). If people are happy with it in its present form I suggest a maintainer of Common.js plops it in there. ( I have updated the discussion to just focus on the recommended code addition) --mdale (talk) 22:28, 6 February 2010 (UTC)
I have no problem with this. I can deploy it tomorrow when I get back home, or someone else can do it in the meantime. —TheDJ (talk • contribs) 13:03, 7 February 2010 (UTC)
any updates on this? --mdale (talk) 17:39, 10 February 2010 (UTC)
I have now deployed this code. Thanks for the watchlist bump :D —TheDJ (talk • contribs) 18:15, 10 February 2010 (UTC)
OK, that was not fun. I'm so used to getParamValue being available (either trough commons or Navigation popups) it didn't occur to me it would be missing. For now I have deployed a getURLParamValue(), since i wasn't sure about potential conflicts with other tools that have their own getParamValue. I think those implementations are pretty consistent, but I'll want to run a check on that before using that name in Common.js. In the future we can use ParseURI, once the new JS2, jquery and mwEmbed tools are finally fully deployed, but that is not an option at this time of course. —TheDJ (talk • contribs) 18:49, 10 February 2010 (UTC)

Potential security issue

While, I'm sure that whoever runs http://toolserver.org/~para/geoip.fcgi is perfectly trustworthy it seems like a very weak link in the chain. Whereas scripts from Wikipedia have high cache values, publicly viewable edit histories, and notify many people when they are modified; making it likely that malicious changes can be reverted without too much damage; a modification to this script could pass unnoticed for quite some time. Are there any mechanisms in place to prevent this being horribly abused? Conrad.Irwin (on wikt) 22:55, 4 February 2010 (UTC)

As you say, the assumption that toolserver users are trustworthy. Javascript is by its very nature a potential security issue. Happy‑melon 23:45, 4 February 2010 (UTC)
It's not as if we allow just any external script to be included. So far those are only WikiMiniAtlas and the geolocating script. Those are maintained by trusted users on the toolserver. Users who have been around for a LONG time and who are not likely to go rogue. But it's like Happy-Melon says. —TheDJ (talk • contribs) 13:01, 7 February 2010 (UTC)
It took me some searching to find out what this is about, so in case anyone else is wondering: That toolserver script is called from the beginning of MediaWiki:Common.js/watchlist.js, the result of that then seems to be used in MediaWiki:Geonotice.js to display some watchlist notices only in some parts of the world. A little more searching turned up Wikipedia:Geonotice. (I have now added a code comment to watchlist.js and a page notice to Geonotice.js explaining what it is.)
--David Göthberg (talk) 01:00, 5 February 2010 (UTC)

hasClass

The hasClass function...variable...thing uses some fairly advanced JavaScript that I'm just trying to figure out. I'm assuming that the reason it is set up as a variable and not just straight "function hasClass(className)" is part of the caching optimization. But I'm not getting how it basically amounts to "var hasClass = ()();" with stuff happening inside the first pair of parentheses. I have no idea what the deal is with the two pairs of parentheses or why it relies on an anonymous function inside an anonymous function to do the work, and I'm looking for a basic explanation, if anyone would be so kind.
--Cogniac (talk) 21:19, 12 February 2010 (UTC)

The outer anonymous function, which is immediately called, creates a "global" variable reCache and returns another function which is assigned to the name hasClass. Due to JavaScript's scoping rules reCache is now only accessible from hasClass, but it's value still persists over multiple invocations of hasClass.
—Ruud 15:37, 13 February 2010 (UTC)
I understand that it's a prime example of JavaScript closures, but what I truly don't understand is the second set of parentheses at the end. I have no clue why those are necessary and/or don't break everything. I can't find any JavaScript construct that requires such a thing.
--Cogniac (talk) 20:49, 16 February 2010 (UTC)
It's a plain function call (of the outer anymous function). So hasClass is equal to the return value of the outer function (which happens to be the inner function). Without that call hasClass would be a reference to the outer function itself, which is not the intention.
—Ruud 21:19, 16 February 2010 (UTC)
Ahhhh. I get it now. It's like a standard function execution call, except the first set of parentheses stands in for the name of the function. var myVar = myFunction(); => var myVar = (function() { do stuff })();
--Cogniac (talk) 22:27, 18 February 2010 (UTC)
Actually, the first set of parenthesis just stand for the parameters (none in this case) and there is no function name before the parameters because it's anonymous.
—Ruud 12:53, 19 February 2010 (UTC)
Well, based on that explanation, none of it makes any sense anymore. It would essentially be var myVar = myFunction(parameters go here)(what the hell are these parentheses for?); => var myVar = (supposedly there are no parameters, despite the fact that there's stuff in here)(still no idea what these parentheses are for); I thought that the first set of parentheses just grouped the outer anonymous function and the second set of parentheses was a call to execute that function.
--Cogniac (talk) 19:01, 26 February 2010 (UTC)

Custom Edit Buttons

I'm trying to implement some custom edit buttons on my Wiki. They work, but only when placed in Common.js. I cannot get them to work when they are placed on Common.js/edit.js like they are here. I stuck an alert() call in my Common.js/edit.js to see if it was even being loaded, and it's not. Comparing my wikibits.js with Wikipedia's wikibits.js, and thus my importScript() with Wikipedia's, I notice the following differences:

  1. Mine: var uri = wgScript + '?title=' + encodeURIComponent(page.replace(/ /g,'_')).replace('%2F','/').replace('%3A',':') + '&action=raw&ctype=text/javascript';
  2. Wikipedia: var uri = wgScript + '?title=' + encodeURIComponent(page.replace(/ /g,'_')).replace(/%2F/ig,'/').replace(/%3A/ig,':') + '&action=raw&ctype=text/javascript';

Could these subtle differences somehow be causing my problem?
--Cogniac (talk) 20:43, 26 February 2010 (UTC)

I think it's more likely that you just don't have the edit.js loader code in your Common.js. Look under the comment "/* Import more specific scripts if necessary */" of wikipedia's Common.js. —TheDJ (talk • contribs) 21:20, 26 February 2010 (UTC)
I already had the importScript calls in Common.js, but it still wasn't working. Unfortunately, after wandering off for a few days and coming back, I have a bunch of messages from contributors about a certain "alert()" call I left in Common.js/edit.js when I thought it wasn't working at all. Apparently it just wasn't working in IE7 for some reason. So now there's double the number of buttons (because I had put it back in Common.js and left what I thought was a non-working copy in /edit.js) and a JavaScript alert() box popping up on every edit. Oops. So...perhaps there is an issue with IE7? I only have IE8 on this box, so I will check this out tomorrow on an IE7 box and report back.
--Cogniac (talk) 04:58, 1 March 2010 (UTC)
Well, now it magically works in IE7, too, so I don't really know what to say. Perhaps it was some bizarre caching issue? Although, I was definitely hitting Ctrl+F5 after every time I edited the JavaScript, so I don't even know.
--Cogniac (talk) 13:59, 1 March 2010 (UTC)
The problem is called a browser cache :D WP:BYPASS. —TheDJ (talk • contribs) 14:02, 1 March 2010 (UTC)
A thing which I repeatedly cleared by hitting Ctrl+F5; a circumstance I clearly stated in my last comment. I guess I needed to "Completely clear the cache" instead. Which makes no sense, because every time before now when I've made an edit to the JavaScript, Ctrl+F5 worked perfectly. For some reason, this did not work with the creation of Common.js/edit.js. I have no idea why.
--Cogniac (talk) 15:11, 1 March 2010 (UTC)
I'm not sure if it's because I'm editing the edit bar, or because I'm doing it on Common.js/edit.js, but it seems as though you have to Ctrl+F5 + Completely clear the cache + close and reopen the browser to get it to refresh properly. Wacky.
--Cogniac (talk) 16:02, 1 March 2010 (UTC)

Collapsible rows and columns

I asked on Help whether Collapsing could be extended to cover certain rows and columns only. Then I realized I hadn’t anything to do for the rest of the day and wrote the code myself. It may need further testing (and perhaps optimizing), but the basic cases are covered alright. Collapsing columns is especially helpful for en.m.wikipedia.org. Is there any chance getting this into common.js? — Christoph Päper 11:33, 6 March 2010 (UTC)

Rank in sortable tables

On a related note to collapsible rows and columns above, it would be nice to have a class ‘rank’ on one heading cell in a ‘sortable’ table that would result in the cells below it – if they contain only whitespace, digits and punctuation – bearing a dynamically generated rank number which is updated on sorting (and perhaps restored on sorting based on that very column, otherwise ‘rank’ should imply ‘unsortable’). The workaround with two tables side by side (inside a third one) is really ugly and fails with rows of different height. — Christoph Päper 15:21, 2 March 2010 (UTC)

Update getURLParamValue per Commons common.js User:Lupo cleanup

This is essentially the same function but includes the # hash to not include #anchors when you getURLParamValues 

function getURLParamValue( paramName, url) 
{
 if (typeof (url) == 'undefined' || url === null) url = document.location.href;
 var cmdRe=RegExp( '[&?]' + paramName + '=([^&#]*)' ); // Stop at hash
 var m=cmdRe.exec(url);
 if (m && m.length > 1) return decodeURIComponent(m[1]);
 return null;
}

mdale (talk) 20:41, 3 March 2010 (UTC)

Ah, you see, this is exactly why I wanted to separate getParamValue of Lupin from this one in Common.js, now we have differing implementations... Thanks for the notification ! —TheDJ (talk • contribs) 21:25, 3 March 2010 (UTC)

Adding a script to collapse template transclusion list

Please see Wikipedia:Village_pump_(proposals)#Collapse_template_transclusion_list_in_Edit_view. I'm not quite sure if the script is ready - I had some problems last time I used it and had to uninstall. But is this reasonable in principle? Rd232 talk 20:00, 8 April 2010 (UTC)

It probably needs a bit more work, but I think that in general we should consider this. —TheDJ (talk • contribs) 20:33, 8 April 2010 (UTC)

Frame breaking

Moved from WP:AN Happy‑melon 11:24, 13 April 2010 (UTC)

I know we once blocked a system that iframed wikipedia for it's own purposes. There is now this "ad service" http://www.magic-banner-bot.com/ which inserts images into wikipedia. It cannot be disabled, uses an iframe and insert ads into the wikipedia content, without explaining why. I think such is grounds for blocking that via Javascript. What do others think ? —TheDJ (talk • contribs) 00:35, 11 April 2010 (UTC)

I thought we already did break iframes thanks to that advertising agency that was framing Wikipedia as a part of their homepage. If we don't, then yes, we absolutely should. Of course any webmaster who purchases a spamming tool that requires disclosing their webserver FTP password to work deserves to lose at life generally. — Gavia immer (talk) 01:01, 11 April 2010 (UTC)
??? Can you block people from reading wikipedia? 'Cause all that script is doing... Choyoołʼįįhí:Seb az86556 > haneʼ 02:57, 11 April 2010 (UTC)
What you can do is use Javascript to detect if the page is being served in a third-party iframe, and if it is, redirect to the Wikipedia page itself with no iframe. This won't stop anyone from reading Wikipedia, but it will prevent them from being forced to view a defaced version of our content. N.B., I haven't been able to force the "magic banner" to actually advertise to me, despite turning off many layers of anti-advertising protection, so I can't tell exactly how it's supposed to work; if it's just accomplished by redirecting through the web domain above, it's even simpler to block, since we could just detect the referer. — Gavia immer (talk) 03:18, 11 April 2010 (UTC)
I don't know much about this, but it looks like it simply creates a new webpage like http://magic-banner-bot.com/468/ . I see it says (Redirected from Banner ads), so apparently the subpage "468" is linked to what is now a redirect. Maybe that gives a clue on how it works... Choyoołʼįįhí:Seb az86556 > haneʼ 03:27, 11 April 2010 (UTC)
Yeah, but I'm not sure if that example is just a canned demonstration or if it's the way their spam works in general. — Gavia immer (talk) 03:44, 11 April 2010 (UTC)
Is this targeting specific pages, or all of Wikipedia in general? Noscript doesn't seem to be picking anything up, and I don't recall it doing so recently when viewing articles and/or other pages. The Thing // Talk // Contribs 04:25, 11 April 2010 (UTC)
Noscript detects it for me, but there seem to be two things going on. One is an IFRAME, which Noscript won't detect because it's just HTML, not a script of any kind; and an actual script which makes the banner that the IFRAME creates move around on the page and become generally more intrusive. I was actually looking at it with the script part turned off when I wrote what I wrote down below, confusing their banner with our own example banner, and didnt realize I was missing most of the effect until just now. —Soap— 17:48, 11 April 2010 (UTC)
An easy way to test would be to make an edit to the target article, then see if it shows up on the iframe. I'm going to do that now.— Dædαlus Contribs 06:32, 11 April 2010 (UTC)
Sadly, the test was .. well, I don't know if I could call it a success, or a failure, but the end result was certainly bad. It isn't a canned picture. It's a live frame of wikipedia. I made a small insertion of a period on that article, and refreshed the ad-bot page. The change was immediately visible. We have to find a way to prevent this.— Dædαlus Contribs 06:37, 11 April 2010 (UTC)
I think the way this software is supposed to work is that you, a blogger or other website designer, have to use "fake" links everywhere on your blog that go to sites that are technically still on your website, but look like they are where youre actually trying to go apart from the parasitic banner ads. I dont know from the context given on his site whether the ads will be served entirely through his own website and thus have the same referrer every time, or if youre supposed to store the ads somewhere else (in which case the referrer could be anything, or may not even exist). The code is ridiculously obfuscated, because according to the HTML source it's copyrighted and the designer of the software doesnt want people copying the source and using it without paying him. However, I think all we really need to know is whether it's an IFRAME, which it is. —Soap— 17:24, 11 April 2010 (UTC)
We appear to have disabled the javascript for breaking iframes about 3 years ago. Not sure why. Dragons flight (talk) 08:54, 11 April 2010 (UTC)
Well that's just evil. Both because it makes it look like various innocent websites are using banner ads and because he's charging $27 for a big-deal box of software that could fit on a floppy disk and is essentially just a few lines of obfuscated Javascript a script that generates HTML code, not really a "program" at all. I have seen other websites doing this sort of thing, though, and it's not always "bad". For about a year the homepage of Skittles (the candy) featured our article integrated into their website in a way that made it function as if it was part of Skittles' own site, but with a sort of navigation panel that made it clear that it wasn't, and that you could also see their pages on Facebook, YouTube, etc. At least to my eyes, there was no deception involved. There was also, amazingly, no spike in vandalism on our Skittles articles despite the fact that none of them were even semi-protected as far as I can tell. The Skittles homepage no longer features Wikipedia, but I think that it if we used to block out this sort of thing in the past, we must have stopped doing it sometime before Skittles started. If we start blocking it again, it'd be nice, if it is at all possible, to think about possible "legitimate" uses of the same kind of HTML trick. (While I wont say that the Skittles campaign necessarily did us any good, since we make no profits and kids eating candy arent likely to be big donors, it didnt really do us any harm either.) —Soap— 17:18, 11 April 2010 (UTC)
This discussion doesn't seem to concern admins. We aren't generally well versed in the technical aspects of the mediawiki software or these issues brought up here. These fixes would be nice, but if they are to be noticed by people who care, this discussion should be moved to WP:VPT and someone also should probably file a bugzilla request with the devs. --Jayron32 03:30, 12 April 2010 (UTC)
If we decided to break frames, we could do that locally with a few lines of javascript without needing to bother the devs. Dragons flight (talk) 05:42, 12 April 2010 (UTC)

The adding following code to Mediawiki:Common.js should do the trick: 

if (document.referrer.indexOf("magic-banner-bot.com") != -1) {
	location.href = "http://en.wikipedia.org/w/index.php?title=User:Chris_G/Leech_detected&action=render";
}

The user will see this page with instructions on how to navigate to Wikipedia directly (someone might want to edit that page to be a bit nicer/user friendly first though). I've tested the script and it works in Firefox + Opera, but if a Windows user would please check it in IE (the older the version the better :) ) that would be good. Javascript isn't my forte so if someone could please double check that it won't break the site etc that would be great (maybe we should move it into it's own function? make it easier to add more sites as they pop up?) --Chris 12:03, 12 April 2010 (UTC)

I just tried it in IE8 and it works. I'd suggest changing the order of the two bullet points - "adverts" first, "server load" second. JohnCD (talk) 20:38, 12 April 2010 (UTC)
I would like to point out that it is probably easy to obfuscate the referrer if the agency would like to do so and that any usage of what he is selling seems to require to run from the domain the user wants to use it on. We can also block all iframes of course, but i'm not sure if that is desirable. Not sure if there are any tools that use wikipedia in a frame. I guess we could start logging that information in a way, in order to find out...
if( window != top ) {
  // this window is run inside a frame
}
The above code should detect when a page is run inside a frame. —TheDJ (talk • contribs) 01:13, 13 April 2010 (UTC)
Just as a general note, that page would need to be moved into the project-space if this code were added. --MZMcBride (talk) 18:30, 13 April 2010 (UTC)

I'd definitely support breaking frames on a general basis, assuming we don't use frames legitimately ourselves, which I don't think we do. Thoughts? Happy‑melon 12:42, 13 April 2010 (UTC)

I can't think of anywhere that we use frames, and if we do we should possibly stop, and I support breaking all of them. Ale_Jrbtalk 13:02, 13 April 2010 (UTC)
Breaking frames will break Toolserver tools and maybe that Google translation tool. There's a reason why the built-in frame breaking script (wgBreakFrames) been turned off. — Dispenser 15:51, 13 April 2010 (UTC)
What toolserver tools rely on frames? Ale_Jrbtalk 15:55, 13 April 2010 (UTC)
If there is no damage to important toolserver tools, I support breaking frames. Snowolf How can I help? 15:59, 13 April 2010 (UTC)
Which toolserver tools are important? Arguably none since they would've been intergrated into MediaWiki. — Dispenser 18:12, 13 April 2010 (UTC)
<AryehGregor>	Happy-melon, it used to be always true. Non-configurably.
<Happy-melon>	until Dec 2006
<AryehGregor>	A few years ago the config option was added, set to false by default in case anyone actually wanted it.
<AryehGregor>	It's never been true on Wikimedia since it's existed AFAIK.

The only reason why $wgBreakFrames is disabled is that no one ever asked for it to be turned on. There's a whitelist built into it, which has Google translate exempted by default, and other exemptions can be added. What toolserver tools would break? Happy‑melon 16:15, 13 April 2010 (UTC)

Before rev:18220 it was stuck to on, no way of turnning it off. And the exception code used in that revision doesn't work since it would be a security risk. On the Toolserver tools:~flacus/IWLC/ uses it as does a new tool of mine. It also breaks most translation services (Google), image searches result page (Bing, Google). It seems the only reason why we are considering breaking the website is because an obscure scumbag is selling banner software (There's a precident). Yet we have taken no steps to break about.com's banner ads and the encourghed hotlinking of our images. — Dispenser 18:12, 13 April 2010 (UTC)
Wikipedia is one of the easiest sites to proxy in the world. You shouldn't be using frames. Nevertheless, those that do can be whitelisted. Ale_Jrbtalk 16:14, 14 April 2010 (UTC)
Toolserver tools are not allow to "serve significant portions of wiki page text", this includes proxying. — Dispenser 17:16, 14 April 2010 (UTC)

Breaking a specific site that's causing a demonstrable issue is one thing. Breaking all use of frames just because is another. There may be a case here for intentionally breaking this magic-banner site, as there was for breaking modernista. But I don't see any compelling case for breaking frames in general, especially as there's a not-remote possibility of collateral damage and unintended consequences. --MZMcBride (talk) 18:30, 13 April 2010 (UTC)

The case against isn't very compelling either - it stands at 'but gooooogle!' - which can be whitelisted (and yes, so can bing). Apart from the search engines, I can't see any valid reason for putting Wikipedia in a frame. The case for means preventing this type of stupid scam in the future, because it just won't work - what if a not-very-savvy person who thought 'oh, that sounds good' actually pays for this crap? They might deserve it, depending on your opinion, but I don't think we should make it possible. Nevertheless, it doesn't bother me a huge amount either way, but we probably should put a stop to this particular one whatever we decide. Ale_Jrbtalk 16:14, 14 April 2010 (UTC)
Oh, and while we don't make any major changes to protect potential foolish people, it is just a config option. In addition, people seeing the frame (plus advertising) might be put off Wikipedia, and less likely to visit/edit/donate in the future. Just a thought. Improbable, maybe, but possible. Meh. Ale_Jrbtalk 16:16, 14 April 2010 (UTC)
How exactly do you purpose to whitelist. Is the method compatible with anonymizers? Will the method work if the frameset is on a HTTPS connection? What will the collateral damage be of application that we don't know about? Wikipedia:Wikipedia CD Selection? Whitelisting would be larger and hard to manage than a blacklist method. — Dispenser 17:16, 14 April 2010 (UTC)
Considering the enormous impact Google's results have on visits to this site, I think it's a pretty legitimate concern that we don't intentionally break them. Whitelisting isn't the answer. Blacklisting is. You can't know if you're just going to break Google and Bing, you could very well break every other search engine (and a whole host of other things that we may or may not become aware of).
There are about a million ways to take content from Wikipedia and put it on your own site. Nobody here should think (or does think) that breaking frames is going to stop any leech with any sort of dedication. As I said, if there's a specific problem with a specific site, by all means, let's work to address that. But large-scale "solutions" that will likely do more harm than good should be avoided. --MZMcBride (talk) 17:21, 14 April 2010 (UTC)

Make it possible to collapse templates used and file usage

I propose to load User:TheDJ/usagecollapse.js on edit pages and file description pages. The script allows you to collapse the sections "File usage", "Global file usage" and "Templates used" on those pages. By default the sections are shown and you can press the show/hide element in front of them to hide them. This action is then remembered with a cookie. The three sections all have their own cookie. —TheDJ (talk • contribs) 14:35, 23 April 2010 (UTC)

Nothing ? No one has an opinion on this ? —TheDJ (talk • contribs) 00:45, 12 May 2010 (UTC)
Three more cookies for a single site and a trivial feature? Seems a bit much. Is there a better way to implement it? --MZMcBride (talk) 01:00, 12 May 2010 (UTC)
I don't think it's trivial. The list substantially clutters the edit screen on heavy pages. Rd232 talk 07:40, 12 May 2010 (UTC)
Clutters? It's at the bottom of the page, below the edit window, submit buttons, etc. I don't see the issue. --MZMcBride (talk) 03:49, 13 May 2010 (UTC)
I have to agree, it seems that we are trading scrolling for extra clicks and obfuscation. — Dispenser 05:00, 13 May 2010 (UTC)
Extra clicks only apply to people actually using the list. What proportion of people do? Now compare with the proportion of people who edit long articles, and are presented with this long list which prevents the edit box being at the bottom of the page, where it generally should be. On large pages the edit box may not even be visible at all after scrolling to the page bottom, because the template list is more than a screen high. That's confusing and annoying! And of course, the list does confuse newbies. They do end up clicking templates and doing all sorts of things that have no relevance - and the clicks must happen much more often than we see, because most of the templates are protected, so they end up frustrated without any visible evidence. I think at the very least the Usability Initiative ought to look into this as a matter of urgency, but given that we have the solution right here, I don't see why should wait. Also: nobody's ever made a convincing argument to me why we have this in the first place. The list itself seems useless qua list; its utility seems to be from providing links to viewing and editing the relevant templates. Except that nobody says "ooh, what templates are in this article that I can edit. I want to edit a template!" Instead they come across a template name in an article, and copy-and-paste the name into a search box and find it - same way they'd find anything else they don't recognise or know where it is. Seriously, what use is this list really? Is that use really so great that it must be shown in full (uncollapsed) on every edit screen? I say categorically no. Rd232 talk 06:29, 13 May 2010 (UTC)
The usability team already has looked at the template issue, their solution is to collapse it too. I think we should consider getting ride of it altogeather as it is inconsitent; only showing when previewing or do full page edit. (It should really say at some point "Preview to see a list of templates") And it includes every template subcalls made. We could also just put .templatesUsed into a scrollbox. However, my option on the File page still stands. — Dispenser 15:33, 13 May 2010 (UTC)
"The usability team already has looked at the template issue..." - link? I think getting rid of it requires more input than we've had so far, whereas merely collapsing it is hopefully not so controversial and certainly less dramatic. I'm not clear what your "File page" option is. You want a different behaviour in the File namespace? I have no objection to that; the main issue is for mainspace. Rd232 talk 16:17, 13 May 2010 (UTC)
usability:File:Design-EditToolbar-2.pdf show part of it. I'm having trouble finding the original mockup/proposal discussing it, on their site (they don't link or categorizes files). The script is for the File and main namespaces. — Dispenser 20:46, 13 May 2010 (UTC)
Cool! But in the mean time, I'll settle for TheDJ's script. Rd232 talk 21:14, 13 May 2010 (UTC)

Hide/Show button in rtl Wikipedia

I am looking for some help in resolving issues with the Hide/Show button for navigation boxes in the Yiddish WP, which uses an rtl orthography. I would expect the button to appear at the end of the line, that is on the left-hand side, but it appears at the beginning (on the right-hand side), for example here.

Another problem is with the appearance of the Hide/Show button in Beta (which uses the Vector skin). In this case the button attaches itself to the title of the box instead of appearing at one end of the title bar.

Any suggestions for clearing this up? --Redaktor (talk) 22:04, 3 May 2010 (UTC)

The quick way, in your MediaWiki:common.css, set .NavToggle to float left instead of right. The better way is to add something like body.rtl .NavToggle { float:left; } but I haven't tested that. As a matter of fact, we should probably setup some rtl CSS on the English Wikipedia as well.... I'm not really seeing the Vector issue... I note you guys use NavFrame instead of collapsible tables. It might have to do something with that, I don't think the NavFrame was tested a lot with Vector yet. —TheDJ (talk • contribs) 22:46, 3 May 2010 (UTC)
Many thanks for that valuable suggestion. (The first didn't seem to work, but body.rtl .NavToggle { float:left; } has cleared up the problem in both skins. In addition another problem (wrong placing of coordinates in Vector) has gone away too. Thanks again!! --Redaktor (talk) 11:58, 4 May 2010 (UTC)

Change to collapsible tables code

Resolved

Due to bugzilla:23570, we probably need to change 

ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );

into 

ButtonLink.setAttribute( "href", "#" );
ButtonLink.setAttribute( "onclick", "collapseTable(" + tableIndex + "); return false;");

We can probably also do it using addHandler i guess... 

ButtonLink.setAttribute( "href", "#" );
addHandler( ButtonLink,  "click", function() { collapseTable( tableIndex ); return false;} );

—TheDJ (talk • contribs) 13:43, 7 June 2010 (UTC)

Last snippet looks fine. —Ruud 15:10, 7 June 2010 (UTC)
Would the last one work? I thought that you'd need to use new Function() since it would reference tableIndex at the time of execution. Also, is there something better than herf="#" for the fail through condition, I've always felt it was quite a hack. I've seen other sites using herf="javascript:// comment here" and it would be nicer if the status bar could provide something a more informative. — Dispenser 20:16, 7 June 2010 (UTC) 
<a href="#">
is evil indeed, but 
a.setAttribute("href", "#");
much less so. — Christoph Päper 20:57, 7 June 2010 (UTC)
Clicking on a link leading to "#" will jump to the top of the page wouldn't it? Gary King (talk) 21:05, 7 June 2010 (UTC)
Normally onclick events should override that behavior however. Do you know of browsers where this is not the case ? —TheDJ (talk • contribs) 21:31, 7 June 2010 (UTC)
Unless it's some strange case, I'm pretty sure that it will jump to the top. I just tested it, and it did indeed jump to the top, even with an onclick. Firefox 3.6.3. Gary King (talk) 21:36, 7 June 2010 (UTC)
The return false should make sure that the default action is not executed (ergo the navigating to #). —TheDJ (talk • contribs) 22:22, 7 June 2010 (UTC)
Not on FF. That "return false" thing is not universal. You have to kill the event using something like
function killEvt (evt) {
  evt = evt || window.event || window.Event; // W3C, IE, Netscape
  if (typeof (evt.preventDefault) != 'undefined') {
    evt.preventDefault(); // Don't follow the link
    evt.stopPropagation();
  } else
    evt.cancelBubble = true; // IE
  return false; // Don't follow the link (IE)
}

// Use it like this:
ButtonLink.setAttribute( "href", "#" );
addHandler( ButtonLink,  "click", function(evt) { collapseTable( tableIndex ); return killEvt( evt );} );
I've been using that code in several of the scripts I developed at the Commons, and it works (so far) on all browsers. Something similar is also in HotCat, BTW. Lupo 10:18, 8 June 2010 (UTC)
Hmm, this sucks. I'm considering adding a killEvent() to wikibits.js because we also need this for the toc collapsing code and Edittools.js —TheDJ (talk • contribs) 18:55, 9 June 2010 (UTC)
I have not actually tested the last example yet. And of course setting href to anything alla "javascript:" for href will be useless, as having "javascript:" there is the whole problem in the first place :D —TheDJ (talk • contribs) 21:29, 7 June 2010 (UTC)

killEvent() is on its way. When it is deployed, we can fix this stuff. —TheDJ (talk • contribs) 19:23, 14 June 2010 (UTC)

killEvt deployed, changes to edittools, toc and collapsible tables made. —TheDJ (talk • contribs) 22:46, 14 June 2010 (UTC)


I don't think it's related, since that code has been in that template for ages. There is a problem with the code change and scripts that expand and collapse hidden templates, though, including my own, which I'll update shortly. Gary King (talk) 02:45, 15 June 2010 (UTC)
Several intermediate changes with syntax errors broke the collapsible tables. The effect should be transient and should disappear with a purge now. T. Canens (talk) 03:04, 15 June 2010 (UTC)
Cool. I think it might have been due to the collapsible table in this template: [1]. If so, hopefully the changes will fix the problem. Dreadstar ☥ 03:07, 15 June 2010 (UTC)

I've reverted this edit because it was causing a template to expand on RfPP in edit mode, and that was hiding the toolbox on the left side of the page with the different protection tags in it. I just checked RfPP, and after reverting that edit it was back to normal. SlimVirgin talk|contribs 04:23, 15 June 2010 (UTC)

Which templates are you referring to? From what I can understand, it seems like "RFPP administrator notation templates" is expanded by default, as well as "New to RFPP? Read me!"? Gary King (talk) 04:26, 15 June 2010 (UTC)
This template [2] uses 'collapsed class', which causes it to always be initially collapsed, no matter what happens around it. Dreadstar ☥ 04:56, 15 June 2010 (UTC)
Indeed, which is why I didn't understand SlimVirgin's comment. I now realize that she is using this script and has been referring to that the entire time. Gary King (talk) 05:06, 15 June 2010 (UTC)
So, only people using that script will have a problem with the box starting off as expanded, instead of being collapsed by default as intended? Or might there be other, unintended collateral damage caused by the changes to Commons.js? Dreadstar ☥ 05:16, 15 June 2010 (UTC)
Nevermind, that script isn't the one adding those extra buttons for SlimVirgin. I don't know which script it is, after quickly sifting through her scripts. To be able to answer your question, I have to see which script is causing the problem in the first place before I can determine what the problem is, then I can determine if the problem is isolated to that one script or other scripts will have similar problems. Gary King (talk) 05:26, 15 June 2010 (UTC)

edit.js and new toolbar

The bigest part of edit.js is for the old toolbar and it is now useless for most users. It could be moved into a separate file. — AlexSm 20:56, 8 June 2010 (UTC)

Is there a special file the new toolbar uses? —Preceding unsigned comment added by 124.138.199.3 (talk) 02:14, 15 June 2010 (UTC)
No, but it can be made just like any other custom .js file. — AlexSm 17:50, 15 June 2010 (UTC)

Okay, more specifically, edit.js should contain 

if (!window.wgWikiEditorEnabledModules || !wgWikiEditorEnabledModules.toolbar)
 importScript('MediaWiki:Common.js/oldtoolbar.js')

and all the mwCustomEditButtons=... statements (3.6Kb) should be moved into MediaWiki:Common.js/oldtoolbar.js. — AlexSm 17:50, 15 June 2010 (UTC)

Probably better to make this distinction in the main Common.js file, that avoids a level of conditional loading. —TheDJ (talk • contribs) 17:54, 15 June 2010 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_18&oldid=375515601"