The LexemeHeader currently initializes itself from the data of the wikibase.entityPage.entityLoaded hook:
$.Deferred( function ( deferred ) { mw.hook( 'wikibase.entityPage.entityLoaded' ).add( function ( wbEntity ) { deferred.resolve( hydrateLexeme( wbEntity ) ); } ); } ) .then( init ) .fail( function ( reason ) { // FIXME: Change to lexeme-extension-specific logger once defined mw.log.error( 'LexemeHeader could not be initialized from wikibase.entityPage.entityLoaded', reason ); } ) ;
This makes it depend on global state and also delays its initialization so that, as @Nikki reports, it sometimes completes only after the wikibase.entityPage.entityView.rendered hook has fired, which means that gadgets and user scripts can’t reliably manipulate the lexeme header.
As far as I can tell, this is completely unnecessary. At the point where its initialization is hooked up, in ControllerViewFactory…
SELF.prototype.getEntityView = function ( startEditingCallback, lexeme, $entityview ) { return this._getView( 'lexemeview', $entityview, { buildEntityTermsView: this.getEntityTermsView.bind( this, startEditingCallback ), buildSitelinkGroupListView: this.getSitelinkGroupListView.bind( this, startEditingCallback ), buildStatementGroupListView: this.getStatementGroupListView.bind( this, startEditingCallback ), buildFormListView: this.getFormListView.bind( this, lexeme, startEditingCallback ), buildSenseListView: this.getSenseListView.bind( this, lexeme, startEditingCallback ), buildLexemeHeader: wb.lexeme.widgets.buildLexemeHeader, value: lexeme } ); };
…we already have the lexeme available for the form and sense list views, so I don’t see why we couldn’t use the same data to build the lexeme header, without waiting for the entityLoaded hook to fire.