Just to make you know: in ruwiki, we adapted RockMFR's "magic editintros" to work with VisualEditor (although the resuntant script is rather hackish), see https://ru.wikipedia.org/wiki/MediaWiki:Gadget-blpEditNotice.js.

@Krinkle Thanks for the detailed explanation.

Right now we have at least 3 widely used gadgets that would need such query, probably there will be more. Having 5–10 additional requests doesn't seem to make negligable difference. Many such gadgets also add elements that shift content on pages which in turn causes misclicks, so the earlier they run the better. Anyway, is it so difficult to implement? I thought splitting large JS files into modules according to the semantics of different code parts and loading them, together with other modules, in one package is exactly what ResourceLoader is for.

Right now many people asking for interface-admin permissions in ruwiki are worried about the ability to edit gadgets data. But with the current state where the integration of JSON with gadgets is poor, the ability to load external JSON for gadgets is very limited. Hence, the efforts to integrate of JSON with ResourceLoader as soon as possible are essential from the perspective of the interface-admin flag purpose.

Can't the <style> tags be moved in some centralized place alltogether? Their scattered presence in HTML causes problems like mentioned here, in T186965 and in T200704 (the last task I opened just recently).

Moreover, it's true for user JS/CSS as well. As I remember, those used to be updated instantly.

