Page MenuHomePhabricator

WikiEditor toolbar is loaded twice when editing
Closed, ResolvedPublic

Description

Since a few days ago, I'm seeing two (enhanced) edit toolbars on top of the edit window. By these edits, it seems @GOIII and other users are having the same problem on English Wikisource.

I vaguely remember some changes to module dependencies some days ago, which might be the cause of this regression...
I don't have the time to investigate the exact cause right now, but it should be fixed (either in the affected scripts or in the extension/MediaWiki itself).

Most likely introduced by: T88027

Event Timeline

He7d3r created this task.Mar 20 2015, 5:38 PM
He7d3r raised the priority of this task from to Needs Triage.
He7d3r updated the task description. (Show Details)
He7d3r added subscribers: He7d3r, GOIII.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 20 2015, 5:38 PM
He7d3r set Security to None.
TheDJ added a subscriber: TheDJ.Mar 20 2015, 11:01 PM

I haven't seen this so far. Which browser is being used, and can it be user script/gadget dependent ?

GOIII added a comment.EditedMar 20 2015, 11:31 PM

It has to with the module (?) schema.Edit
Adding it to the customizations for WikiEditor (below) solves the problem though I can't say logging & whatever else is proper. To reach a wider affected group via criminal hack - adding it to CharInsert or EditTools -type of gadgets also seems to work since those are also rendered on 'edit' & 'submit'.

/* Check that the required modules are available. Then, customize */
if ( $.inArray( mw.config.get( 'wgAction' ), [ 'edit', 'submit' ] ) !== -1 ) {
	mw.loader.using( 'user.options', function () {
		if ( mw.user.options.get( 'usebetatoolbar' ) == 1 ) {
			$.when(
				mw.loader.using( ['ext.wikiEditor.toolbar', 'schema.Edit'] ),
				$.ready
			).then( customizeToolbar );
		}
	} );
}

My gut & guess says - schema.Edit should have been associated as a dependency for ext.wikiEditor.init

TheDJ moved this task from Backlog to Next-up on the WikiEditor board.Mar 21 2015, 1:12 PM
TheDJ triaged this task as High priority.Mar 21 2015, 1:18 PM

Has anyone been able to reproduce this while logged out/on a new account?

TheDJ added a comment.Mar 21 2015, 9:32 PM

First, I think the dependency is on the wrong module.

The schema is added by the module ext.wikiEditor.init
ext.wikiEditor has ext.wikiEditor.init as it's dependency

But the core of WikiEditor is basically jQuery.wikiEditor, ext.wikiEditor is only a 'launcher' for it. This is important because some elements have a different 'entry' route into the wikiEditor, like for instance the toolbar additions, which only depend on ext.wikiEditor.toolbar, which does not have ext.WikiEditor as a grandfather.

Also I see onBeforePageDisplay is used to separately add ext.wikiEditor.init, but since it's a dependency, I don't think that should be required.

GOIII added a comment.EditedMar 21 2015, 9:47 PM

Has anyone been able to reproduce this while logged out/on a new account?

https://test2.wikipedia.org/w/index.php?title=Page:On_the_forfeiture_of_property_by_married_women.djvu/17&action=edit

... is one example where I can reproduce this without logging in. Otherwise, User:s who have selected gadgets or added scripts to their common.js files that adds/removes/manipulates the "default" WikiEditor toolbar in some way shape or form are more likely to see this behavior than those with "vanilla" configurations.

On a related note - I see some additional WikiEditor/schema commits for 1.25wmf21 & 1.25wmf22 that might have a role yet to play in all this still have not been merged; can some one make that happen sooner rather than later?

And as mentioned above in case it got lost - for those User:s who do tinker with the WikiEditor defaults, manually recognizing schema.Edit somehow prior to customizations resolves this issue for those cases. TheDJ explained this far better just above.

