MediaWiki talk:Common.js/Archive 20

Archive 15

←

Archive 18

Archive 19

Archive 20

Archive 21

Archive 22

Archive 23

Do not create NavFrame buttons if the new class "mw-collapsible" is used

Currently, the code which provides the Wikipedia:NavFrame functionality has a test like this

function createNavigationBarToggleButton(){
    // ...
    if (hasClass(NavFrame, "NavFrame")) {
        // Create the buttons...
    }
}

But this causes a conflict (example) if we try to moigrate to the (not so new) MediaWiki plugin which uses the class "mw-collapsible" (see previous discussion). Since it was not good idea to just copy the styles of NavFrames to the classes of this new plugin, I think a good way to help in the migration would be to improve the test above like this:

function createNavigationBarToggleButton(){
    // ...
    if (hasClass(NavFrame, "NavFrame") && !hasClass(NavFrame, "mw-collapsible")) {
        // Create the buttons...
    }
}

This way, we could still use the old classes for formatting and the new ones to make things "collapsible". The same idea would apply to the old "collapsible tables" system, where

if ( hasClass( Tables[i], "collapsible" ) ) {

would be replaced by

if ( hasClass( Tables[i], "collapsible" ) && !hasClass(NavFrame, "mw-collapsible") ) {

What do you think? Would that work? Helder 14:04, 5 March 2012 (UTC)

By the way, we could also replace the deprecated hasClass(NavFrame, "NavFrame") by $(NavFrame).hasClass( 'NavFrame' ) (since this is the last script in MediaWiki namespace using this function). Helder 14:14, 5 March 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)

I wouldn't split everything into gadgets but mwCustomEditButtons has to go to a separate page because it's useless with default settings (!) and WP:RefToolbar 2.0 definitely has to be a default gadget. With MW 1.19 it doesn't work in IE8 and possibly causes problems for other edit buttons. — AlexSm 18:38, 1 March 2012 (UTC)

mwCustomEditButtons is protected by an if so it doesn't really matter. But I do agree about the default gadget. --Locos epraix 03:03, 5 March 2012 (UTC)

It does matter because it's 3+ KB of code. And it's actually not "protected" and the statement if(mwCustomEditButtons) doesn't make any sense: right now it's always true and the code always runs; if devs remove the object then this code will cause JS error. — AlexSm 04:13, 5 March 2012 (UTC)

Yup I didn't realize that var was always defined. It should be changed to something like if(!mw.user.options.get('usebetatoolbar')). --Locos epraix 23:09, 6 March 2012 (UTC)

I've asked the migration of the edittools into a (default) gadget on its talk page. Helder 20:37, 29 June 2012 (UTC)

MediaWiki:Common.js/edit.js: Opt-out

Hey all,

edit.js claims to have an opt-out method by "adding mwCustomEditButtons = []; to Special:Mypage/common.js". However this is in my opinion not a very wise nor reliable way to opt out.

For one, it will redefine the entire array. So any aliases to it are no longer correct and will be pointing to the old array. And if users have other scripts enabled that add buttons, those would be lost as well.

I'd recommend instead turning the button-part of the script into a Gadget and enable it by default (*[ResourceLoader|default]). Then users can simply opt-out but unchecking in the preferences. That makes it load faster (as it will not be loaded at all (instead of undone after the fact) for those opting out. And also more reliable and user friendly. Krinkle (talk) 00:55, 7 March 2012 (UTC)

Bug 32795 fixed

Tracked in Phabricator
Task T34795

The bug affecting line-height printable mode CSS rule, was recently fixed in Mediawiki 1.19. Please check if the following lines are still required. – Fuzzy – 19:57, 6 March 2012 (UTC)

    // In print IE (7?) does not like line-height
    mw.util.addCSS('@media print { sup, sub, p, .documentDescription { line-height: normal; } }');

Actually, only the margin issue was fixed, the line-height issue is still open i believe. —TheDJ (talk • contribs) 22:51, 6 March 2012 (UTC)

This bugfix enabled the top/bottom margin to be set in print mode (by removing the !important specifier). The line-height fix is a workaround for this issue. – Fuzzy – 09:18, 12 March 2012 (UTC)

MediaWiki:Common.js/edit.js: mw.toolbar.addButton

Hey all,

As some of you may know, using the global mwCustomEditButtons has a down side. If you add an item to it too late (that is, after the toolbar is already initialized), then they are ignored. And there is no way to fix this from here because it's just an array, there is no event taking place that can be hooked into to.

This can be fixed by using mw.toolbar.addButton instead. Which will add it to the queue if it's still early, and add it to the toolbar directly if it's after the initialization. Krinkle (talk) 00:51, 7 March 2012 (UTC)

Arial Unicode MS for IPA

mw.util.addCSS('.IPA, .Unicode { font-family: "Arial Unicode MS", "Lucida Sans Unicode"; }');

Arial Unicode MS has known rendering problems for IPA characters. This font shouldn't be included in the list for .IPA. Having it here can make IPA text display incorrectly, or encourage editors to to work around the display problems in their own browser by entering text incorrectly, thus making the display break for readers whose browsers work right. —Michael Z. 2012-03-14 18:16 z

Any suggestions for a better font? Preferably one that is installed by default? — Edokter (talk) — 18:34, 15 March 2012 (UTC)

Arial Unicode MS is the default Windows font that include the biggest range of unicode chars. We should leave it, but change the order. And about Tahoma? --Locos epraix 18:54, 15 March 2012 (UTC)

But it botches the display of IPA, and for some number of users with good IPA fonts installed, it will break IPA which would otherwise display correctly. The requirement is having the IPA characters, not having “the biggest range.” Does including this font actually improve IPA display at all, for anyone?

It looks like Windows has some real IPA fonts.[1] The SIL fonts are free and support a broad or full range of IPA, but many are serif fonts.[2] [updated] —Michael Z. 2012-03-18 19:34 z

See also Wikipedia:IPA#Affricates_and_double_articulation. —Michael Z. 2012-03-16 15:10 z

I'll see if I can filter on Windows version, as basically only XP needs it. — Edokter (talk) — 19:47, 18 March 2012 (UTC)

Thank you. Please let me know how it goes, because we have some catching up to do on this front in en.Wiktionary. —Michael Z. 2012-03-19 04:36 z

Specifying these fonts is only needed for Windows XP using Internet Explorer and specifically Internet Explorer 6 (older than Internet Explorer 7). If you used other browsers on Windows XP, there would be no problem in displaying IPA. I suggest using Lucida Sans Unicode, then Arial, then Segoe UI, then Microsoft Sans Serif, then specify the "inherit" case. Please, use anything but Arial Unicode MS. I remember it appeared very illegible on Windows XP, not to mention its big issue with the tie-bar   ͡   . Segoe UI, DejaVu Sans and Arial Unicode MS aren't installed by default in Windows XP and they appear blurred on Window XP because they were designed to be rendered using technologies like ClearType which are hardly found on Windows XP. It's very weird that Lucida Sans Unicode doesn't render the tie bar properly on Windows 7 (and probably all Windows versions after Windows XP), yet it renders the tie-bar properly on Windows XP. Would the following be able to specify a specific Windows version as it's used for ⟨if ($.client.profile().versionBase == '6') { importScript('MediaWiki:Common.js/IE60Fixes.js'); }⟩?

if ($.client.profile().platform == 'win'().versionBase == 'XP') {
}

--Mahmudmasri (talk) 01:50, 6 July 2012 (UTC)

jQuery.client() does not (yet) have the means to retreive the OS version number. versionBase returns the browser's base version. — Edokter (talk) — 11:37, 30 August 2012 (UTC)

OK, I changed the target for the font to XP only, but still target all browser, as IE8 also benefits, and Chrome still has the Unicode bug under XP. I also prefered Lucida Sans Unicode for IPA while preferring Arial Unicode MS for Unicode. I hope this remedies any issue. Please report any breakage under Windows version newer than XP. — Edokter (talk) — 13:02, 30 August 2012 (UTC)

Uncaught TypeError: Object [object Object] has no method 'wikiEditor'

When I accessed https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&oldid=482403942 I got

Uncaught TypeError: Object [object Object] has no method 'wikiEditor'

from line

$target.wikiEditor('addDialog', dialogobj);

of mediawiki:RefToolbar.js. Helder 19:04, 17 March 2012 (UTC)

adjustments to secure.js and secure_new.js

Hey guys,

I adjusted secure.js and secure_new.js to add an exemption for the new shop links. Both of them were added to the same line as the full exemption for www and mail because shop.*.org urls exist for all projects and redirect to shop.wikimedia.org.

• For the new secure server this should be temporary. We only have SSL on the checkout pages right now because of limitations with the provider but are working on getting that changed. When it exists I'll just revert this out.
• For the old secure server the link just fails miserably over on incubator because the shop doesn't exist. This one will just stay.

I'll keep an eye here for a couple days but feel free to poke me by email or talk page if you have questions as well. Jalexander--WMF 23:35, 30 March 2012 (UTC)