Last modified: 2012-12-13 11:20:01 UTC
Da scheint das JavaScript das die Größe des Feldes automatisch ändert, zu langsam zu sein. (Langsamer PC mit aktuellem Firefox) Es dauert immer 1 bis 2s bis der eingegebene Text erscheint.
Description translation: The edit summary input field automatically resized in JS. On a low-entry computer with Firefox, this script is a little long to react, and so UI isn't directly updated: text could appear only after 1 or 2 seconds. * * * [ Adding 'javascript' keyword, in the case someone want to explore an alternative: to speed up the field size. ]
It could be interesting to know what kind of machine this is. The developers have quite fast machines and could be going slightly over the top with heavy-weight solutions.
It has a 1.7 GHz Intel Pentium (IV) desktop computer running Windows XP. I don't run programs that would slow down typing like windows-key-hooks (as far as I know :-). But you should really avoid accessing the DOM on each keystroke.
I told them! (mumble)... The proc should be more than fast enough, but I suspect the UI guys are to optimistic on the hardware!
How is the aliases on this machine? Are they very slow? Any numbers?
(In reply to comment #5) Pardon? If this answers your question, I usually have no problems with slow inputs, except in Upload Wizard when I upload >= 15 files at once but this is caused by an interval that is not cleared + a resize handler that is called on each key stroke. Why not simply waiting whether other people have the same experience? Perhaps I have to buy a new machine, this is overdue, anyway. Or you simply use a timeout (setTimeout) and clear (clearTimeout) it with the next key stroke. Only if the timeout was "faster" than the keystroke, you compute your DOM stuff and otherwise, the timeout is simply cleared.
In the item page there is an edit field for (a possibly empty) label field on top, then there are a description field and below that there are zero, one or several fields for aliases. Those are the most heavy ones in the user interface. Can you create one of those and check what is happening? Is it responsive? What if there are several of them, are they still responsive or does it take several (10-20) seconds to manipulate them? The idea with the timeout is quite good. It will make the load scale much better, especially if new timeouts can be held in a pending state until the last one is completely handled.
(In reply to comment #7) The lag there seems to be less than when entering something into the description field. Even when having 6 of them, it's "less irritating". What happens when entering a description: # <typing lorem ipsum dolor sit amet> # lag 2s # the first letter or letters that was/were typed by me is/are visible # the bar changes its color from white to blue # lag 1s # the second part is visible # lag 3s (depends on the length of what you are typing) <--- is is what I find "most irritating" # the third part is visible All in all typing "lorem ipsum dolor sit amet" takes me about 5 seconds while it takes 13 seconds before all letter are visible on screen in the "enter description" box below the "label field on top".
(In reply to comment #7) >What if there are several of them, are they still responsive or >does it take several (10-20) seconds to manipulate them? No. Typing is more fluent. Only when clicking edit or cancel it takes about 2-3s. Sometimes they need some time to resize but at least the letters are visible. There is also a lag but generally it takes only 1s longer to display what I filled-in completely. Of course it would be nice if there would be no visible lag at all so it's easier to immediately see and correct typos.
The size is not adapted anymore, so it should be fast now.
Verified in Wikidata demo time for sprint 16
