Page MenuHomePhabricator

Loading ext.wikieditor.toolbar module should not load it if user has preference "Enable enhanced editing toolbar" off
Closed, InvalidPublic

Description

  1. Disable the option "Enable enhanced editing toolbar" and/or "Show edit toolbar (requires JavaScript)" on

https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-editing

  1. Open some page for editing. E.g.:

https://www.mediawiki.org/wiki/EmptyPage?action=edit

  1. Execute the following code on your browser's error console: ----

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

  1. The old toolbar will be replaced by the enhanced toolbar, ignoring the user's choice.

Version: unspecified
Severity: enhancement
URL: https://www.mediawiki.org/w/index.php?diff=prev&oldid=502609

Details

Reference
bz34594

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:18 AM
bzimport set Reference to bz34594.
bzimport added a subscriber: Unknown Object (MLST).

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)

  1. 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 T36730: Add tests to verify that mw.user.options.get(...) from module "user.options" returns useful information about the user's choices regarding the toolbar.