MediaWiki talk:Common.js/Archive Apr 2007

message: 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×tamp=20070128094554 Geni 11:06, 28 January 2007 (UTC)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: not to bad yet.Geni 17:55, 28 January 2007 (UTC)

text: 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)
thread_title: vandal problem

message: 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)
replies: text: 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)
replies: text: Thanks Ruud! For the explanation and the fix. Grouse 16:19, 3 March 2007 (UTC)
thread_title:  Access key for project page: why change it? 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
replies: text: You're correct that it avoids an HTTP redirect. I just tested it. Mike Dillon 17:28, 5 March 2007 (UTC)
thread_title:  escape() and replace() in importScript function 

message: 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)
replies: text: On which page does this happen? —Ruud 17:37, 6 February 2007 (UTC)

text: 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)
replies: text: I have added a test for whether any header row exists: HTH HAND —Phil | Talk 11:02, 9 March 2007 (UTC)
thread_title:  Collapsible tables 

message: 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)
replies: text: 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)

text: 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)
replies: text:  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)

text:  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)
replies: text: 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)

text:  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)
thread_title:  Reverted 

message: 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)
replies: text: Charinsert doesn't work without JS anyway. —Ruud 10:57, 8 March 2007 (UTC)

text: 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)
thread_title: Fallback? 

message: A long time ago, Quarl and I discussed 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)
replies: text: 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 (UTC)
replies: text:  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)
replies: text: 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 (UTC)

text: Further work at bugzilla:9937. --brion 15:59, 17 May 2007 (UTC)
thread_title:  Placing the cursor after the section name 

message: 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)
replies: text: 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)
replies: text: Question: What happens for users with javascript disabled? Prodego talk 19:23, 18 March 2007 (UTC)
replies: text: 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)
thread_title:  Proposal: Edittools with Javascript 

message: 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	[hide]Section 1
some stuff               	…and more stuff
[hide]Section 2	[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)
thread_title:  Collapsible sections 

message: 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)
thread_title:  Proposal: Editpage.js 

message: 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)
replies: text: Just give it the collapse class, without specifying collaped or autocollapse. —Ruud 10:31, 22 March 2007 (UTC)
replies: text: Thanks for the reply Ruud. --MattWright (talk) 17:27, 22 March 2007 (UTC)
thread_title:  notcollapsed class in collapsible tables and navframes