Page MenuHomePhabricator

Module for the Charinsert gadget sometimes doesn't load
Open, Stalled, MediumPublic

Event Timeline

Ineuw created this task.Feb 7 2015, 6:12 AM
Ineuw raised the priority of this task from to Needs Triage.
Ineuw updated the task description. (Show Details)
Ineuw added a subscriber: Ineuw.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 7 2015, 6:12 AM
Ineuw updated the task description. (Show Details)Feb 7 2015, 6:13 AM
Ineuw set Security to None.
Ciencia_Al_Poder added a subscriber: Ciencia_Al_Poder.

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.

gerritbot added a subscriber: gerritbot.

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.

He7d3r renamed this task from Charinsert extension to Charinsert gadget.Feb 7 2015, 3:30 PM
He7d3r updated the task description. (Show Details)
He7d3r added a project: CharInsert.
He7d3r removed a subscriber: gerritbot.
He7d3r added a subscriber: He7d3r.Feb 7 2015, 3:34 PM

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.

He7d3r renamed this task from Charinsert gadget to ResourceLoader does not load the module for the Charinsert gadget.EditedFeb 7 2015, 4:18 PM
He7d3r edited projects, added MediaWiki-ResourceLoader; removed CharInsert.

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

Ineuw added a comment.Feb 7 2015, 4:20 PM

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.

Ineuw added a comment.Feb 7 2015, 8:39 PM

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

GOIII added a subscriber: GOIII.Feb 7 2015, 9:24 PM

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);

Ineuw added a comment.Feb 7 2015, 9:32 PM

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.

He7d3r added a subscriber: Krinkle.Feb 7 2015, 9:34 PM

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.

GOIII added a comment.Feb 7 2015, 9:36 PM

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.

He7d3r added a comment.Feb 7 2015, 9:40 PM

@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

matmarex removed a subscriber: matmarex.Feb 7 2015, 9:45 PM
GOIII added a comment.Feb 7 2015, 9:48 PM

@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.

Ineuw removed a subscriber: Ineuw.Feb 8 2015, 12:13 AM
GOIII triaged this task as Medium priority.Feb 8 2015, 6:03 AM

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...

matmarex closed this task as Resolved.Feb 8 2015, 9:26 PM
He7d3r reopened this task as Open.EditedFeb 8 2015, 10:43 PM

Loading an unnecessary module for all users (and for all actions, not only in the 'edit' action) is a not a fix, but a hack.

He7d3r updated the task description. (Show Details)Feb 9 2015, 12:07 AM
He7d3r updated the task description. (Show Details)

(..) 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.
Krinkle changed the task status from Open to Stalled.Jul 3 2015, 12:25 AM

See previous comments. mediawiki.toolbar loads by default and in-time on the edit page. The plain conditional is confirmed to work. Using mw.loader.using() is undesirable as that will cause it to be loaded on-demand even when not on on a page that has a toolbar.

If you want to use the mw.toolbar on any other page, make sure to call mw.loader.using() and put your code in its callback. It is a module like anything else that is only loaded when you load it.

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.

GOIII added a comment.EditedJul 4 2015, 2:29 PM

. . .
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.

* Generated JavaScript links use insertTags() from wikibits.js.

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.

GOIII added a comment.EditedJul 5 2015, 2:32 AM

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..

TheDJ added a subscriber: TheDJ.EditedJul 5 2015, 11:46 AM

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.

GOIII added a comment.Jul 5 2015, 11:39 PM

Fwiw...

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

jquery.wikiEditor.toolbar.config.js#L468

'deferLoad': true,
TheDJ added a comment.Jul 6 2015, 12:46 PM

'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.

GOIII added a comment.EditedJul 6 2015, 10:20 PM

'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').

GOIII added a comment.Jul 6 2015, 10:32 PM

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

'deferLoad': true,

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

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

GOIII added a comment.Jul 16 2015, 9:54 PM

'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.

Krinkle renamed this task from ResourceLoader does not load the module for the Charinsert gadget to Module for the Charinsert gadget sometimes doesn't load.Nov 18 2016, 7:30 PM
Krinkle edited projects, added CharInsert; removed MediaWiki-ResourceLoader.

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.