[FOCUS/ACT]text input fields lose focus when scrolling browser window




Event Handling
19 years ago
9 years ago


(Reporter: Garrett Ewald, Assigned: saari (gone))




Firefox Tracking Flags

(Not tracked)




19 years ago
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.

Comment 1

19 years ago
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

Comment 2

19 years ago
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

Comment 3

19 years ago
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.


Comment 4

19 years ago
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.

Comment 5

19 years ago
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.
Summary: Using scroll bars while entering data in a form not working → text input fields lose focus when scrolling browser window

Comment 6

19 years ago
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.


Comment 8

19 years ago
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


Comment 9

19 years ago
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 ).
Assignee: cbegle → joki
Component: Browser-General → Event Handling
Keywords: pp
QA Contact: asadotzler → janc

Ever confirmed: true

Comment 11

18 years ago
Adding focus/activation prefix for tracking.
Summary: text input fields lose focus when scrolling browser window → [FOCUS/ACT]text input fields lose focus when scrolling browser window

Comment 12

18 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
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.
Target Milestone: --- → Future

Comment 14

18 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok

Comment 16

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 17

17 years ago
Is this bug fixed?
OS: All


16 years ago
QA Contact: madhur → rakeshmishra


16 years ago
Blocks: 140346


16 years ago
QA Contact: rakeshmishra → trix

Comment 18

15 years ago
Assignee: joki → saari
QA Contact: trix → ian
Works from over a year. Please close.

Comment 20

9 years ago
Resolving WFM as per previous comment.
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.