Open the dialog for the 'General Election 2015' table on https://en.wikipedia.org/wiki/Tooting_(UK_Parliament_constituency)?veaction=edit . Observe that it takes several seconds to load (>10s for me).
Improvements were made to this which has lessened the problems significantly, but it could still be improved further.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T71799 Editing a transclusion with many templates hangs the browser | |||
| Open | None | T134814 Multi-part transclusion dialog a little slow to load | |||
| Resolved | matmarex | T153475 Trying to scroll invisible elements into view is slow | |||
| Resolved | matmarex | T153490 Using $element.closest( 'html' ).length to check whether an element is attached is slow | |||
| Resolved | matmarex | T153713 TextInputWidget#adjustSize should do nothing if widget is detached | |||
| Resolved | matmarex | T154024 Kill slow MutationObserver stuff in TextInputWidget | |||
| Declined | None | T176998 Try using SentinelJS (or stealing code from it) instead of nasty code in TextInputWidget#installParentChangeDetector | |||
| Resolved | matmarex | T154025 Element#updateThemeClasses results in a separate setTimeout for each widget, which has some overhead, making it slow |
Change 287776 had a related patch set uploaded (by Esanders):
Attach template form after building
The above patch speeds the test case up from ~10s to ~4s, so probably still room for improvement.
Like you said in one of the earlier (deleted) comments, yeah, it seems that TextInputWidget#adjustSize is the biggest problem. I don't really have any advice what to do about it.
One thing I noticed is that #adjustSize is often called multiple times, e.g. from ve.ui.MWParameterPage constructor:
this.valueInput = this.createValueInput() .setValue( this.parameter.getValue() )
Constructing the input results in an #adjustSize call later (from #installParentChangeDetector), calling #setValue results in another immediate call (from #onChange). This could be avoided by constructing the inputs with { value: this.parameter.getValue() } in their config, or changing OOjs UI not to call #adjustSize from #onChange if the element is detached, or maybe just debouncing calls to #adjustSize if we can't figure out how to call it less often.
Apart from that, it looks like you're just doing a lot of work here. There are 2180 element nodes inside .ve-ui-mwTemplateDialog. Perhaps some of that could be lazy-loaded?
In fact, it looks like it would be easy to do at least for the "info" and "remove" buttons in ve.ui.MWParameterPage, since they're not shown until the user focusses the field anyway. And PopupButtonWidgets turn out to be a bit expensive when you build 50 of them at once.
Also, some ideas for micro-optimisations:
I don't really have time to work on this, but do ping me with patches to review. :)
This is now taking <2s, although this is a smallish table so scale that up to a longer one and it's worth keeping this open.
Change 328380 had a related patch set uploaded (by Bartosz Dziewoński):
ve.ui.MWParameterPage: Restructure constructor to reduce needless work
With the test case from the other task (https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit) this is still pretty terrible. The dialog takes ~10 seconds to open, and the hundreds of MutationObservers from TextInputWidgets firing afterwards make it unusable for several more seconds after it has opened. The dialog itself is also very choppy, there's some weird stuff going on when you scroll.
The above is my last patch about this for now, this isn't terribly pressing. For whoever looks here next, I suggest lazy-loading things and somehow magicking away the MutationObservers.
Change 328380 merged by jenkins-bot:
ve.ui.MWParameterPage: Restructure constructor to reduce needless work
The example I provided, https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit still takes ages, and in firefox, I get the unresponsive script popup. So for these lists it is still far from working. And Zaandam is even a relative short list.
Indeed, it takes ages for me too. This is why the task remains open, and why I added to the description that "Improvements were made to this which has lessened the problems significantly, but it could still be improved further."
And Zaandam is even a relative short list.
It's a a 92 row table where each row is a template transclusion with a bunch of different parameters. When I click edit, it causes 2,268 errors to be thrown into my console, as compared to the 38 that are thrown in the example given in the description. Obviously the visual editor should handle this a lot better than it does, but given its structure, that template is not exactly blameless.
For now, I recommend sticking to wikitext when editing that table.
Ok, that is what I want to stress.
And Zaandam is even a relative short list.
It's a a 92 row table where each row is a template transclusion with a bunch of different parameters. When I click edit, it causes 2,268 errors to be thrown into my console, as compared to the 38 that are thrown in the example given in the description. Obviously the visual editor should handle this a lot better than it does, but given its structure, that template is not exactly blameless.
What I mean with a relatively short list is that there are also lists with a couple of 100 rows. So to really solve this, just polishing is not enough, it likely needs a different approach.
For now, I recommend sticking to wikitext when editing that table.
Most people will do that, but this happens to be the kind of list that (also due to wiki loves monuments) relatively new users will see, and run into an unresponsive browser. Maybe it is short term better if VE recognize a complex structure like this and gives a popup this is to complex to edit with VE, with an override to still try it.
Change 450946 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Template dialog: Lazy resize multiline text inputs on first focus
Change 450946 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Template dialog: Lazy resize multiline text inputs on first focus