MediaWiki talk:Gadget-PageNumbers-core.js

From Wikisource
Jump to navigation Jump to search

Local copy[edit]

Is there a compelling reason for us to have a local copy of this rather than loading the version from oldwikisource like with most of the other common javascript? Prosody (talk) 19:17, 14 January 2013 (UTC)[reply]

Yes. One day this copy will load within proper starting and ending div tags while the others will continue to follow the designs of a designer who left development altogether. See the talk page at old for details. -- George Orwell III (talk) 23:55, 14 January 2013 (UTC)[reply]

Recent changes don't work in Firefox 25[edit]

Not sure what has been done to cause the breakage (no edit summaries makes it difficult to know), however, the page number and the grey highlight is now offset in a downwards direction when using Firefox. There has to be a better way. Would you please return it to the previous form where it worked. Thanks. — billinghurst sDrewth 06:23, 3 November 2013 (UTC)[reply]

Seeing a similar effect in Chrome, though not as accentuated as with FF. — billinghurst sDrewth 06:44, 3 November 2013 (UTC)[reply]
Technically this has been "broken" for months if not years now (& I'm not going to rehash Any of it for the umpteenth time right now either) but, yes, to the layman's eye everything seemed just fine. If the gray highlight is still off at the time of this post - its because I don't know javascript for sh!t. That shouldn't be all that much to fix - the embedded page numbers still reside on the same line as the point where the Page: namespace's page-break cuts into the transcluded content. Compensating for or adding/subracting a line return and/or a hard space is the obvious code fix for the gray highlight thingy if its still offset (I just don't know enough to be sure where exactly to do that & my gut tells me the offsets were all off to begin with).
The major point was to reign in Dynamic Layouts from intruding in on "things outside of the 'editbox' & it's norms" upon User: save and the subsequent viewing. This has been rectified (for the most part) in what probably is not the most elegant nor most efficient way to script what was needed. Sorry for any headaches - past present or future. Fair warning - now that that the boundary boxes are "aligned" along the top (where the most sub wrappers & sub containers reside), the lower half (or footer related) still has a thing or two "inside the wrong box" for lack of a better term so folks should expect a bit more weirdness before everything is completely "stable" again. --George Orwell III (talk) 08:44, 3 November 2013 (UTC)[reply]

Broken again[edit]

This is becoming infuriating that the simple ability to link is constantly under change, without obvious concern for users, and fellow administrators, and now I get no page numbers in either browser, and rolling back gives me page numbers with [undefined]. If you want to play with this, take it all over to test.wikipedia.org and play over there, get it right, then bring it back here. In the meanwhile, please give me stable page numbering so that I can do my bits around here. — billinghurst sDrewth 09:22, 6 November 2013 (UTC)[reply]

Proper page number decoding[edit]

This script mangles page names containing various Unicode characters, for example "1–2" as "1.E2.80.932". Please replace: 

        var name = page_span.id;
        if ( name.match( /^.CE.9E/ ) ) name = "Ξ";
        if ( name.match( /^.E2.80.93/ ) ) name = "—";
        if ( name.match( /^.E2.80.94/ ) ) name = "—";

with: 

        // Switch to URL encoding, except for hex-like sequences that would turn
        // into ASCII control characters.
        var name = page_span.id.replace(/\.([2-68-F][0-9A-F]|7[A-E])/g, "%$1");
        try {
            name = decodeURIComponent(name.replace(/_/g, " "));
        }
        catch (exc) {
            name = page_span.id;
        }

This is essentially a lossy implementation of an anchordecode: that would reverse the anchorencode: parser function. The try is in there because there may be false positives.

Also, if anyone here is an administrator at the Multilingual Wikisource, please update the version there as well. Thank you!

 – Minh Nguyễn (talk, contribs) 05:44, 9 October 2014 (UTC)[reply]