• The behavior is not consistent: if a reference (the text at the bottom of the page) is visible to the user (i.e. if the citation link's (like [1]) target is visible in the screen), hovering the mouse on the citation link won't show a pop-up with the reference. Instead, the reference at the bottom will just be highlighted. You can see an example here (the citation link is at the right of the screen below the image): try hovering the citation link when the Sources section is visible on the screen or not. Note that this is an intended behavior which can be easily changed in the code and is common to both implementations.

Yes, pretty much looks like.

As I can see, the first change is live. How about the second (adding newlines that weren't in the source)?

Sure, purge is useless in such cases.

In T179544#3734623, @MaxSem wrote:

I have a silly question: why do we even use reference names in IDs? Because these IDs are also using reference numbers, they're not stable anyway.

No, was just trying to select an appropriate tag.

That's very disturbing as many popular images are effectively spoiled after reuploading with minor adjustments.

Don't really think it depends on that, but added.
BTW, my self-written code (see at the bottom) for 2017 wikitext editor works well in both cases.

Okay I assume I'm wrong about opt-out (just too many fellow users reported that). The issue still stands though.

We largely updated Reference Tooltips gadget in ruwiki, and welcome other wikis to update to it. Other suggestion is to create a global gadget based on it.

• Tooltip style & animations are updated to be consistent with Page Previews' style & animations.
• Many bugs are fixed (see the list here).
• Harvard-style citations are now supported.
• Tooltips inside tooltips are now working properly (they did work before, but there were bugs associated with this behaviour). See the animation.
• An option is added that allows to convert native browser tooltips for titled <abbr> tags and such into gadget tooltips. It is default on touch devices, allowing users of the desktop version on such devices to see them.
• The settings dialog is rewritten using OOUI (its modules are loaded on demand) and looks similar to the Page Previews settings dialog.
• Saving the settings doesn't require page reload anymore.
• The code is refactored. Tooltips & elements having them are objects now. The script used jQuery and pure JavaScript inconsistently – now it uses the first everywhere where appropriate (performance losses are negligable).
• Old IE support is removed (JavaScript isn't loaded to them anyway).
• The coding conventions are applied.

See more details at the gadget's mediawiki.org talk page.

Thank you, @matmarex. Sorry, had to time.

Thanks, I guess that's it.

I guess I'm incorrectly mixing DOMContentLoaded and moments of execution of its handlers here, here's one of my 2016 tests of in which order the hooks/events are fired on the action=edit page:

1480205746966 resourceloader.loadEnd
1480205747184 wikipage.content
1480205747356 wikipage.editform
1480205747566 ext.wikiEditor.toolbar
1480205747569 $
1480205748301 doneInitialSections

In T192623#4249151, @Krinkle wrote:

This internal hook was not supported for use by gadgets. The public interface provides wikipage.content and $().

Well, it was present in the documentation (now it's not). As I remember, it was a good way to catch a very early moment which used to happened even before DOMContentLoaded has fired. Not sure if it was conceptually appropriate for our purposes though; we used it to coordinate loading order of many related scripts & gadgets. Anyway, we now don't need it where we did, since we now do most of the task with gadget dependencies.

Scripts dependent on resourceloader.loadEnd hook have broken. Was it planned? Was the hook removed?

Thanks! I guess the method we use was acquired from some documentation that is now outdated.

So, how should all the custom toggles be repaired across wikis (example)? Is adding .mw-made-collapsible a proper fix?

Hey, I don't know why you broke prefix:namespace: search, just one note: the warning text

The namespace found in the search term prefix: is not compatible with the namespaces requested. You can fix it by prefixing your query with all:.

is a lie for all wikis except enwiki: all: search doesn't work there, and that's T165110: Let search with "all:" keyword on non-English projects, not only with its translations.

Okay, but so far it has worked stably.

Please don't hurt {{subst:REVISIONID: {{subst:FULLPAGENAME}} }} which is used as {{<includeonly>subst:</includeonly>REVISIONID: {{<includeonly>subst:</includeonly>FULLPAGENAME}} }} in some ruwiki templates, inserting the last known revision ID in order to generate &direction=next link for the viewer which will point to the newly saved revision (for example).

While we have implemented a JavaScript fix in ruwiki for stabilized articles, from time to time we have users (example) who switch somehow (knowingly or unknowingly) to the stable version of not-a-stabilized article. Then they edit with VisualEditor, probably don't notice the warning that they are editing an old version, save the article—only to get an ORES-based bot to revert their edit due to deletion of text. Is this fix going to exclude such cases, or does it apply only to stabilized articles?

@Schnark, wow, thank you! Haven't even thought of that. So, only accesskey issue stays.

@Deskana I'm sorry, I've updated the task description.

As for now, the issue disappeared for all asked users.

Interestingly, only a part of scripts / gadgets is down. Even some styles are fine. For one of our gadgets, MediaWiki:Gadget-UTCLiveClock.js, script part is fine, style part is not.

As for now, the problem is present for every user I asked, except for Monobook users. If you try load artibrary page with ?useskin=monobook, it's fine.

Thanks for the split, I will do as you advise next time.

Love ya guys, always coming across this page when trying to recall those hook names & googling. How about adding this at https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook?

1. https://ru.wikipedia.org/w/index.php?title=MediaWiki:Gadget-wikificator.js&diff=prev&oldid=91933003
2. https://ru.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=prev&oldid=91933212
3. https://ru.wikipedia.org/wiki/MediaWiki:Gadget-wikificator.css
4. https://ru.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=91933060

Yeah, this is more about the need to do something like this in the global CSS rather than about long summaries.

What do you expect?

I don't mean the Recent changes block itself, what I mean is just disappeared margin here:

It's even worse.

It adds foreign CSS too, messing with the page layout (removing the indentation between the page title and the content, for example).

This is reported by many users in ruwiki, though the effect is not as intense as in Iniquity's case for the most.
Also, in my case, "Your alerts" icon becomes red, although no new notifications appear there. Maybe this is connected.

See https://bugs.chromium.org/p/chromium/issues/detail?id=789163. The change in Google Chrome behaviour is possible.

As Sunpriat2 has found out, this is because of this security update: https://chromereleases.googleblog.com/2017/12/stable-channel-update-for-desktop.html

Group 2 is back on wmf.7. When the update is gonna be?

@IKhitron In order to make fragments with spaces work as underscores at the first page load, the following JS code could be used in personal common.js or elsewhere:

var hash = navigator.userAgent.indexOf( 'Firefox' ) === -1 ? location.hash :
    decodeURIComponent( location.hash );
if ( hash.indexOf( ' ' ) !== -1 ) {
    var restoredFragment = hash.substring( 1 ).replace( / /g, '_' );
    var targetElement = document.getElementById( restoredFragment );
    if ( targetElement ) {
        if ( typeof targetElement.scrollIntoView !== 'undefined' ) {
            targetElement.scrollIntoView();
            if ( typeof history !== 'undefined' ) {
                history.replaceState( {}, '', '#' + restoredFragment );
            }
        } else {
            location.hash = '#' + restoredFragment;
        }
    }
}

As I noted in T169315#3735840, mediawiki.hlist is so far very weak compared to Edokter's snippet. Starting with the fact that mediawiki.hlist has '•' as a delimiter (instead of ' • '), which creates disproportionate space if <li> elements are not followed directly one after another without any spaces. ;: lists aren't supported too.

Edokter at enwiki has done a huge job implementing .hlist class, it's very well-designed. Many wikis use it, including eswiki, ruwiki, frwiki. Why should this Minerva novelty, consisting of a few rules, replace it, making local technicians have to do a huge job resolving the conflict and/or replacing .hlist with .hlist-separated all over the site? Couldn't it just receive another name and/or be limited to Minerva interface area?

Please don't miss {{anchorencode}} part of the task. Quite a lot of templates in ruwiki using {{anchorencode}} / mw.uri.anchorEncode() to encode anchor links have broken in many cases due to use of []. en:Module:Footnotes, for one, will break in many cases if you try delpoy to enwiki.

Thank you, @Anomie, I will choose another place. Actually, the lack of a place where local wikis' technicians could consult with MediaWiki developers seems to me to be an actual problem, not sure if the places you listed fulfill this need completely.

Hi @hoo, we've been implementing the functionality mentioned in the task description, namely generating unique reference names for references created from Wikidata (and solving some adjacent problems), in ruwiki (after T175725: Deploy HTML5 sections to WMF production was done for ruwiki and some things broke). Do you have any thoughts on which algorithm is better suited for generating hash values for references? I've done my modest research and stopped at fnv164 as it is fast, and 64-bit hash reduces collision probability to a negligibly small value. But maybe I am missing something.