https://bugzilla.wikimedia.org/show_bug.cgi?id=39268
Krinkle <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |code-update-regression CC| |mediawiki-bugs@nadir-seen-f | |ire.com Summary|Support dynamically binding |[Regression] Dynamically |additional focusable |added textarea within the |textarea's to the legacy |editform no longer work in |toolbar editor |the classic edit toolbar Severity|normal |major --- Comment #21 from Krinkle <[email protected]> --- (In reply to comment #20) > Hang on. IT USED TO WORK!!! > > The toolbar used to work in the three component fields and it was a > programming change in more recent MW changes that caused this to stop > functioning. It is simply not an enhancement That it used to work doesn't mean the problem isn't in the Proofread extension. The classic toolbar never supported dynamically inserted textarea's. It always bound to specific (or any) textarea's when the page is ready, and keeps event handlers on them. However since you seem to be convinced the regression was caused by a change in core and not in the Proofread extension, I've dug into the history of the classic toolbar. Turns out there was indeed a point where a certain implementation detail was lost in a rewrite: * r59832 (fixups r59655): In 2009, Dantman optimised the toolbar binding logic by using event delegation on document.editform instead of binding to all known textareas found by document.createElement('textarea'). The purpose of it was to support multiple textareas on the editor - as registered and output by the server side. It wasn't for the purpose of Proofread and not to support dynamically inserted textarea's per se. That was a coincidental consequence of the more efficient approach for event binding. But only as long as it is created and attached to the dom *within* the subtree of the id="editform" element. * r86603: In April 2011, DieBuche rewrite the toolbar code from legacy/common/edit.js to a new module: mediawiki.action.edit. In doing so all features were preserved, including supporting edit forms with more than 1 textarea (such as in SemanticMediaWiki). However the new implementation only worked for textarea's that exist on the page before the editor is initialised. This wasn't a problem as nothing in the previous version suggested this was an intentional side-effect. It was just how it was implemented. Somewhere along the line the Proofread extension was written and basically just happened to work as it was because of it. > This is simply a request to have text inserted at the point where the cursor > is located, wherever the cursor is located (within the three false sections). Easier said than done. That would require the editor to know about the textarea. And know which textarea's are relevant and which ones are not. For example, if another widget presents a balloon dialog somewhere else on the page, the toolbar may not be related to it at all. Visually it is easy to see which ones logically belong to the editor, but technically it isn't so trivial. Especially if one can pop up at any time. It may not appear that way to you, but the Proofread extension inserts these additional textarea's with javascript, not with PHP. Which means that unless the editor waits for the proofread extension javascript to finish, they are inserted too late. Yes, it can be implemented. But it hasn't been done yet, and it never was. As explained earlier it worked by coincidence and stopped working in a rewrite that didn't cause any regressions in code using supported and documented features. > * Wikisource is a major sister, one feels that we almost have to apologise > for taking time away from enWP projects. I don't give shiny rats' ass about English Wikipedia (not in particular anyway). A bug is a bug. > * Proofread page is our major tool to present works and to have texts > available. So who maintains it? Has it been thoroughly reviewed? Does the maintainer keep up with bug reports, latest standards and release notes and changes in MediaWiki core? > * It is not an insignificant issue. > > I don't see why it is seemingly dismissed as not important, or not an issue. It is not considered unimportant. I was merely saying that it doesn't seem to be caused by MediaWiki core and I don't know enough about Proofread or Wikisource to fix it myself. --- So a lot of information on the table. Lots of different approaches to take from here. I'm going to recommend we change the implementation of the classic edit toolbar again to use even delegation, and this time document that it is with the intention of supporting dynamically inserted textarea's (as opposed to being an implementation detail for efficiency reasons). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