Wrap the tags inside quotes. Page numbers are simple things, usually numbers or roman numerals, and we have used emdashes and endashes successfully when quoted. Pages numbers are not more complex. — billinghurst sDrewth 05:50, 9 October 2014 (UTC)[reply]
@Mxn: have you an example of where we have the problem? — billinghurst sDrewth 01:20, 10 October 2014 (UTC)[reply]
@Billinghurst:: In fairness to Minh, I have seen this on occasion before (I checked my vague memories of where but nothing showing right now.) However (1) your solution of quoting; and (2) it is almost always a mistake to transclude a page liable to be marked as described; especially in combination mean that there is very little likelihood of this being an issue worthy of addressing within PageNumbers.js. In any case, this whole issue is merely one of a special case of language/browser misunderstanding/mishandling of UNICODE which is most probably not worth of address at an application level, and will most likely be addressed sooner if band-aid solutions (@Mxn: I am not denigrating the brilliance of your solution!) are not plastering the whole edifice together already? AuFCL (talk) 01:57, 10 October 2014 (UTC)[reply]

@Billinghurst: I originally asked for this change at the Multilingual Wikisource because the Vietnamese Wikisource includes that version; George Orwell III asked me to see if the change would also apply to this version as well.

At the Vietnamese Wikisource, some of our most important documents are numbered by column, two columns to a page. So vi:Mục lục:Dictionarium Annamiticum Lusitanum et Latinum (Bayerische Staatsbibliothek).pdf for example has a page numbered "1–2" for the page with columns 1 and 2. It also has a page numbered, for lack of a better term, "inside cover" (bìa phụ). We are using quotes around the page numbers in the <pagelist> tag, if that's what you mean, but the anchor-encoding actually comes from the ProofreadPages extension preprocessor. If you include vi:Trang:Dictionarium Annamiticum Lusitanum et Latinum (Bayerische Staatsbibliothek).pdf/11 (1–2) on a page using the <pages> tag, "1–2" is passed into MediaWiki:Proofreadpage pagenum template [1][2][3], which MediaWiki's preprocessor turns into: 

<span class="pagenum" id="1.E2.80.932" title="Trang:Dictionarium Annamiticum Lusitanum et Latinum (Bayerische Staatsbibliothek).pdf/11"></span>

The id attribute is apparently set so that you can link to individual pages in the main namespace, for example vi:Từ điển Việt–Bồ–La/A#1.E2.80.932. (The preprocessor is definitely responsible for the anchor encoding: try entering <span id="1–2">abc</span> into Special:ExpandTemplates and viewing the raw HTML.) This script picks up the id attribute and will happily convert ".E2.80.93" into an en dash, but only at the beginning of the string, not in the middle. It also won't help with characters like "ì" and "ụ".

Regardless, the Vietnamese Wikisource doesn't use the English Wikisource's script, so I have no problem if you decline to incorporate the proposed change. I just wanted to offer it in case any documents here also get tripped up by this bug.

 – Minh Nguyễn (talk, contribs) 06:37, 10 October 2014 (UTC)[reply]

Simpler alternative[edit]

After digging into the cause of the anchor encoding above, I arrived at this simpler, more reliable change:

  1. Change MediaWiki:Proofreadpage pagenum template to add data-page-number="{{{num}}}" next to id="{{{num}}}".
  2. In this script, replace:
            var name = page_span.id;
        if ( name.match( /^.CE.9E/ ) ) name = "Ξ";
        if ( name.match( /^.E2.80.93/ ) ) name = "—";
        if ( name.match( /^.E2.80.94/ ) ) name = "—";
    with:
            var name = page_span.getAttribute("data-page-number") || page_span.id;

Other wikis that include this script but haven't updated their MediaWiki:Proofreadpage pagenum template would just have to put up with badly mangled page numbers.

 – Minh Nguyễn (talk, contribs) 08:05, 10 October 2014 (UTC)[reply]

It sounds like something that would be better within the ProofreadPage code, rather than in the page numbering output. May as well resolve it at host. — billinghurst sDrewth 10:49, 10 October 2014 (UTC)[reply]
Sorry, I wasn't clear above. The bug doesn't actually have anything to do with ProofreadPage itself. The bug lies in how MediaWiki:Proofreadpage pagenum template and MediaWiki:PageNumbers.js both rely on the id attribute, which gets transformed by MediaWiki's preprocessor. ProofreadPages passes the correct, unencoded page number to MediaWiki:Proofreadpage pagenum template. It doesn't make sense to add a special case to the preprocessor, does it? – Minh Nguyễn (talk, contribs) 07:29, 12 October 2014 (UTC)[reply]
Also, the bug appears on plenty of pages here at the English Wikisource, including:
 – Minh Nguyễn (talk, contribs) 08:13, 12 October 2014 (UTC)[reply]
