Seen in trunk 20070824, not seen in trunk 20070810. That's the window. I see this bug when typing in the Description text box in bugzilla forms, and also (in SM) when typing text in the body of the plain text mail composer. To reproduce, enter enough lines of text in the text box that a vertical scroll bar appears. Then scroll the thumb to the top, so that there is no text above the top of the text box, but there is text below the bottom of the displayed portion of the text box. Then position the cursor at the end of the next to the last row of displayed text in the text box, and press enter. This will push the formerly last displayed row of text below the bottom of the text box, and create a new blank last row. Then type a new row of text, then press enter again. The cursor will have moved below the visible portion of the text box. Continue to type a new row of text. You will not be able to see the characters as you type them. The text you type thereafter is not lost, but does not appear in the text box as you type. Scrolling down will reveal the text you typed. It may be necessary to ensure that the last character typed on each line is a space. I'm not sure about that. I can reproduce this at will. (The sad part is, I can reproduce this unwillingly, too. :)

I am seeing this as well on my mac. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007082504 Minefield/3.0a8pre ID:2007082504

Also, pressing enter when the cursor is on the first character of a line now frequently causes the text box to scroll to the top and place the first at the beginning of the first line of the text box. This is very disturbing. I'm surprised a product of this age is having so much trouble with basic text editing.

works: 2007082104 - fails: 2007082204 (Mac builds) http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-08-21+04%3A00%3A00&maxdate=2007-08-22+04%3A00%3A00&cvsroot=%2Fcvsroot quite a few candidates in there

I've narrowed this down further to http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1187742720&maxdate=1187751839 which seems to point the finger squarely at bug 375436.

Nelson, the text editing is built on top of a layout engine designed for something entirely different. So it ends up having various issues. And yeah, looks like some caller of ScrollSelectionIntoView needs fixing. Looking into it.

For reference the quickest way I found to reproduce this was to put the cursor in a bugzilla comment box, scroll the page so the box wasn't visible then type. It should scroll back to the cursor.

This is also easy to reproduce with horizontal scrolling in an <input type="text">.

Comment on attachment 278317 [details] [diff] [review] Fix Requesting approval. This is a patch to make sync editor updates always flush layout instead of only sometimes flushing layout.

Comment on attachment 278317 [details] [diff] [review] Fix a1.9=dbaron

Fix checked in. To test this, I think I want a combination of the event stuff in mochitest with the snapshotting of reftest. I looked into doing this all inside mochitest, but the small iframe the code runs in makes things suck (e.g. scrolling into view, which is what we're testing here). Could we hook up something where reftest runs against a profile that allows UniversalXPconnect and reuse the mochitest EventUtils.js?

Boris, This bug claims to be fixed, over 30 days ago, but the problem is still completely 100% reproducible in a nightly trunk SeaMonkey build for Windows from 2007-10-07.

Nelson, it sounds like perhaps there are two separate bugs here? The original steps to reproduce for this bug reproduced the problem for me on both Mac and Linux, and the fix I checked in fixed both of those, in both Seamonkey and Firefox. I just double-checked, and the Linux 2007-10-07 Linux build doesn't show the problem. If Windows still does, then I'm at a complete loss as to why, to be honest. We should probably file a separate bug on that. I'm not sure I'll be able to help with it, since I can't reproduce on Windows and can't see how the problem can happen at this point...

Boris, this might indeed be a separate bug. The original bug I reported in comment 0 occurred in both the browser text edit boxes (like the one in which I'm typing right now), and in the email text editor boxes. The present problem does not seem to occur in browser text edit boxes, but only in the email composer text editor box. The original problem was a little tricky to reproduce, not quite as easy as "type anything on the bottom line in the text box and keep typing until you type past the right edge of the box, and then the text you type will be entered below the bottom of the text box (the box won't scroll up)." But that description fits the problem I'm seeing now in the mail text composer. I'll file a mailnews bug.

Aha! I've been testing in browser textareas all along, since that was easier than messing with mailnews compose. Please assign the bug you file to me; I'll look into it tomorrow.

Nelson, please mention in the new bug whether you're seeing the bottom of the scrollbar cut off as well when the bug happens?

The new bug is bug 399410.