MediaWiki talk:Common.js/Archive 4

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Reverted

I reverted the changes for several good reasons:

A similar solution has been rejected in the past.
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.
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

Placing the cursor after the section name

A long time ago, Quarl and I discussed^{[broken anchor]} 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)[reply]

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 (U T C)

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)[reply]

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 (U T C)

Further work at bugzilla:9937. --brion 15:59, 17 May 2007 (UTC)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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:

[hide]Caption
[hide]Section 1
some stuff	…and more stuff
[hide]Section 2
some stuff	…and more stuff

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)[reply]

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)[reply]

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)[reply]

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

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