Sorry for being away for a few days real life calls

I tried implementing this and it broke all the numbering; [undefined] came up for all the embedded links back to the page namespace instead. - George Orwell III (talk) 23:01, 13 October 2014 (UTC)[reply]

@George Orwell III: I'm sorry, there was a typo above: the variable should continue to be named name, not num, and jQuery.data() can't be called on raw DOM elements. I've corrected the mistakes above. That was bad copy-pasta from the OldWikisource version of my proposal. – Minh Nguyễn (talk, contribs) 05:35, 14 October 2014 (UTC)[reply]

┌───────────────────┘
 @Mxn: -- OK, that stopped the "undefined" results all around but now embedded numbers are no longer generated after the targeted point {anchored url] in certain cases. If you re-visit the pages you listed above earlier that were affected by this "issue" you should now see that the embedded "target" page number/back-link and all links afterwards are no longer generated. Please verify you see the same before I revert to previous scheme. -- George Orwell III (talk) 23:13, 17 October 2014 (UTC)[reply]

Ah, that's because name is being used for both the displayed page name and the URL anchor. Replace this line: 

        var pagenumber_id = "pagenumber_" + name;

with this: 

        var pagenumber_id = "pagenumber_" + page_span.id;

 – Minh Nguyễn (talk, contribs) 03:44, 19 October 2014 (UTC)[reply]

@Mxn: - Ok that last one seemed to resolve the lack of generation of the target & subsequent embedded page links but I noticed the mouse-pointer hover over such links does not produce the corresponding "grey highlight" of transcluded content like it does for "normal" links. No big deal for me personally but somebody, someday will surely complain about the lack of it. Any ideas? -- George Orwell III (talk) 03:56, 19 October 2014 (UTC)[reply]

Thanks for taking care of that. The page number span for one of these special pages contains a ".". jQuery treats "." as the start of a class name, rather than as part of the ID. Replace this: 

        var page_span = self.pagenum_ml.filter( "#" + id );

with this: 

        var page_span = document.getElementById( id );

 – Minh Nguyễn (talk, contribs) 04:17, 19 October 2014 (UTC)[reply]

@Mxn: No good - now all the "hover-highlighting" no longer works. reverting. -- George Orwell III (talk) 04:39, 19 October 2014 (UTC)[reply]
@George Orwell III: Yikes, sorry, need to wrap that in a jQuery object: 
        var page_span = $( document.getElementById( id ) );
I tested this suggestion with User:Mxn/PageNumbers.js and it seems to work fine. – Minh Nguyễn (talk, contribs) 10:33, 19 October 2014 (UTC)[reply]
@Mxn: -- not so much here (as far as I can tell). While the "grey highlighting" upon hover for embedded links in general now work as before, the instances originally listed above still generate properly but no highlight upon mouse hover in those special cases. Its no big deal since it affects so few pages apparently but if you think you can nail it down, I'm willing to keep trying rather than revert it. Good thing I checked before saving - it just took a bit longer for the caching to catch up. The grey highlighting upon mouse hover now works for those special cases listed above as well as the rest of the embedded links like before. Thanks again & Please check back whenever you get around to it in a couple of days just to be sure others don't wind up seeing/not seeing something we do/don't right now. -- George Orwell III (talk) 10:49, 19 October 2014 (UTC)[reply]

Changes to left margin push up against left sidebar[edit]

Tracked in PhabricatorTask T85614Open

The last change to margins now pushes the square bracket up against the left side bar, and it seems to require a little more whitespace between the sidebar and the left square bracket. (firefox 34] — billinghurst sDrewth 03:45, 1 January 2015 (UTC)[reply]

