This also happens on german wiktionary. see: https://de.wiktionary.org/wiki/Wiktionary:Fragen_zum_Wiktionary#Textbausteine

That should be some JavaScript issue with another gadget.

I've tried enabling all available gadgets but the charinsert extension was still being shown below the edit area (although the web console displayed a lot of warnings about deprecated features).

Someone with the problem should try to disable all gadgets in preferences, and then re-enable them one by one, testing whether the charinsert works again, to see which one is the culprit.

Change 189207 had a related patch set uploaded (by Mvolz):
Bug T88897 Fix: Add popPending to error case

https://gerrit.wikimedia.org/r/189207

Patch-For-Review

I'm sorry, it is not the same problem that we have in german wiktionary. The charinsert bar doesn't disappear here. It is still there, but not working. So this seems to be something different. Might be a race condition while loading JavaScripts.

This might be related to the change "EditPage: Optimise loading of mediawiki.toolbar module", which was deployed with MediaWiki 1.25wmf14 on 13 January 2015, or (less likely) "Split mediawiki.toolbar from mediawiki.action.edit", deployed on 14 October 2014.

I have the gadget enabled, however the code from
https://en.wikisource.org/wiki/MediaWiki:Gadget-charinsert.js
doesn't seems to be loaded by ResourceLoader (on Firefox 35.0.1):

Testing by disabling all gadgets, and then re-enabling them one by one is a good idea and will do so immediately. It certainly is within the scope of my technical ability.

Disabling all gadgets and just re-enabling the Charinsert has no effect.

Take a few days off and everything goes to pieces...

undid this addition and the CharInsert bar is back...

https://en.wikisource.org/w/index.php?title=MediaWiki:Gadget-charinsert-core.js&diff=5236858&oldid=5236783

The gadget works for me.

@Ineuw, when you're viewing a page where the gadget doesn't load, can you open your browser's JavaScript console, paste the following and press Enter: mw.loader.moduleRegistry.user.state, and tell me what is the result? (It should be a short text, for example "ready".) Alternatively, if you can't open the console, you can instead paste the following into browser's address bar, and press Enter: javascript:alert(mw.loader.moduleRegistry.user.state);

matmarex, the solution by George Orwell III was to remove the "Jan 23 Krinkle toolbar bit addition and dependency changes" and the Charinsert loaded immediately. If it fails again, I will do as you suggested. And yes, using the console is not a problem, but until your post I didn't know how to locate the problem.

In T88887#1023031, @GOIII wrote:

Take a few days off and everything goes to pieces...

undid this addition and the CharInsert bar is back...

https://en.wikisource.org/w/index.php?title=MediaWiki:Gadget-charinsert-core.js&diff=5236858&oldid=5236783

Now you are not using the toolbar in the way @Krinkle recommended on T86235#976999.

Oh well. I didn't see the en.WS rem'd lines in the Wikipedia application of CharInsert so he'll have to address it without breaking it when he gets around to it I guess.

@GOIII: ext.gadget.charinsert-core does not depend on any code from the small module mediawiki.action.edit, so this does not look right: https://en.wikisource.org/w/index.php?diff=5236850

In T88887#1023042, @He7d3r wrote:

@GOIII: ext.gadget.charinsert-core does not depend on any code from the small module mediawiki.action.edit, so this does not look right: https://en.wikisource.org/w/index.php?diff=5236850

I agree - something or things still need further tweaking. But as an admin my main concern is the restoration to a state were things work as they did before for en.WS contributors. This has been accomplished so it stays that way -- warts and all -- until somebody comes along and improves upon the gadget without breaking it.

And that's not me in this instance - I fight for maintaining functionality; development is not my no longer of immediate concern, again, in this instance and as things currently stand.

In T88887#1022685, @He7d3r wrote:

This might be related to the change "EditPage: Optimise loading of mediawiki.toolbar module", which was deployed with MediaWiki 1.25wmf14 on 13 January 2015

It would make sense if the gadget is loaded before mediawiki.toolbar, because the conditional added by Krinkle would be false at this point. The strange thing is that it worked for me but not for other users...

In T88887#1023702, @Ciencia_Al_Poder wrote:

(..) It would make sense if the gadget is loaded before mediawiki.toolbar, because the conditional added by Krinkle would be false at this point.

mediawiki.toolbar is loaded from the top queue. It loads before any gadgets. If it isn't loaded by the time that gadget initialises, it will never load. If it doesn't load, it means the user is not on an edit page.

In what scenario (page and action) are you observing the problem?

<charinput> is also useful even if you are not in edit mode. Think about this: In german wiktionary we are using <charinput> to support entering IPA-Characters, which are not available on a keyboard, into an input field. See: https://de.wiktionary.org/wiki/Hilfe:Reime#Reimseiten_anlegen This is used on a page which is not in edit mode. To make this work we had to add some javascript in MediaWiki:Common.js

