Wikimedia Bugzilla is closed!

Is this happening anywhere in production?

Seems like the expected result. Don't load WikiEditor if you don't want it.

That preference decides whether not to load it automatically for the user. If you load it by hand, it will load. Suggesting invalid or wontfix otherwise.

(In reply to comment #1)
> Is this happening anywhere in production?
I reported it because I was testing this:
https://www.mediawiki.org/w/index.php?diff=prev&oldid=502607
and the toolbar was loaded even if the user disabled that "usebetatoolbar" option.

(In reply to comment #2)
> (In reply to comment #1)
> > Is this happening anywhere in production?
> I reported it because I was testing this:
> https://www.mediawiki.org/w/index.php?diff=prev&oldid=502607
> and the toolbar was loaded even if the user disabled that "usebetatoolbar"
> option.

yeah, I merged those two using() calls so that there aren't 2 http requests made. I was aware of the fact that that means it will load the wikieditor.toolbar module even if the user doesn't have the toolbar enabled (rationale: it's better to optimize for those that enable the gadget and have the wikieditor enabled, than to optimize for the users that enable the gadget but dont have the wikieditor and thus wont see the effects of the gadget, since those users shouldn't using that gadget then).

However I did not expect that loading the wikieditor.toolbar module would also initialize the module, that is indeed a bug.

Rephrasing bug summary: "Loading ext.wikieditor.toolbar should not initialize it".

The call to $( '#wpTextbox1' ).wikiEditor(); should only be made when and if it is explicitly asked for.

Further investigating I see that ext.wikiEditor.toolbar.js does indeed not call $( '#wpTextbox1' ).wikiEditor();, that code is in ext.wikiEditor.js, so how come that is executed?

I don't know if this is related but, if I copy the code
----
if (mw.config.get('wgAction') === 'edit') {
    mw.loader.using('user.options', function () {
        alert('usebetatoolbar=' + mw.user.options.get('usebetatoolbar'));
    });
}
----
to my common.js[1] on ptwiki and then open a page in edit mode[2], I always get "usebetatoolbar=1", no matter which of the 4 possibly combination of the following options I choose:
1) Show edit toolbar (requires JavaScript)
2) Enable enhanced editing toolbar
Besides, on each case the toolbar is/is not displayed as follows:
<none>: no toolbar displayed
(1): Old toolbar is displayed
(2): Enhanced toolbar is displayed (bug 30795, but contradicting bug 19786)
(1)+(2): Enhanced toolbar is displayed

On the other hand, if I add "&debug=1" to the url[2], I always get "usebetatoolbar=null" in all cases above (and the kind of toolbar displayed in each case is as in the previous list).

I've tested this using Google Chrome 17.0.963.56.

[1] https://pt.wikipedia.org/?oldid=29029589
[2] https://pt.wikipedia.org/w/index.php?title=TestPage&action=edit

PS: according to [[pt:Special:Version]], ptwiki is runing 1.18wmf1 (r109351).

(In reply to comment #0)
> 4) The old toolbar will be replaced by the enhanced toolbar, ignoring the user's choice.

This happens on ptwiki as well, which is running 1.18wmf1.

Like I said, this is not a bug. You're explicitly loading the WikiEditor, obviously it will show up then.

I've opened a new bug for what I described in comment 4; bug 34602

And what about comment 5?
That problem make it mw.user.options.get('usebetatoolbar') useless since it
doesn't tell us if the new toolbar is enabled or not.

(In reply to comment #10)
> And what about comment 5?
> That problem make it mw.user.options.get('usebetatoolbar') useless since it
> doesn't tell us if the new toolbar is enabled or not.

That's not related to WikiEditor but user.options in general. But I'll answer here now that we're here. It returns null because user.options module isn't loaded yet. This should be fixes as of earlier today when user.options was moved to the top of the page before the load queue, and if not simply add a dependency on user.options, and then this will be available no matter what.

(In reply to comment #11)
> (...) if not simply add a dependency on user.options, and then this will be available no matter what.

But that is the problem: the code is already wrapped by a "mw.loader.using('user.options', ...)" call and still shows those unexpected behaviour.

(In reply to comment #12)
> (In reply to comment #11)
> > (...) if not simply add a dependency on user.options, and then this will be available no matter what.
> 
> But that is the problem: the code is already wrapped by a
> "mw.loader.using('user.options', ...)" call and still shows those unexpected
> behaviour.

I moved this to Bug 34730.