Page MenuHomePhabricator

Add tests to verify that mw.user.options.get(...) from module "user.options" returns useful information about the user's choices regarding the toolbar
Closed, DeclinedPublic

Description

https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki

Splitting this from bug 34594 comment 5:

The use of mw.user.options.get in the code below should indicate whether the user has or has not enabled the option in its preferences[2]:

console.log('$.isEmpty(mw.user.options.values)=', $.isEmpty(mw.user.options.values));
console.log(

'usebetatoolbar=' + mw.user.options.get('usebetatoolbar') + ';' +
'showtoolbar=' + mw.user.options.get('showtoolbar')

);
mw.loader.using('user.options', function () {

console.log('using "user.options" > $.isEmpty(mw.user.options.values)=', $.isEmpty(mw.user.options.values));
console.log(
    'using "user.options" > ' +
    'usebetatoolbar=' + mw.user.options.get('usebetatoolbar') + ';' +
    'showtoolbar=' + mw.user.options.get('showtoolbar')
);

});

Nonetheless, I've tested it on Portuguese Wikipedia[1], which is currently running MW 1.18wmf1 (r109351), using Google Chrome 17.0.963.56, and the result is inconsistent:
On each of the following cases

  1. Only "Show edit toolbar (requires JavaScript)" enabled Note: Old toolbar was loaded, as expected
  2. Only "Enable enhanced editing toolbar" enabled Note: Enhanced toolbar was loaded, DISRESPECTING the user's choice of disabling "Show edit toolbar (requires JavaScript)". This was described on bug 30795, and I believe it justify marking bug 19786 as WORKSFORME.
  3. Both options enabled Note: Enhanced toolbar was loaded, as expected
  4. Both options disabled Note: No toolbar was loaded, as expected

the result is always the same:

$.isEmpty(mw.user.options.values)= true
load.php:1usebetatoolbar=null;showtoolbar=null
load.php:1using "user.options" > $.isEmpty(mw.user.options.values)= false

load.php:1using "user.options" > usebetatoolbar=1;showtoolbar=1

So, after the module "user.options" loaded, mw.user.options.get(...) isn't returning any useful information about the user's choices regarding the toolbar.

If I test the same code, and the same combination of preferences on debug mode (adding ?debug=1 to the URL), the resulting log is always the same, but different from the above:

$.isEmpty(mw.user.options.values)= true
load.php:3usebetatoolbar=null;showtoolbar=null
load.php:8using "user.options" > $.isEmpty(mw.user.options.values)= true

load.php:9using "user.options" > usebetatoolbar=null;showtoolbar=null

I don't know if I should report in a separated bug the fact that
mw.loader.using('user.options', function () {/* code */})"
doesn't guarantee that mw.user.options.values will be filled with the user's preference.
But this is certainly also a bug, because currently the /* code */ can't use mw.user.options.get() at all.

[1] https://pt.wikipedia.org/?oldid=29092806
[2] https://pt.wikipedia.org/wiki/Special:Preferences?uselang=en#mw-prefsection-editing


Version: 1.18.x
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=19786

Details

Reference
bz34730

Event Timeline

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

Er... As Krinkle said on bug 34594 comment 11, this seems to be fixed by recent changes (r107534, I think - see bug 30914), because on ptwikibooks, which is running MW 1.19wmf1 (r112130), the result is as expected.

Mark, should we add some regression/unit tests for this? (tags: need-regression-test, need-unittest)

Results on ptwikibooks

  1. Only "Show edit toolbar (requires JavaScript)" enabled ----

$.isEmpty(mw.user.options.values)= false
usebetatoolbar=;showtoolbar=1
using "user.options" > $.isEmpty(mw.user.options.values)= false

using "user.options" > usebetatoolbar=;showtoolbar=1

  1. Only "Enable enhanced editing toolbar" enabled ----

$.isEmpty(mw.user.options.values)= false
usebetatoolbar=1;showtoolbar=
using "user.options" > $.isEmpty(mw.user.options.values)= false

using "user.options" > usebetatoolbar=1;showtoolbar=

  1. Both options enabled ----

$.isEmpty(mw.user.options.values)= false
usebetatoolbar=1;showtoolbar=1
using "user.options" > $.isEmpty(mw.user.options.values)= false

using "user.options" > usebetatoolbar=1;showtoolbar=1

  1. Both options disabled ----

$.isEmpty(mw.user.options.values)= false
usebetatoolbar=;showtoolbar=
using "user.options" > $.isEmpty(mw.user.options.values)= false

using "user.options" > usebetatoolbar=;showtoolbar=

(In reply to comment #1)

Er... As Krinkle said on bug 34594 comment 11, this seems to be fixed by recent
changes (r107534, I think - see bug 30914), because on ptwikibooks, which is
running MW 1.19wmf1 (r112130), the result is as expected.

Mark, should we add some regression/unit tests for this? (tags:
need-regression-test, need-unittest)

Yes, changing bug to reflect that since you say the original bug has been fixed.

I'm not sure we can or should add tests for this.

If a scrip is missing a dependency, then the code in that module is likely not always available. It's not related to user.options in particular, not related to the editor preferences themselves either.