Last modified: 2014-10-21 02:04:47 UTC
A machine that I frequently use to edit Wikipedia is 900MHz (not 1GHz as I originally thought). Slow by today's standards but it should be fine for using a search engine. When suggestions are enabled (as they always are after bug 52812) the delay between typing a letter and having it show up in the text box is no longer imperceptible. This has to do with the "computation" not the "display", i.e. it happens when I hide them with .suggestions {display:none !important;} Suggestions on Google and YouTube cause the same delay so it might not be possible to fix this and keep the feature mandatory. Something else that I've only seen on slower machines is trouble with holding down the backspace key. This used to erase a search perfectly. Since bug 52812, the search string will only disappear when you release the key. This does not happen on Google so it should be fixable.
In order to resolve this bug, we may need more info. In particular, operating system and version, Web browser and version, etc.
That would be Archlinux with kernel 3.12 and chromium 31.0.1650.63. On firefox 26.0 it's slower still but that's because the whole browser is made of JS.
This could be caused by the jquery.autoEllipsis module doing some really weird stuff to determine if the text is too long to fix in the box, and doing it wrong anyway (bug 30309). Maybe we could just use text-overflow: ellipsis.
Change 111180 had a related patch set uploaded by Bartosz Dziewoński: jquery.suggestions, mediawiki.searchSuggest: Don't use jquery.autoEllipsis https://gerrit.wikimedia.org/r/111180
Change 111180 merged by jenkins-bot: jquery.suggestions, mediawiki.searchSuggest: Don't use jquery.autoEllipsis https://gerrit.wikimedia.org/r/111180
Connor, can you check if the patch above helped? It's not yet live on Wikipedias, but I deployed it on my testing wiki, feel free to play with it however you need: http://users.v-lo.krakow.pl/~matmarex/testwiki/ (use user: testwiki, password: testwiki to access the site, it's a very simple antispam measure).
On the testwiki, I do not notice a time delay with fast typing anymore. There still is a time delay of 1-2 seconds when I hold backspace to erase what was typed.
Change 124827 had a related patch set uploaded by Bartosz Dziewoński: jquery.suggestions: Debounce calls to $.suggestions.special https://gerrit.wikimedia.org/r/124827
Yay. Let's try another thing for the backspacing, but this is a bit of a long shot – if this patch doesn't help, then I don't know what could. I deployed this to my test wiki as well.
Created attachment 15073 [details] What the change really means To illustrate what the change really means: 1: This is what you see when you type "exa" in the search box in the German Wikipedia. 2: Add an "a" and watch very carefully what happens. The line at the bottom immediately changes along with what you type. But you need to be very fast, this is only visible for 120ms. 3: 120ms later you will see this. In my opinion the current real-time update adds no benefit. It's kind of nice to have the line updated very fast but you can barely make use of this advantage. You are not that fast with your mouse. You have to wait for the search anyway because the number of search results may change (as it does in my example).
Change 124827 merged by jenkins-bot: jquery.suggestions: Debounce calls to $.suggestions.special https://gerrit.wikimedia.org/r/124827
I'm going to assume this fixed the second issue as well, because if it didn't then I have no idea what to do ;) Connor, I'd love if you could verify this fix as well. Thanks!
Since you mentioned the second issue (backspace), I have been trying to test it but the testwiki gives a server error. I hope you can get it back online.
Yah, I just noticed :/ Thankfully the code should be deployed on the labs beta cluster, e.g. http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page – you can test there as well.
The backspace issue is still there on the beta wiki, sorry.
I can't reproduce the backspace thingy; I suspect doesn't affect all browsers? I'm going to close this bug to clear things up, especially as we managed to resolve the more visible issue here. Please create another one if you want to follow this up (you can use the "Clone This Bug" link at the bottom and just adjust the description if you're lazy :) ).