if (wgPageName == "Hilfe:Reime") {
mw.loader.load(["mediawiki.action.edit", "mediawiki.toolbar"]);
}

Because this is so weird, i would prefer:

1. <charinput> should work on all pages, independent if they are in edit mode or not.
2. <charinput> should not use a global function "insertTags".
3. The global function "insertTags" should be moved to mw.util.insertTags or somewhere else.
4. This new function should be loaded on every page where <charinput> is used.
5. If 4. is not possible the new function should be placed in a module which is always loaded.

In T88887#1423553, @Krinkle wrote:

. . .
Whether charinsert itself works and what modules are loaded on pages using charinsert is up to the CharInsert extension and not related to Gadgets or ResourceLoader.

OK but somewhere along the line, the Charinsert extension relied on the since deprecated wikibits.js per the Notes section here.

When you go to ResourceLoader's deprecated-identifiers slash legacy-javascript page for Wikibits.js to look for the replacement to insertTags(), there is no replacement listed.

But when you go to the section for Edit.js on the same legacy javascript page for ResourceLoader, you do find insertTags() listed as deprecated and it's replacement is given as mw.toolbar.insertTags.

Applying that given replacement as a dependency for the common Charinsert gadget does not generate the charainsert bar at all.

Removing mw.toolbar as a dependency for the common Charinsert gadget does generate the charinsert toolbar but errors out to insertTags() undefined when selecting any of characters listed for "insertion".

So what is the right way to insure insertTags() is somehow included in the dependency chain without including mediwiki.toolbar given all the above? Seems like a catch-22 to me thanks to no real (or working?) replacement module for what has been formally deprecated to date.

OR maybe MediaWiki:Gadget-charinsert-core.js itself needs an "overhaul" to somehow avoid using insertTags altogether?

The module registered by the CharInsert extension still to this date does not register itself with ResourceLoader. The CharInsert uses legacy HTML onclick handlers with inline JavaScript calling the global insertTags().

I was under the impression that it was a wiki's own gadget calling insertTags(), not the CharInsert extension. (Both could in theory be the case, but the gadget problem will solve itself once the extension works properly).

The CharInsert extension, as being in control over when to parse and display its interface to the user, can ensure that it loads the mw.toolbar module accordingly. This way we don't needlessly load mw.toolbar on all pages of a wiki – This in contrary to adding it as dependency of your gadget, as that would cause mw.toolbar and the gadget to be loaded on all pages for all users (which cut into your global performance budget and negatively impact user experience). All this because a gadget is not in control over when it loads, and has no way to know that from the CharInsert extension.

I can help fix the CharInsert extension to 1) Ensure it uses mw.toolbar.insertTags instead of the global legacy alias to it – both of which are currently present by accident on edit pages but not in other edge cases. 2) Have it provide a mw.hook so that gadgets can hook into it would duplicating its dependencies.

Before I continue, however, I have one more question. Why do we have charinsert gadgets on different wikis? They all tend to to the same thing in different ways, but why are they doing anything at all? Isn't that what the CharInsert extension is for? Why, for example is MediaWiki:Gadget-charinsert-core.js specifying all the symbols. Isn't that what [[MediaWiki:Edittools]] is for? I imagine things would be a lot more maintainable and load faster by using the interface CharInsert specifically provides for this purpose.

My best guess would be that there is one small or major feature or bug in CharInsert that led to users working around it. Let's get to the bottom of that and instead direct the effort of those gadget maintainers towards the CharInsert extension so that everybody wins.

T13130: Provide a preference to disable the CharInsert tool, to save users' bandwidth?

In T88887#1426917, @He7d3r wrote:

T13130: Provide a preference to disable the CharInsert tool, to save users' bandwidth?

Yup -- just one reason of many that I'm aware of. Not many cared for the Edittools' inflexible approach to 'character hosting' to put it politely.

That said, best case scenario is to eliminate both EditTools & the CharInsert gadgets out there once and for all by making the current WikiEditor/VisualEditor toolbars' character sets easily customizable instead of loading every god damn language character set under the sun by default to get around the fact neither currently really are.

I had assumed that is where things were headed when the sets were made into their own sharable unified resource that supposedly "anything" could draw upon; not just VE/WE/etc..

Several things come to mind:

