Page MenuHomePhabricator

German character insertion toolbar appears multiple times in conflict screen
Closed, ResolvedPublic5 Estimated Story Points

Description

Motivation
There is a bad interaction between Two-Column-Edit-Conflict-Merge and the new character toolbar the German community created as a replacement for the removed core toolbar feature which also broke the old character toolbar just a few weeks ago. The new code obviously attaches to all elements that match a certain CSS selector.

Acceptance Criteria

  • The special tool bar does not appear on hidden text fields, but only where suitable

Notes

  • Come up with a proposal how to solve the issue
  • Contact the maintainer to discuss the proposal

Event Timeline

Lea_WMDE updated the task description. (Show Details)Dec 18 2018, 10:44 AM
thiemowmde triaged this task as Medium priority.Dec 18 2018, 12:43 PM
thiemowmde added a project: patch-welcome.
thiemowmde moved this task from Incoming to Edit Conflict Handling on the archived--TCB-Team board.

I did a brief investigation. Before T30856, the toolbar code was https://de.wikipedia.org/wiki/MediaWiki:Onlyifediting.js. But this file is not used any more. The current toolbar is a gadget that is enabled by default. The code is in https://de.wikipedia.org/wiki/MediaWiki:Gadget-editMenusDef.js, which depends on https://en.wikipedia.org/wiki/User:PerfektesChaos/js/menuSwitcher/r.js (the "r" refers to an uglified "release" version, see https://en.wikipedia.org/wiki/User:PerfektesChaos/js/menuSwitcher/d.js for the uncompressed "debug" version). There is a line of code that says

Position   = [ { selector: "textarea:enabled",

This is, as far as I can tell (I would love to hear what other developers think about the readability of this code), the CSS selector. In other words: Currently, the toolbar attaches to all <textarea> elements on the page, no matter where they are or what their meaning is.

The only possible hack I can imagine is adding disabled="disabled" to all our <textarea>s as long as they are hidden, and removing it the moment the corresponding edit pen icon is clicked.

That, or fixing the gadget to only attach to the one #wpTextbox1 textarea it should care about.

Lea_WMDE updated the task description. (Show Details)Jan 10 2019, 1:33 PM
Lea_WMDE set the point value for this task to 5.

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.

PerfektesChaos added a comment.EditedJan 17 2019, 9:30 AM

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.

thiemowmde closed this task as Resolved.Dec 4 2019, 9:53 AM