Gotcha User:Billinghurst. Do me one favor first (hopefully you're not on a tablet or something as "tiny") - can you slowly resize your browser window width-wise (wider if its normally a window of many on the desktop, smaller if its normally taking up the whole screen) and see if at some point the side-bar margins (and the pageNums) don't readjust themselves position wise (happens around a viewable width of 982px to be specific). Thanks. -- George Orwell III (talk) 04:00, 1 January 2015 (UTC)[reply]

Never mind - reverted. -- George Orwell III (talk) 13:59, 1 January 2015 (UTC)[reply]

@George Orwell III:} I would have been happy with the retrieval of .5 em (think that prior it was -3, and you took it to -4 … -3.5??) if I remember the change that you made. — billinghurst sDrewth 07:43, 2 January 2015 (UTC)[reply]
@Billinghurst: that was the whole point of asking you to test for the "readjustment" of default css settings coming from the phps on the servers as you [hopefully] use a device or monitor with a view area that is roughly larger than 982px at its max. As you slowly shrink your browser window's width from full screen (the max dpi) all the way down to a size where everything becomes unintelligible -- and however your system defines ~982px -- you "should" see exactly a .5em shift in padding, margins, etc. when that ~982px threshold is crossed. Keep the focus of your viewable window to the most top-left corner of any WS page. The shift is most easily seen by focusing on the sidebar menu as your window shrinks.

