MediaWiki talk:Common.js

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• it
• nl
• es

Default gadget for secure server

Currently there are two versions of the script for secure server, and they are very similar. What about merging the two scripts into one only page, making it easier to keep updated?

Besides, I think this script could be moved to e.g. MediaWiki:Gadget-always-secure.js, and be loaded by Resource Loader, minified, as a default gadget. This would allow us to remove the globals "disableSecureLinks" and "disableSecureLinks2" (since the user could just toggle a checkbox on Special:Preferences#mw-prefsection-gadgets). Helder 18:21, 27 October 2011 (UTC)

There are two scripts, because the new secure server setup is significantly different from the old setup (universal vs. hack job). Seeing as the old server will be removed at some point, 2 scripts is the better approach, since the old code will no longer be needed as soon as the old server becomes a 'redirect'. No objection to moving it to a gadget, if you can 'auto enable' the gadget on just the secure server. It should not be run, because it's slow and should not by default include all code, because most users won't need all that code. So make the gadget an autoloader for the service, which then lazy loads the script. —TheDJ (talk • contribs) 20:42, 27 October 2011 (UTC)

BLP editnotices script

The BLP script currently isn't very useful, as it only works if one actually presses the "Edit" button, which might not always be the case. There are many "improve this article" links in maintenance templates or the option to edit on double-click, in which cases the editnotice won't appear.

I've created an alternative script that also isn't executed on every pageview, but only if the user might actually edit an article. While in these cases the script makes either one (or if it's a BLP) two connections to the API, I think it could greatly improve performance. Some time soon, the BLP blurb should probably be cached, possibly in a cookie, to avoid unnecessary connection, but at the moment I'm still feeling too unsure with jQuery to try that (in fact, I took me two (!) months to find that one syntax error).

The script is located at User:The Evil IP address/blp.js and at the moment, it will only add the notice to articles in Category:All orphaned articles; while this might seem silly, I've done this to avoid any possible interference between the existing BLP script and mine, it can easily be changed to show the notice in an article from the BLP cat. Another easily implementable feature may be an opt-out for experienced users, who know the message already (even though of course CSS may be used for that, but one would still have to make those two connections).

Please let me know what you think and if you see any room for improvements. --The Evil IP address (talk) 17:53, 12 November 2011 (UTC)

In the previous discussion in October David suggested using hidden category which would eliminate the need for the 1st API call in your script. And some minor notes: (1) API has clcategories parameter; (2) $('div#jump-to-nav') is actually removable in user preferences; on a related note, it would be nice if someone added "(outdated option)" to Tog-showjumplinks message. — AlexSm 22:35, 14 November 2011 (UTC)

clcategories looks like a good idea. I've used #jump-to-nav, because that's where MediaWiki natively adds the editnotices after. I thought it could only be hidden from view via the preferences, not from the DOM. --The Evil IP address (talk) 15:19, 16 November 2011 (UTC)

Border="1" and tables

{| class="wikitable" border="1"

See the links below. border="1" is now allowed in HTML 5. No one has found a way otherwise to share tables with borders while copying and pasting, in syndication, via RSS readers, etc..

• https://bugzilla.wikimedia.org/show_bug.cgi?id=18829
• http://www.w3.org/html/wg/wiki/ISSUE-155-CP1
• http://dev.w3.org/html5/spec/tabular-data.html#the-table-element
• http://www.w3.org/Bugs/Public/show_bug.cgi?id=7468#c19
• http://www.w3.org/2002/09/wbs/40318/issue-155-objection-poll/results
• http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-table-element
• http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#attr-table-border
• http://lists.w3.org/Archives/Public/public-html/2011Apr/0377.html

My experience with the CSS and JS talk pages on Wikipedia has been fairly negative mostly due to a sort of religious reverence for future HTML 5 nirvana. Well, HTML 5 now allows border="1". See also:

• meta:Help:Table#Viewing tables in email and web pages outside Wikipedia

A more recent discussion is here:

• User talk:Dispenser#Reflinks is removing normal wikitable code

I suggest adding back the JS code that enabled the addition of border="1" to wikitables. See this diff of its removal. The edit comment refers to this discussion. The initial discussion that added border="1" is here. --Timeshifter (talk) 15:15, 14 November 2011 (UTC)

default
Like	this?

I have to ask, but without CSS, are tables not displayed with default (albeit prehistoric-looking) borders as shown? — Edokter (talk) — 15:36, 14 November 2011 (UTC)

No, the default for <table> is no borders. For HTML concerning tables and table borders see:

http://www.w3schools.com/html/html_tables.asp

And there is no single inline CSS code, I believe, that will add borders to all the cells of a table. See:

http://www.w3schools.com/css/css_table.asp --Timeshifter (talk) 15:46, 14 November 2011 (UTC)

default
Like	this

It varies between browsers. My example at right uses raw HTML, no CSS, few attributes (just two: <table align=right> and <th colspan=2>), but some browsers will show borders where most don't. --Redrose64 (talk) 15:55, 14 November 2011 (UTC)

I do not know of any browser that will show borders for your table. From:

http://www.w3schools.com/html/html_tables.asp - is this:

"If you do not specify a border attribute, the table will be displayed without borders. Sometimes this can be useful, but most of the time, we want the borders to show." --Timeshifter (talk) 16:42, 14 November 2011 (UTC)

Below is the most basic wikitext for a table (no styling at all). Currently border="1" is inserted by the table button if you disable vector's dialog boxes on the editing tab of preferences as I do. "Enable dialogs for inserting links, tables and more." Try it out. The wikitext for the table below came from this method. I removed the styling info at the top:

{| class="wikitable" border="1"

{| 
|-
! header 1
! header 2
! header 3
|-
| row 1, cell 1
| row 1, cell 2
| row 1, cell 3
|-
| row 2, cell 1
| row 2, cell 2
| row 2, cell 3
|}

It produces this:

header 1	header 2	header 3
row 1, cell 1	row 1, cell 2	row 1, cell 3
row 2, cell 1	row 2, cell 2	row 2, cell 3

Doing without easily-sharable tables, charts, and lists (those that use tables) makes for less useful info. It is liking trying to share text without paragraphs. Can you imagine that? There are probably hundreds of thousands of tables on Wikipedia pages. I could give many examples of why sharing many of them without borders is almost impossible. At some point Wikimedia may block the hot-linking of images, and thus image charts. See commons:Category:Statistics. Then the many wikitext-based data and text charts without borders will be what is easily shared by people in email, etc..

I suggest putting border="1" in the other table button inserts when using the table button on the rest of the edit toolbars. For example when dialogs are enabled and "Style with borders" is selected, this table wikitext below is what is produced:

{| class="wikitable"  
|-
! Header text !! Header text !! Header text
|-
| Example || Example || Example
|-
| Example || Example || Example
|-
| Example || Example || Example
|}

I suggest border="1" be added to the top line.

From this page (emphasis added):

• http://www.w3.org/TR/html5/obsolete.html

The border attribute on the table element can be used to provide basic fallback styling for the purpose of making tables legible in browsing environments where CSS support is limited or absent, such as text-based browsers, WYSIWYG editors, and in situations where CSS support is disabled or the style sheet is lost. Only the empty string and the value "1" may be used as border values for this purpose. Other values are considered obsolete. To regulate the thickness of such borders, authors should instead use CSS.

From this page (emphasis added):

• http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#attr-table-border

The border attribute may be specified on a table element to explicitly indicate that the table element is not being used for layout purposes. If specified, the attribute's value must either be the empty string or the value "1". The attribute is used by certain user agents as an indication that borders should be drawn around cells of the table. Tables can be complicated to understand and navigate. To help users with this, user agents should clearly delineate cells in a table from each other, unless the user agent has classified the table as a (non-conforming) layout table.

So border="1" is conforming and not obsolete in HTML 5. --Timeshifter (talk) 08:20, 24 November 2011 (UTC)

Here is a page that explains things more simply:

• HTML5 TABLE Element Attributes - "In HTML5 the TABLE element uses the global attributes and one other attribute: border. And it has changed to only have the value of 1 or empty (i.e. border=""). If you want to change the width of the border, you should use the border-width CSS property."

This is very clear too: HTML5 table Tag. --Timeshifter (talk) 16:30, 10 January 2012 (UTC)

.hlist

This edit is causing trouble for people using IE7. The last line may raise an exception, which IE7 reports to the user. The .before('( ') fails because the string to be inserted is mis-interpreted as an invalid selector. A possible fix might be to change that to .before('<span>( </span>'). The .after() call would have to be fixed similarly. Lupo 10:48, 17 November 2011 (UTC)

I saw that too, but the problem went away for me. The wikibits server did have some hickups yesterday, perhaps that was the cause. Do you still see the problem? — Edokter (talk) — 11:00, 17 November 2011 (UTC)

Yes, consistently. If the selector before the .before() doesn't match anything, this will fail. It's not a loading/server hiccup issue, it's a question of whether the page does contain anything that matches $('.hlist dl dl, .hlist ol ol, .hlist ul ul'). If not: boom. Lupo 11:26, 17 November 2011 (UTC)

That is one big fat jQuery bug. Putting in <span>...</span> won't help in that case. — Edokter (talk) — 11:41, 17 November 2011 (UTC)

Not sure if it's a jQuery bug. Note that the documentation says the argument must be a HTML string, DOM element, or jQuery object, or a function returning one of these. In particular, see the second example: they do not do $("p").before("Hello"); but explicitly $("p").before( document.createTextNode("Hello") );. Lupo 11:53, 17 November 2011 (UTC)

Passing null should not throw an exception, but just do nothing. I've filed a bug anyway. Meanwhile, the exception should be cleared. — Edokter (talk) — 12:09, 17 November 2011 (UTC)

Yeah. In any case, I can confirm that your fix (checking for an empty list) does avoid the exception being raised. Thanks!Lupo 12:35, 17 November 2011 (UTC)

Bug in jQuery has been fixed. — Edokter (talk) — 21:35, 17 November 2011 (UTC)

Updates needed for 1.19

See these changes that were needed on the 1.19 test site and this report

Wouldn't it be better to only ionclude the code that uses mw.util within that section? -- WOSlinker (talk) 09:29, 14 January 2012 (UTC)

No, mw.util should be global. Wrapping common.js in it a horrible kludge. See also bugzilla:33669; this apparently causes revesal of the load order of site and user JS. — Edokter (talk) — 10:23, 14 January 2012 (UTC)

Bugzilla:33711 states that all modules are now loaded asynchonously. I still think wrapping the entire file in ml.loader.using() is a kludge. Is the wrapping required, or would simply starting with mw.loader.using('mediawikiw.util'); on the top be enough? — Edokter (talk) — 10:51, 14 January 2012 (UTC)

I read the documentaion again. It must be wrapped. It somehow still doesn't sit right with me. Surely, it should be possible to have mw.util as a core dependancy when the site JS module loads? — Edokter (talk) — 11:09, 14 January 2012 (UTC)

It's possible in principle, but MediaWiki currently exposes no interface for defining such dependencies; the mw.loader.using(...) declaration is just the inline equivalent. Happy‑melon 17:12, 14 January 2012 (UTC)

It seems to me this could be done in ResourceLoader itself. — Edokter (talk) — 17:33, 14 January 2012 (UTC)

Also, would simply having mw.loader.using( 'mediawiki.util', mediwiki.util.init ); (or even mw.loader.load( 'mediawiki.util' )) at the top have the same effect? I feel have closing parens at the bottom is an invitation to errors when adding code. — Edokter (talk) — 17:39, 14 January 2012 (UTC)

That's pretty much what I said: the backend to support Common.js having a dependency on any given module is very much in place, but there is currently no mechanism for specifying such dependencies for a given installation of MediaWiki. I'm not a JS expert, but I believe that the asynchronous loading mechanism means that when the JavaScript is sent to the browser to be executed, it would see a using() statement and queue the code within it to be executed when the module had been loaded, but would then merrily continue parsing subsequent lines, almost certainly (unless you had a blisteringly fast connection) before the mw.util module had necessarily loaded. Happy‑melon 18:23, 14 January 2012 (UTC)

How about including private copies of wikiGetlink, getParamValue & addCSS and then there would only be two small bits of code that depend on mw.util.addPortletLink which could be wrapped on their own? -- WOSlinker (talk) 20:11, 14 January 2012 (UTC)

What's so inherently bad about wrapping code? That's all the dependency framework does, it just wraps whole files rather than individual code blocks. The only downside to wrapping is the small chance of someone damaging the closing bracket with a careless edit, something easily countered with a judicious comment. Happy‑melon 21:51, 14 January 2012 (UTC)

Without knowing the internals of javascript engines, this construct seems incredibly inefficient. I may be wrong here. However, it is very counter-intuitive having to require a wrapper on what is now a simple linear construct. Every JS file depending on some functionality is going to require it. That alone should be enough reason to build the dependency tree into ResourceLoader. — Edokter (talk) — 22:13, 14 January 2012 (UTC)

(←) If I seem a bit upset, it is becasue I know this is going to be a potential major breaking change. Requiring all JS files to be wrapped in .using is going to make a lot of wiki operators unhappy. What would be nice is that mw.loader.using( 'someModule' ); without a callback would make a synchronous call to that module's init. That would at least lose the wrapping requirement. — Edokter (talk) — 22:29, 14 January 2012 (UTC)

I agree with Edokter that mw.util should be executed before everything else. You could wrap Common.js but what is going to happen to all existing user .js files? — AlexSm 17:42, 17 January 2012 (UTC)

Wrapping common.js obviously has it's flaws (see below). Wrapping userscripts is less problematic, because they don't need to be global. Scrap that. Any evet that points to some function will also break when wrapped. — Edokter (talk) — 17:49, 17 January 2012 (UTC)

Revert global wrapping

{{sudo}}

Hi. Please revert this edit immediately. It's breaking collapse-related code. I've just confirmed this on test.wikipedia.org. --MZMcBride (talk) 15:36, 17 January 2012 (UTC)

Example messages from the browser error console:

Error: toggleNavigationBar is not defined
Source File: javascript:toggleNavigationBar(1);
Line: 1

Error: collapseTable is not defined
Source File: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=site&only=scripts&skin=monobook&*
Line: 6

Done. Thanks, PeterSymonds (talk) 15:43, 17 January 2012 (UTC)

Thank you! The collapse functionality is working again. --MZMcBride (talk) 15:45, 17 January 2012 (UTC)

Please give exact details (URL) of any failures. This will eventually needs to be reinstated. — Edokter (talk) — 16:46, 17 January 2012 (UTC)

All functions inside your wrapper became private and not accessible through javascript: links. — AlexSm 16:51, 17 January 2012 (UTC)

Then we have a massive dilemma... Break common.js because of the missing dependency declaration, or break common.js because it is no longer global. — Edokter (talk) — 16:59, 17 January 2012 (UTC)

Sorry, I don't know have much more information than what I provided. The code you added broke NavFrame and the other type of collapsing code. The error messages above came from my browser console. The collapsing functionality was broken in Chrome/Windows 7 and Firefox/Windows 7.

I didn't realize that JavaScript had private functions. I'm also not really clear on why the additional code is necessary. I'd strongly encourage testing at test.wikipedia.org if possible first before any additional code changes, though. Breaking collapse code site-wide is kinda nasty. :-) --MZMcBride (talk) 17:10, 17 January 2012 (UTC)

You said you confirmed the error on the test site. Do you have a link to a page there that produces the error? For why it is necessary, see mw:ResourceLoader/Migration guide (users)#Dependencies. — Edokter (talk) — 17:17, 17 January 2012 (UTC)

Edokter: we can either move those function outside the wrapper or replace javascript: URLs with click() events. — AlexSm 17:16, 17 January 2012 (UTC)

collapseTable as a click event also seems broken. The old collapsible code should prpbably go alltogether anyway, but we still may have code that uses mw.util and must be global. This can only be solved by preloading mw.util in core. — Edokter (talk) — 17:25, 17 January 2012 (UTC)

I was testing with testwiki:Collapse. That's a copy of User:MZMcBride/Archive index, which is where I noticed the issue initially. I copied en.wikipedia.org's Common.js to testwiki:MediaWiki:Common.js. Right now, testwiki:Collapse is still broken as test.wikipedia.org's Common.js is using the wrapper code. --MZMcBride (talk) 18:21, 17 January 2012 (UTC)

As a stop-gap you could use:
function(){ /* local scope*/ window.iAmGlobal = function(){ .. } ; ...
Of course global functions like this should be inexistent eventually. Use proper event binding instead. Krinkle (talk) 04:34, 18 January 2012 (UTC)

Thanks Krinkle. We now have a working Common.js on the beta site, and I will make it live here momentarely. Two function need to remain global for now, collapseTable and toggleNavigationBar, which serve the old collapsible table code and NavFrame respectively. These are essentially deprecated in favor of mw-collapsible, and we should make an effort to discourage their use. Two other functions, addPortletLink and getURLParamValue can be safely removed, as they still live in wikibits.js, which is not going anywhere soon. (These mappings were added in a mistaken fear that wikibits would be removed sooner then later.) — Edokter (talk) — 12:20, 19 January 2012 (UTC)

Please do not make any significant changes here before the blackout

Once the blackout goes into effect, editing will locked (although stewards and staff will be able to circumvent this if necessary). Thus if any bad changes are made, it may be difficult to get them reverted until after the blackout. There will be some CentralNotice-related code going into Common.js immediately before the black-out, but otherwise, we should probably leave things as is until after the black-out is over. If you have any questions or comments, please ping me on my talk page or email me. Thanks! Kaldari (talk) 21:16, 17 January 2012 (UTC)

Wait, the blackout is working by CentralNotice? Isn't that Javascript-dependent? --Yair rand (talk) 21:53, 17 January 2012 (UTC)

Yes. Some site-wide CSS will also be deployed concurrently to make the blackout more effective/obnoxious. --MZMcBride (talk) 22:08, 17 January 2012 (UTC)

Just a chance for me to test my hacking skillz. — Edokter (talk) — 22:42, 17 January 2012 (UTC)

Will I still be able to use the readability extension or View > Page Style > No Style in Firefox. — Dispenser 23:07, 17 January 2012 (UTC)

Disabling CSS and javascript will probably get you in. Not sure if editing is disabled. — Edokter (talk) — 23:10, 17 January 2012 (UTC)

Editing will be disabled via $wgGroupPermissions. We're drafting a technical FAQ on Meta, BTW. Steven Walling (WMF) • talk 00:39, 18 January 2012 (UTC)

Split MediaWiki:Common.js/edit.js into (default) gadgets

Wouldn't be better to move the individual parts of MediaWiki:Common.js/edit.js to gadgets enabled by default, and restrict it to users with the 'edit' right?

Besides, instead of checking for $.wikiEditor and $.wikiEditor.modules.dialogs, what about using the values of

mw.user.options.get('showtoolbar')
mw.user.options.get('usebetatoolbar')
mw.user.options.get('usebetatoolbar-cgd')

to determine which version of the RefToolbar to load? Helder 10:37, 21 January 2012 (UTC)