1: MediaWiki:Edittools contained the original character insertion set, but is totally unparse-able by javascript tools
2: MediaWiki:Edittools is used to include editing advice AND the characters to insert
3: Extension:Charinsert can be fixed, but it does way too little for many sites to be actually useful.
4: Most sites therefor use something like Edittools.js, which is more advanced than anything, it has UI to efficiently deal with a large set of special characters
5: Edittools.js has a no-JS fallback, which makes some ppl happy
6: These elements have been a consistent fixture of so many sites for so long, that people will hate any change there. (Their gadget form is relatively new, but these hacks have been around since 2007ish)
7: WikiEditor charinsert is 'slow' (pre emptive loading after page is done?).
8: If you need custom characters ALL the time, you want those tools close-by. This is why the condensed presentation, with 1 'set' consistently visible is so much desired by some. Same if all you do is work on IPA.
9: Edittools.js allows you to insert wikitext, for common use tasks, that no one ever bothered to integrate into the old toolbar or the Wikitext toolbar.
10: It's hard to change what is in the default set of mediawiki.language.specialCharacters. This would lead to conflicts between language versions trying to use a common charinsert set. In some language, certain characters are not condoned by style guides, whereas in some other countries they are bare essentials. The quote signs are a good example of this. Hidden away into deeper parts for some languages, in the first panel in others.
11: Edittools.js allows for 'spaces' inside the main group, giving you 'subgroups' of related characters.
12: Edittools.js interface is extremely 'condense' and thus highly efficient for experienced editors (monobook vs Vector issue).

So I would say:
1: Split out MediaWiki:Edittools to fulfill it's various purposes....
2: Rework the output of the non-JS fallback to show the charinsert as defined in the specialcharacters modules, or just convince people that JS is a requirement for this kind of functionality.
3: Revamp the old WikiEditor into this century and allow you to insert wikicode elements that currently require usage of the Edittools inserter (comments, ref, nowiki, noinclude)
4: Make it handier to use WikiEditor char insert and the Advanced toolbar at the SAME time. (think docklets, instead of pages in toolbars ?)
5: Add subgrouping to the WE and VE charinsert, less spacing between individual chars, and more between groups.

In the mean time, we could rewrite the edittools scripts to reuse the new specialcharacters RL modules, but probably it will take too much time to do that, might as well focus on the big picture.

Fwiw...

In T88887#1427226, @TheDJ wrote:

. . .
7: WikiEditor charinsert is 'slow' (pre emptive loading after page is done?).

jquery.wikiEditor.toolbar.config.js#L468

In T88887#1428354, @GOIII wrote:

'deferLoad': true,

Yup. Actually while I was casually reading through that part of the code, I noticed this rather embarrassing 1 second delay after pressing an unloaded tab... https://gerrit.wikimedia.org/r/#/c/223017/ That's probably 95% of the delay that people experience with char insert and WE... Bit shameful that we only figure that out now.

In T88887#1429495, @TheDJ wrote:

In T88887#1428354, @GOIII wrote:

'deferLoad': true,

Yup. Actually while I was casually reading through that part of the code, I noticed this rather embarrassing 1 second delay after pressing an unloaded tab... https://gerrit.wikimedia.org/r/#/c/223017/ That's probably 95% of the delay that people experience with char insert and WE... Bit shameful that we only figure that out now.

That's Great!!!! Many thanks @TheDJ, @Krinkle.

Hopefully, that change can help move things along in addressing T70791 afterwards; it to is semi-related to the character set question in that the delayed loading seemed to prevent any means of locally initiated deletion, modification or addition to WikiEditor's default sets (a la it's 'booklets').

Err... I guess I'd be remiss if I didn't also mention the same...

... exists for the 'Help' booklet of WikiEditor as well just in case that matters somehow.

See jquery.wikiEditor.toolbar.config.js#L583

In T88887#1429495, @TheDJ wrote:

In T88887#1428354, @GOIII wrote:

'deferLoad': true,

Yup. Actually while I was casually reading through that part of the code, I noticed this rather embarrassing 1 second delay after pressing an unloaded tab... https://gerrit.wikimedia.org/r/#/c/223017/ That's probably 95% of the delay that people experience with char insert and WE... Bit shameful that we only figure that out now.

Follow-up: @TheDJ, it seems that one second delay was for the benefit of the DIV wrapper that held the spinner graphic. Without it, no spinner is displayed anymore upon clicking on one of the booklets (Help, Special Characters, etc.) so it might be worth visiting the question of whether or not to remove those spinner wrappers from the extension's code.

As an aside: the loading of the Index and Page sub-booklets are still being 'defered' (I'm guessing still per the deferLoad: true, setting) so its still not possible to manually add or remove booklet elements as is the case with other toolbar elements. In short, the story T70791 is still unchanged.

A related issue is again present on EnglishWikisource..

https://en.wikisource.org/w/index.php?title=Page:Alcohol,_a_Dangerous_and_Unnecessary_Medicine.djvu/207&action=edit
CharInsert doesn't load despite being selected in Gadgets...in the preferences..

@ShakespeareFan00: That's in T208664 unless you have checked that it is actually a Module issue that you run into?

Thanks, for redirecting me.

I apologize for this late reply because I am not in the habit of ignoring posts addressed to me. The character-insert is accessible at all times. My only issue is that it doesn't stay on top (above the edit window), as how I set it in my vector.js.