Last modified: 2014-05-09 17:22:34 UTC
1) click on a page 2) click in edit window 3) start editing 4) notice, out of corner of eye, the edit bar being posthumously added to the edit window after several seconds have elapsed. 5) watch, in alarm and then irritation as the cursor jumps to the top left corner, instead of where the text was clicked, and the text typed appears (up to 20 seconds late) in the top left corner. 6) watch, with increasing irritation, the cursor jumping AGAIN, after the text has been added to the top left corner, to the BOTTOM RIGHT of the text. this behaviour indicates a lack of thought and consideration for users with slower browser. javascript is lovely and wonderful ONLY if it's utilised properly.
apologies: noticed that there's a difference between strategy.wikipedia.org and en.wikipedia.org. this bugreport relates to whatever software has been deployed for strategy.wikipedia.org. on firefox 2, the time between hitting the initial edit and the final "jump" in stage 6 is a WHOPPING thirty to forty seconds. which is a completely unacceptable amount of time to have to wait, before beginning editing JUST because someone decided that the use of jquery and a nice pretty editor would be a good idea.
Please try to submit bug reports in a neutral and factual tone (what happened, what do you think should have happened, and why), rather than the angry and accusatory one this one is written in. The principle of "assume good faith" applies here as well. If you want a developer to fix your bugs, it's best not to yell at them. Fixed the cursor-moves-to-top issue in r57210; the fix should be deployed within the next few days. I couldn't reproduce the cursor going to the bottom right or find any code that moves it there (maybe it was already removed), but then I don't have a slow browser to test on. Speaking of slow browsers: if possible, I recommend you upgrade Firefox to version 3.5, which has a /much/ faster JavaScript engine.
The jump to the bottom is noticeable under firefox 3.5 (on a year-old debian laptop), but only by being quick (a click in the middle of the edit box as fast as my reflexes allow results in the cursor being at the bottom). I can't notice the jump to the top, and the editing toolbar appears instantaneously. (using http://usability.wikimedia.org/w/index.php?title=Releases/Acai&action=edit )
I apologize for any possible confusion: when I said I "couldn't reproduce" the bottom right issue, I meant I couldn't reproduce it /on trunk/. Could you see whether it happens at http://prototype.wikimedia.org/en-wp/index.php?title=San_Francisco&action=edit ? (This URL should also be updated with the fix I mentioned in comment #2.)
(In reply to comment #4) > I apologize for any possible confusion: when I said I "couldn't reproduce" the > bottom right issue, I meant I couldn't reproduce it /on trunk/. Could you see > whether it happens at > http://prototype.wikimedia.org/en-wp/index.php?title=San_Francisco&action=edit > ? (This URL should also be updated with the fix I mentioned in comment #2.) yes, the cursor-jump to the end of the article still occurs. that's a particularly good page to use because its size takes over a minute to stabilise. ahhh... ok - the _first_ time i started editing, i had a cursor-jump to the end of the article. the second time, i didn't. so, you likely have an AJAX or an event-driven race condition going on, which would explain why you were unable to reproduce the problem.
The problem is just a timing issue, at some point during load the editor is removed from the DOM and re-inserted inside some <div> tags (who knows why) this causes Firefox to lose the focus on the input box, and so there is a need for a manual refocus after that (which causes the cursor to jump to the end). The correct solution to this is to not dynamically wrap the text box in <div>s - I can see two possible fixes: either insert the <div>s in the markup before the editor is loaded, or re-write the CSS so that the wrapping divs are not required.
(In reply to comment #2) > Please try to submit bug reports in a neutral and factual tone (what happened, > what do you think should have happened, and why), rather than the angry and > accusatory one this one is written in. The principle of "assume good faith" > applies here as well. If you want a developer to fix your bugs, it's best not > to yell at them. my apologies: i always, always always make sure, when reporting free software bugs, that i convey what effect the bug had on me, as a user. i consider that if the software is broken, sufficient to cause frustration, and that it had a detrimental psychological effect on me, the user, that that adverse effect _is_ part of the bug. understanding the effects that the software has, on the users, i believe to be a very important part of ensuring that the software is useable and useful. i never _ever_ see, on free software projects, a category where such issues can be reported, so i tend to include them as part of the technical bugreport in the manner in which you've seen. so - please don't take it personally, ok !
(In reply to comment #2) > then I don't have a slow browser to test on. Speaking of slow browsers: if > possible, I recommend you upgrade Firefox to version 3.5, which has a /much/ > faster JavaScript engine. i run firefox 2 and also i run IE6 running under wine (ies4linux) precisely _because_ they are slower, and result in being able to detect these kinds of race conditions. as the lead developer of http://pyjs.org i have access to about eight to ten different kinds of web browsers. there was a race condition bug i managed to reproduce in XFree86 in 2000 precisely because i had a slower computer running far more tasks than it was capable of handling. no other developers could repro the bug until i advised them to deliberately put the load on the (much more powerful) test machine through the roof. once that had been done it took under 2 seconds to repro the bug. so i strongly urge you to consider keeping the older browsers around, and use them for your day-to-day development. you'll end up writing software that, when it runs on the faster browsers, runs at _blinding_ speed. and, when people use embedded systems and/or older hardware in emerging countries, it'll still be damn quick.
This may have been fixed in r57409, could you see if this issue still occurs on http://prototype.wikimedia.org/ ?
Focus is now just lost, which is better, but still annoying.
(In reply to comment #10) > Focus is now just lost, which is better, but still annoying. > We could fix that by explicitly focusing the textarea, which would automatically restore the cursor position as well. I'm not sure whether we're already focusing the textarea like that (we aren't AFAICT) or whether it's acceptable to do so, I'll ask Trevor.
Seems like we have 2 problems... * In Internet Explorer Focusing the textarea causes the browser to scroll if needed to ensure that the entire textarea is visible - which usually makes the page scroll down. We fix this by remembering the scroll position, doing the selection stuff, then restoring it - which unfortunately is jumping the page all around. * In Internet Explorer Text selection happens on the entire document, and also is handled through a poorly documented Range object. This causes otherwise trivial operations to become complex, which results in higher possibility of bugs. * Internet Explorer sucks I'm going to look into these issues as a whole and see if there could possibly be a more elegant solution...
Was not able to reproduce the defect in all browsers
This might be a duplicate of Bug: 41911
Bug 41911 was recently fixed. There might be more issues covered in this report, but the bug very old and a lot has changed in this area. I think if anyone is still seeing a problem, they probably should file a new ticket, with current information. For now, i'm closing this as worksforme
