lkcl wrote:

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.

conrad.irwin wrote:

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.)

lkcl wrote:

(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.

conrad.irwin wrote:

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.

lkcl wrote:

(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 !

lkcl wrote:

(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/ ?

conrad.irwin wrote:

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...

wikibugs wrote:

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