It can be switched on by var cdAllowEditOthersMsgs = true; ;-)

What's wrong with standard "Edit description" feature? Topic name edit is just like a normal message edit.

Theoretically this could be done by a plugin relying on cd.sectionsReady hook. But this may lead to problems with new messages navigation and messages highlight zone redrawal mechanism.

Fixed here and here.

Fixed here.

Thanks for the PR, but I think using CSS would be a better idea. We would have to add a space between items for white-space: nowrap to work properly.

Hello. @Aklapper, well, it's nothing but a small project, it's total code size is about 400 KB after Babel, 200 KB with uglification. I plan to spread it to other projects, so interproject communication on Phabricator would be nice. Its github repository is here: https://github.com/jwbth/convenient-discussions. So, do you ask to create a repository on Gerrit too?

Thanks.

@Schnark So, what is it based on? Technical unfeasibility? Perceived lack of necessity? There are users who are not happy about it. I think, some would say, there is no need in the hiding/showing functionality at all if the state is not saved in a cookie. The only thing it does when used on one page is saves a small amount of space.

The problem is that adding the class hatnote doesn't help, I've tried that on https://ru.m.wikipedia.org/w/index.php?title=Истомин,_Константин_Иванович&oldid=96534177.

Just to make you know: in ruwiki, we adapted RockMFR's "magic editintros" to work with VisualEditor (although the resultant 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 who ask for interface-admin (see T190015) 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 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 to some centralized place altogether? Their scattered presence in HTML causes problems like mentioned here, in T186965 and in T200704 (I opened the last task 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.