Last modified: 2014-11-17 10:53:02 UTC
Due to the amount of widgets involved, toggling edit mode has quite a big performance footprint. While bug #73221 will resolve quite some loops through the infrastructure, still, it would not be a good idea to switch to section edit mode for statemtents without having a mechanism that ensures toggling edit mode only for necessary components. A practical solution might be to apply some smartness to $.wikibase.*listview widgets regarding the management of their sub-widgets' edit mode: When starting a *listview widget's edit mode, all sub-widgets touching the viewport are switched to edit mode while those out of the viewport remain in non-edit mode until they become visible in the viewport. In combination with the sticky toolbars, the mechanism should resolve the performance pitfall of initializing components that are not (and probably will not even become) visible. This pitfall does currently exist for the site links section. Unless there are no other options for solving the performance issue when toggling edit mode, the mechanism should be implemented an tested on the site links section before implementing section edit mode on statements. Side note: In the new UI, not all statements and site links will/should be visible when loading a page ("more" links). These invisible components would not need to be initialized before toggling their visibility anyway. However, that does not solve the general issue. In fact, both mechanisms should combine easily.
https://gerrit.wikimedia.org/r/#/c/173005/
Change 173005 had a related patch set uploaded by Tobias Gritschacher: Deferred sitelinkviews switching to edit mode https://gerrit.wikimedia.org/r/173005
Change 173005 merged by jenkins-bot: Defer sitelinkview's switching to edit mode https://gerrit.wikimedia.org/r/173005