I tried not being logged in (private browser windows in Firefox 36 and Chrome 41 on Fedora 21) and I cannot reproduce the problem. :(

GOIII added a comment.EditedMar 21 2015, 10:32 PM

Win 8.1 ~ IE 11 here.

How about logged-in but only select Enhanced toolbar in User Prefs (No classic toolbar to overcome & No WikiEditor dialog mode iow)?

.... and somebody said it might be "forced to appear" by opening an Edit session and then immediately hitting the Edit tab once or twice more.

I was able to reproduce this as a Logged in user, with @GOIII's link, but only upon the 2nd page load. This is probably subject to a race condition, being influenced by caching.

Have not been able to reproduce as a logged out user so far.

This is specific to the proofread page extension I suspect.

It doesn't include ext.WikiEditor directly, but instead uses a wrapper module to launch it. Because of the onBeforePageDisplay adding ext.wikiEditor.init, the editor and the proofread page extensions get into a race to change the editor. Possibly sloppy usage of variables to keep selectors ?

This is specific to the proofread page extension I suspect.

Again - above my pay grade - but I noticed that the wgPageContentModel somewhere in this past week's wikiEditor.init related changes was/is (at one point) geared for wikitext in particular on the road to event logging. The Page: namespace in the ProofreadPage extension has a content model of proofread-page ; could that be a factor?

It doesn't include ext.WikiEditor directly, but instead uses a wrapper module to launch it. Because of the onBeforePageDisplay adding ext.wikiEditor.init, the editor and the proofread page extensions get into a race to change the editor. Possibly sloppy usage of variables to keep selectors ?

The "race to fail" phenomenon you describe is kind of a known, ongoing issue with the Page namespace and the PrP extension (under WikiEditor in particular). Similar "drop outs" have been to happen when some combination of enabled gadgets and/or user scripts are in the mix along with WE & PrP.

matmarex removed a subscriber: matmarex.
He7d3r added a comment.EditedMar 22 2015, 11:32 PM

This is specific to the proofread page extension I suspect.

It is not. I also see the problem on Wikipedias, e.g. at
https://en.wikipedia.org/w/index.php?title=User_talk:He7d3r&action=edit&section=new
using Firefox 36.0.1 on Ubuntu Studio and only this global script:
https://meta.wikimedia.org/w/index.php?oldid=11655433
(I disabled all gadgets on English Wikipedia, and the problem still happened)

This is my First time looking at source code of Mediawiki but i never got the 2 toolbars error and so i think its got to be a race condition in:
https://gerrit.wikimedia.org/r/#/c/191221/17/WikiEditor.hooks.php
lines 200 -> 268

in function editPageShowEditFormFields:
line 206 $outputPage->addHTML(;

and in function editPageShowEditFormInitial line 257
$outputPage->addModules( $feature['modules'] );

doesn't that repeat the DIV toolbar element generation?

Has anyone been able to reproduce this since today's morning swat (15:00 - 16:00 ish)?

Has anyone been able to reproduce this since today's morning swat (15:00 - 16:00 ish)?

Something has changed for the better alright... most notably no more messages of any kind in my F12 Developer Tools (Win 8.1 / IE 11) console log immediately after I removed my previous hack to include/rely on the schema.Edit "module" in my WikiEditor toolbar customizations on both en.wikisource and en.Wikipedia.

On Wikisource - I could not reproduce the "double toolbar" in any namespace for more than 10 minutes now of loading random pages & [re]opening them to edit mode w/ multiple submits. The issue seems rectified on this Project fwiw....

On Wikipedia however - double toolbar right away, even after alternating w/Wikisource for said time period, right up until I stopped typing this line (and once more before I submitted this). Same story; no toolbar customizations in either instance of the double WikiEditor toolbar generated.

Of Note:

  • In the odd instances when I do get a single, customized toolbar on en.wikipedia now, hitting the edit tab or submitting once or twice afterwards always produces two un-customized toolbars for the rest of the session no matter how many differing ways of trying or re-trying takes place.
  • Only a browser URL address bar refresh generates a single customized WE toolbar at any point after initializing an edit session resulting in double toolbars.

I still haven't been able to reproduce this bug myself. @GOIII, what happens when you try it in incognito/private browsing mode? Am wondering if it might be cache-related.

GOIII added a comment.Mar 24 2015, 6:42 AM

You meant Internet Explorer 11's InPrivate mode? = same thing... 2x toolbars.

@Krenair - Have you tried temporarily copying my common.js to your testbed to see if that reproduces the problem for you? (though I'm not 100% sure its not browser specific or something)

... and @He7d3r : anything new/changed for you?

I still see two toolbars consistently at
https://meta.wikimedia.org/w/index.php?title=User_talk:He7d3r&action=edit&section=new
using this script
https://meta.wikimedia.org/w/index.php?oldid=11670228
on Firefox 36.0.4 and Chrome 41.0.2272.101 64-bit (and the button does not appear in any of the two toolbars - but copying the same script to the console, and executing it from there, adds the button to the second toolbar).

Thanks @He7d3r, I was able to reproduce it on production wikis (and beta) with that. Not localhost yet.

Change 199387 had a related patch set uploaded (by Alex Monk):
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/199387

Similar issue on the Italian Wikiquote with a gadget depending on ext.wikiEditor.toolbar.

FRacco added a subscriber: FRacco.Mar 27 2015, 2:48 AM
This comment was removed by FRacco.

I had the same problem with my personal toolbar on Italian Wikiquote. I tried to copy the code to my global js and there was the same problem on all wikis.
I changed the original code:

$.when(
    mw.loader.using( 'ext.wikiEditor.toolbar' ),
    $.ready
).then( customizeToolbar );

with the new code:

mw.loader.using( 'ext.wikiEditor.toolbar', function() {
    $( customizeToolbar );
} );

(see diff) and now the problem seems to be solved.

GOIII added a comment.Mar 29 2015, 8:44 PM

Still getting random double generation every so often.

Hope https://gerrit.wikimedia.org/r/199387 solves this.

Sigh... still seeing this & others report the same.

Any fix in sight? No? Well then a revert would be appropriate would it not?

I'd rather try getting https://gerrit.wikimedia.org/r/199387 reviewed and merged... :-/

Change 199387 merged by jenkins-bot:
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/199387

Change 204171 had a related patch set uploaded (by Catrope):
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/204171

Change 204172 had a related patch set uploaded (by Catrope):
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/204172

Change 204173 had a related patch set uploaded (by Alex Monk):
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/204173

Change 204171 merged by jenkins-bot:
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/204171

Change 204172 merged by jenkins-bot:
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/204172

Change 204173 merged by jenkins-bot:
Try to unbreak WikiEditor modules

https://gerrit.wikimedia.org/r/204173

Elitre added a subscriber: Elitre.Apr 16 2015, 8:00 PM

UPDATE: Seems to be resolved for me as well as for previous reports (en.wikisource) Thank You.

... and a special thanks for spreading the fix across past 1.25 revisions as well as the current 1.26 -- waiting one to two weeks for patches to actually roll-out only increases the angst among suffering users.

I'm glad that change resolved it. Thanks for confirming it, and for waiting for code review to happen.

TheDJ closed this task as Resolved.Jun 21 2015, 1:39 PM
TheDJ claimed this task.
GOIII moved this task from Next-up to Closed on the WikiEditor board.Apr 3 2016, 8:55 AM