Last modified: 2014-11-13 08:27:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67988, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65988 - Don't load ULS IME on autofocused search bar
Don't load ULS IME on autofocused search bar
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
UniversalLanguageSelector (Other open bugs)
master
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance
Depends on:
Blocks: 55683 uls-diet
  Show dependency treegraph
 
Reported: 2014-06-01 08:31 UTC by Nemo
Modified: 2014-11-13 08:27 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
mw.loader.inspect(); on it.wiki main page, unregistered user, unfocused (3.75 KB, text/plain)
2014-06-01 08:31 UTC, Nemo
Details

Description Nemo 2014-06-01 08:31:58 UTC
Created attachment 15542 [details]
mw.loader.inspect(); on it.wiki main page, unregistered user, unfocused

Tested with Chromium 34.0.1847.132 Russian Fedora aura (265804).

1) Visit http://it.wikipedia.org/wiki/Pagina_principale, incognito mode, unregistered user, after having opened the developer console (tab is focused).
I. Observed: the search bar is autofocused.
2) Switch to developer console without keystrokes, e.g. clicking on the JavaScript console.
II. Observed: nothing.
3) Type mw.loader.inspect(); and enter.
III. Observed:

(index)	name	size
0	"jquery.uls"	"96.4 kB"
1	"jquery.ime"	"52.8 kB"
2	"ext.uls.inputsettings"	"33.5 kB"
3	"jquery.uls.data"	"33.3 kB"
4	"ext.uls.displaysettings"	"18.6 kB"
5	"jquery.i18n"	"17.3 kB"
6	"mediawiki.jqueryMsg"	"15.1 kB"
7	"jquery.suggestions"	"11.6 kB"
8	"ext.uls.interface"	"8.1 kB"

IV. Expected: ULS resources should be lazy loaded. Until I type alphanumeric characters in the (autofocused) search bar, it can't be assumed I'm going to use it.

Compare:

1-bis) Focus the developer console and click the refresh button.
2-bis) Nothing
3)

V. Observed: Search bar is not focused. ULS is not loaded, see attachment.

Compare:

1)
2-ter) Press tab button
II.
3)
III.

Compare:

1)
2-quater) Press ctrl-shift-J or any other ctrl shortcut.
II-bis. Observed: the IME icon appears.
3)
III.
Comment 1 Niklas Laxström 2014-06-01 20:08:49 UTC
Leaving aside whether adding autofocus on a main page is a good thing or not for a moment, in my testing there doesn't seem to be a way to differentiate between manual focus and autofocus. Searching the internet didn't help either.
Comment 2 Nemo 2014-06-01 20:20:54 UTC
Thanks for looking into it so swiftly!

It's indeed tricky and I'm not as competent as to suggest an implementation: as a user however, personally I wouldn't be bothered by the IME being loaded only after my first keystroke.
Pau, do we know from testing what the user expectations are? A data-based decision could perhaps be made by checking whether ime-disable events are proportionally more frequent than ime-enable events on "normal" view action (to non-special pages?) compared to action=edit and whatever? No idea if that helps.
Comment 3 Santhosh Thottingal 2014-06-02 03:00:34 UTC
(In reply to Nemo from comment #0)
> IV. Expected: ULS resources should be lazy loaded. Until I type alphanumeric
> characters in the (autofocused) search bar, it can't be assumed I'm going to
> use it.

A problem with lazyloading IME after user types is, the input key transliteration starts/happens only after user types several characters -when the IME is lazyloaded. That make first few characters without IME and then with IME.
Comment 4 Krinkle 2014-06-03 21:55:59 UTC
(Nemo asked me for input. Thanks.)

One solution that might be possible is to indeed lazyload it when the input field is first used (based on keyup or value change, not focus).

Then, using a callback, once jquery.ime is loaded, read the value entered so far and pass that to jquery.ime immediately (e.g. fast-forward).

To optimise for user experience, you could bind an on('focus') handler still (for browsers not having autofocus, or for when the user focused something else and is going back to the search box, at that point you can anticipate user input and fetch it right away). But you'll have to be careful to bind after autofocus has fired.

Looks like browsers are inconsistent in when they fire autofocus, so binding after it is even harder. Maybe try something hacky like listening for 'focus' only once (using jQuery#one), then see if element.autofocus is set. If so, remove the attribute and bind the event again.
Comment 5 Nemo 2014-06-11 09:51:05 UTC
Thanks Krinkle, that looks actionable.

Amir, can you please give an estimate of when this is going to be worked on? If it's not going to be within this month I'll have to work for local workarounds.
Comment 6 Nemo 2014-06-14 07:53:00 UTC
It was pointed out that the same behaviour is not immediately reproducible on other wikis like fr.wiki. To reproduce, one indeed needs to add something like it.wiki's JS

// Autofocus nel campo "ricerca" della homepage
$(function() {
  if (mw.config.get('wgIsMainPage') && mw.config.get('wgAction') === 'view')
    $('#searchInput').focus();
});

(of which as a workaround I'm asking removal https://it.wikipedia.org/w/index.php?title=Discussioni_MediaWiki%3ACommon.js&diff=66456352&oldid=66261344 ).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links