I can only test the browser(s) that I have handy and those are all IE. double :(

So can you kindly add your favorite browser's performance regarding the possible readjust at ~982px threshold or not? Please answer this question either way -- sooner would be more helpful than the usual when I get around to and if remember to timeframe. -- George Orwell III (talk) 11:22, 3 January 2015 (UTC)[reply]

Monobook does not change width (Firefox), though I do see that vector does shuffle and squeeze (toolbar and margin) to the left (Chrome) when I get browser to mid-width of the (first) monitor. — billinghurst sDrewth 12:11, 3 January 2015 (UTC)[reply]
@Billinghurst: Thanks for that. So under monobook nothing happens regardless of the browser used while under vector Chrome makes the "shift" but Firefox does not?... if I'm understanding you correctly there that is. -- George Orwell III (talk) 13:25, 3 January 2015 (UTC)[reply]
That was just two tests. I have tried FF logged out, and in vector it behaves the same as Chrome. So presumably that means that monobook is static width left toolbar, and chrome is dynamic, and browser independent. — billinghurst sDrewth 03:04, 4 January 2015 (UTC)[reply]

┌───────────────────┘

@Billinghurst: -- UPDATE (+E/C)

Never mind - there is no point in trying to come up with a solution or a compromise while further tinkering is likely to occur. The already open Task is tracked above. -- George Orwell III (talk) 03:11, 4 January 2015 (UTC)[reply]

Bitrot[edit]

@Inductiveload: While debugging something else I ran across this: 

        $(function() {
            if ($(".pagenum").length) {
                pagenumbers.init();
                $(window).load(pagenumbers.refresh_offsets);
            }
        });


.load() is no longer an event handler method in jQuery 3.0 (it now fetches data from the server). This needs to be changed to: 


        $(function() {
            if ($(".pagenum").length) {
                pagenumbers.init();
                $(window).on('load', pagenumbers.refresh_offsets);
            }
        });

Though it would probably work even with $(document).ready(). --Xover (talk) 14:07, 12 December 2020 (UTC)[reply]

Done Special:Diff/10707649. :-) Inductiveload—talk/contribs 23:52, 12 December 2020 (UTC)[reply]
@Xover, @Inductiveload: I have reverted as page numbers had moved from the lead part of the page to middle of the page—Firefox, monobook. Was happening in the three biographical articles linked from Portal:Accepted Frewen. — billinghurst sDrewth 01:24, 13 December 2020 (UTC)[reply]
Ok, dropping raw thoughts here as they occur to me (and before morning coffee takes effect; apologies in advance for the stupid), since I can't predict how much time I'll have to pursue this today, and it may be useful for others…
First, @Billinghurst: One of those changes was to fix the problem reported in WS:S#Translation license box does not expand. In addition, the most likely culprit for the issues you saw is the other change (the one starting this thread). In other words, it would be preferable to try to preserve the fix for the translation license template rather than aim for a status quo (since the status quo was broken).
Second, as briefly mentioned, the most likely culprit is the change proposed here (diff). It means calling refresh_pagenumbers() an additional time that has most likely not been working for years (since MW updated jQuery to 3.x), and since refresh_pagenumbers() calculates the position of the page numbers, it seems the most likely thing to cause the problems you describe.
Thirdly, when I try to load this script from my common.js, even without these two changes, I am seeing even more weirdness: at first blush it looks like the div for holding the pagenumbers is placed after the licence banner, footer, etc. That suggests even more timing issues, and the difference makes this (pardon my French) hell to debug. I am wondering if the split into main and -core gadgets makes any kind of sense here, or if it is only exacerbating this kind of issue. So, since I can't reproduce the problem, I think I may approach this by some judicious application of brute force and ignorance and try to smush this together into a single gadget. That should at least eliminate one class of timing issues and might give some idea of where the real problem is. --Xover (talk) 09:00, 13 December 2020 (UTC)[reply]
It was just easiest to revert to status quo, rather than having a nuffnuff try to work it out. — billinghurst sDrewth 10:38, 13 December 2020 (UTC)[reply]
Sure, that's usually the best bet: roll it all back and figure out the details once the dust settles. It was just that in this particular case the rolled-back state was also broken (in a public-facing way), and there was a chance the borkage could be fixed without introducing the new breakage. --Xover (talk) 20:37, 13 December 2020 (UTC)[reply]
And in the world's longest (and possibly dumbest) detour, the issue with the local copy was that the Gadget loads some CSS as a dependency, but when you load it locally you need to load the CSS yourself. *sigh* And by the time I finally figured that out I'd run out of wikitime. I did try to test the issue Billinghurst reported, but failed to reproduce it. It was in Safari rather than Firefox, and it was not very thorough testing, so not conclusive; but it does suggest the issue is affected by the differences in the environment for a Gadget vs. a user script.
One thing worth checking out though, is whether the $(window).on('load', pagenumbers.refresh_offsets); really needs to hook into the load event. In my testing the script consistently tried to add the handler after the load even had already fired, and load, unlike ready, does not immediately execute handlers added after it's been fired. Just on eyeballing I'd say this could run from the ready event. I started on a BF&I refactor where that worked fine, but, that was refactored code so not directly comparable. It may not even be needed at all (there's all kinds of voodoo coding hiding in there, trying to handle edge cases that cannot actually happen), but if it is this is a prime suspect in miscalculating the initial position of the page numbers (switching layouts would probably fix it if so). --Xover (talk) 20:37, 13 December 2020 (UTC)[reply]
Ok, just tested in Firefox (83.0, macOS) with my local copy and I can't reproduce Billinghurst's problem in any of the layouts, and in neither Vector nor Monobook. We may need to set this up as a Gadget to debug properly. --Xover (talk) 08:27, 14 December 2020 (UTC)[reply]
Oh, and digging a bit on the load event, it looks like since jQuery 3.x, when .ready was made asynchronous, a .load handler inside .ready will effectively never execute. We should just drop the .load event and execute pagenumbers.refresh_offsets() synchronously inside $(document).ready(). If that gets called before the page geometries are completely settled in some cases (it's technically a race, especially on image-heavy pages, but all our images have known dimensions ahead of time) we'll need to refactor so we can attach the .load handler earlier (or force a .refresh_offsets() at the right time some other way). --Xover (talk) 08:38, 14 December 2020 (UTC)[reply]
@Xover, @Billinghurst: I have reverted to the version that fixed Jan's reported issue with the collapsing. Reverting this Gadget and not Mediawiki:Gadget-PageNumbers.js's associated changes has left the whole thing broken in the respect that the moving of headers, footers and templates out of the layout-ed area was totally killed by the original reversion.
Billinghurt: please let me know if you still see your issue now.
We can deal with the load issue separately. Inductiveload—talk/contribs 12:55, 14 December 2020 (UTC)[reply]
Retrieved from "https://en.wikisource.org/w/index.php?title=MediaWiki_talk:Gadget-PageNumbers-core.js&oldid=14025515"