Entering data in this field that extends beyond the view of this browser doesn't scroll the window up, and when I use the scroll bar on the right I have to clinck back into the field to start typing again. Maybe it does the same thing in Netscape, but it seems odd.

Not sure I understand what your saying. When typing in a text field (like this comments box) if I type more than would fit a vertical scrollbar pops up and it scrolls as I type more lines. Is this not working for you? Or are you talking about the main browser window not scrolling when your text field extends below the current visible part of the page. Please include clear steps to reproduce the behavior you are experiencing. Without clear steps it is all a guessing game. And also include the build ID(date) you tested. Thanks

comments from reporter: It's the main browser window that doesn't scroll, and the odd behavior is that using the mouse to scroll the browser up or down disables the cursor placement in the text field. To start typing again I have to click back in the box first. I'll have to find the build number, though I just downloaded the beta this morning, it's M15, but I don't have the program open right now. I think this already exists as another bug. I'll look for it and report back

It's the main browser window that doesn't scroll, not the text field I'm entering into. The odd behavior is that using the mouse to scroll the browser up or down disables the cursor placement in the text field. To start typing again I have to click back in the box first. Another odd behavior is happening right now on the bug update form while I'm typing into this text box. The main browser window keeps scrolling to the bottom of the page, hiding the text field I'm typing into, whenever I hit the space bar. Also, when I hit commit, the browser goes blank and never loads a page, though the update to the bug report does register. I'll have to find the build number (it's 2000032208). I just downloaded the beta this morning, it's M15.

The problem with the space bar is not happening now. Perhaps it's related to going back and adding more to the comment. I also got the reply to "commit" on the next threee submissions. there;s a new problem this time...I can't click somewhere in the earlier paragraph. The cursor stays at the bottom.

gewald@indiana.edu, let's keep this bug focused on the original issue. multiple isuses in one report can make it extremely difficult to get the bug assigned, fixed and verified quickly. Updating summary to reflect original issue.

OK, scrolling the browser window with the mouse and the scrollbar does not steal focus from the text inut field. I can start typing in thecomment box, grab the mouse and scroll the browser window up or down and continue typing in the comment box without needing to click back in the box. So I think that the main issue here is WORKSFORME with 032409 build under NT. gewald@indiana.edu with a current build if you start to type a comment and then click on the scrollbar does it steal focus from the comment box?

Right. Several issues here: Scrollbar stealing focus. This WORKSFORME as far back as 20000318 (before reporters build). However, if you accidentally click anywhere on the page as you're going for the scrollbar, the text box does lose focus - this is standard behaviour. I suspect this is what happened to gewald@indiana.edu. Spacebar moving screen - again, if you are not focussed in the text box, space bar is mapped to Page Down, so this seems to be what happened there. However, I think what gewald@indiana.edu was really trying to say was that if you have a multiline text entry field which is half visible at the bottom of the window, and you type into it, and the typing extends into that part of the box not visible, the window does not scroll. Reporter evidently thinks it should, and I agree with him. However, this is the behaviour in NS 4.x also, so this is an RFE. As this has got a bit confusing, I'm leaving it up to Asa to rewrite this bug however he sees fit. Gerv

Using build 2000032608 I'm still having the loss of focus when scrolling. In this build the text box does scroll when the number of lines warrants it, but if that's below the view of the browser window I can keep typing but not see what I'm doing until I physically scroll down in the browser. Then the focus problem returns. I can't start typing again without clicking back in the text box. The cursor is sitting there blinking, but nothing happens. This happens when all I do is click on the side scroll bar (and when I click elsewhere on the page as noted).

OK, there are two bugs here. The first is that clicking on the main browser scrollbar causes text widgets to lose focus. Sounds like this is a Mac problem and not a windows problem. I'm going change this bug to refelct that issue, add pp keyword to reflect that it is Mac only and assign it to event handling. The second issue, the browser window does not scroll as user types in a multiline text box which is part way off screen, I'm going to spin off into a new bug ( bug 33429 ).

Confirming. Gerv

Adding focus/activation prefix for tracking.

Mass update: changing qacontact to ckritzer@netscape.com

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Updating QA Contact.

Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.

QA contact updated

Is this bug fixed?

.

Works from over a year. Please close.

Resolving WFM as per previous comment.