Thank you for informing me; I am not using that feature, and I was not aware that any other script is inserting hidden enabled textarea elements at that stage. CodeMirror, CodeEditor, Schnark, Ace, wikEd are using disabled property while sleeping if I recall correctly, or show up later. At least I have tested interaction and did not detect any problem.

I have changed the code of the background JS already. display:none anchor elements will be dropped. I should think a little bit more on context and possible effects. However, it may take some days or a week for testing and experiencing to get downstream from my hard disk via BETA-dewiki to debug state to release state.

BTW, it is intended that on Upload form or any other page with multiple textarea fields expecting large amount of text input each big input element shall be equipped with input assistance directly attached.

It might happen that some browsers regard hidden form fields as disabled, and others do not. However, the gadget shall not rely on this assumption.

Thanks a lot for working on this!

For your information: I tried, but as far as I can see we can't add disabled properties to the textareas in the TwoColConflict interface. The textareas are created server-side. For users without JavaScript, the conflict resolution screen opens with all fields already being editable textareas. Only if JavaScript is available all these textareas are hidden, and can be re-activated with the edit icons.

disabled properties could only be added with JavaScript, but there is no way to guarantee if this code would be executed before or after the toolbars have been added. I can't see a way to specify this dependency at the moment, as the toolbar code is not a registered MediaWiki-ResourceLoader module.

The solution you implemented now might run into the same concurrency problem.

My suggestion is to limit your code to textareas with a name that starts with "wpTextbox" (there might be more than one): textarea[name^=wpTextbox]:enabled

Equipping any page, even a Special:Blankpage with any kind of forms and input facilities shall be supported, no matter how an identifier is called. Therefore wpTextbox is limiting too much on official MW generated pages.

I will look into details of TwoColConflict and ponder about a solution that keeps out specifically this one. The menuSwitcher capabilities allow a wide range of customization. Should be detectable by mediawiki.user or selectors specific for TwoColConflict in a :not() rule. Or excluding the entire page situation.

The dewiki application has ext.gadget.editMenus RL ID (doc), but that should not pollute a world wide code.

After a good sleep, I am now dreaming of MutationObserver and the basic software should do:

• Do not equip initially any disabled or hidden input element, whatever user request might tell.
• Observe all requested input elements by MutationObserver.
• Hide toolbox as soon such element will be disabled or hidden.
• Pop up or create toolbox as soon such element will be enabled or displayed.

Browser availability is to be checked, but should disseminate soon. 2ColEdConflMgr is in BETATEST state, might take a while until regular.

Will take a while for testing by myself and by debug stage user community.