Closed Bug 21176 Opened 26 years ago Closed 26 years ago

Click in text field causes it to scroll out of view

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 18649

People

(Reporter: akkzilla, Assigned: pollmann)

References

(
URL
)

Details

Go to the Bugzilla Enter Bug page (see URL). Notice the text fields for URL and Summary are much wider than they should be (the size specifies only 60 columns) and don't fit in the window (if they do, resize the window to where they don't). This is a separate bug which I'll file separately. Click in one of the empty text fields. Notice the whole window scrolls to show as much as possible of the text field, so you can no longer see the labels indicating which text field is which. 4.x doesn't do this. The scroll is coming from nsFormControlFrame::ScrollIntoView(), line 297.
Whiteboard: [PDT-]
Is this Linux specific? Please let us know results on all platforms. Thanks. Putting on the PDT- radar. I believe you can re-scoll and view...thought painful :-0
Having to scroll horizontally after every text field clicked in is so painful that it would definitely prevent me from using mozilla to file bugs. Dogfood isn't just "I can accomplish these tasks", it's "I can accomplish these tasks without being slowed down so much that I don't have time to do my real job." Try filing two or three bugs (waiting an hour or so between them so you don't memorize which text field position is which) and see if you still think it's a reasonable workaround. Don't know whether it's XP or not: on Windows I crash before I get that far, bug 21180.
Status: NEW → ASSIGNED
I added this ScrollIntoView behaviour. Whenever a form control receives focus, it scrolls into view. This was a feature request entered through bugzilla (forget the bug number), with the main purpose of making it possible to see form elements that were given focus via javascript and when tabbing between form elements. I'm doing testing with IE and Nav on Windows right now to see where we differ in behaviour. sense to do this via
BTW, my somewhat easier workaround would be to expand the window to be larger so that the textareas don't need to be scrolled. Yes, I know it's a pain. :S
OS: Linux → All
Hardware: PC → All
Target Milestone: M13
Marking M13 unless/until this get's bumped up to PDT+
I've been testing and comparing behaviours a bit. The one that seems most usable to me is IE 5 on Windows. In Un*x Nav, fields are never scrolled into view and tabbing between form elements is completely busted. We can't emulate this behaviour as it breaks the HTML 4.0 spec. (Tab ordering) Windows Nav is better, but there are some usability issues. If you tab through the fields, we scroll into view with some logic very close to what gecko is using now, and the labels to the left are chopped off. Luckily, on Windows Nav, there is a distinction between focus received through tabbing and focus received through clicking, and we don't scroll at all if focus is received through clicking. This is okay as it solves akkana's problem, but it can lead to typing in text fields that you can only see one pixel of, which is bad. IE's scroll-into-view behaviour is identical for focus received through tabbing or clicking on an element. When an anchor receives focus, it is scrolled into view as much as possible. When a select, text input, textarea, or button receives focus, it is scrolled vertically into view as much as possible, but horizontally into view only as much as is needed to see the cursor (or leftmost edge if there is no cursor). This prevents typing into a field that you cannot see (which can happen on Nav) and reduces scrolling versus our current approach. Note that as characters are typed into a text input in IE, the window may be scrolled so that the cursor is always in focus (this behaviour is not found in Nav). Akkana, does this seem reasonable to you? Do you have any other suggestions? If we are to emulate IE's logic completely, it will require knowledge of frame type in the focus manager (I think?). Tom Pixley was 'da man for the focus manager, so I'm CC'ing him.
Yes, this seems reasonable: scroll vertically to bring the whole field (or as much as possible) into view, but horizontally only as much as needed to bring the cursor into view. (I'm not sure why the vertical scroll is actually necessary if the line with the cursor was already visible, but I'm sure I'll get used to it.) I agree that scrolling a completely invisible text field so that you can't type into something invisible is a good thing, just please keep the horizontal scrolling to the minimum that's necessary.
*** Bug 21181 has been marked as a duplicate of this bug. ***
I don't think we should be scrolling unless it is needed to show the insertion point or selection, and when we do scroll it should be just enough to show it plus minimal context. We should not assume that the user wants to maximize the field, they may have just purposefully arranged things otherwise. Besides, big jumps are extremely disorienting. This means we would not scroll if a click causes an insertion point that is visible, but we would scroll automatically when the caret goes out of visibility while typing. IE does this nicely, as do most popular word processors. For other details on automatic scrolling, see Macintosh Human Interface Guidelines, pp166-167, and Windows Interface Guidelines for Software Design, pp114-115.
To be honest, I much prefer trudelle's model (scroll as little as possible) if given my druthers.
Me too. :) That means we won't scroll "vertically as much as possible and horizontally as much as needed" but both will be "as much as needed". The bit about continually scrolling to keep the insertion point in view sounds like it might require work on the editor side. That should probably be a separate bug.
yes, that would require some additional work. The way it works today, the editor code scrolls to keep the caret visible, but that only effects the scroll view of the editor content. It doesn't effect the scroll view of the document in which the editor is embedded.
Blocks: 24206
Target Milestone: M13 → M14
Due to regressions caused by my fix to bug 20315, I will probably not be able to get to this today. Marking M14 and I'll try to get it in early M14 if possible.
Eric: Can't you turn off the auto-scrolling entirely? Things were working fine before that was checked in, and not scrolling is the desired behavior in most cases anyway (because the insertion point is usually already visible). That would be a very simple fix which would greatly reduce the importance of this bug.
Blindly turning off auto-scroll would cause problems with tabbing through form elements. The better fix for this bug is not too hard, but I've still got some higher priority bugs. I can only promise M14. (It was going to happen in M13 were it not for the new crasher bug I just got assigned and the reopen of another PDT+ bug, sorry.)
If you have time in M13 and really want to see this in, here's where the changes need to be made: nsFormControlFrame::ScrollIntoView() nsComboboxControlFrame::ScrollIntoView() nsGfxListControlFrame::ScrollIntoView() nsHTMLButtonControlFrame::ScrollIntoView() nsImageControlFrame::ScrollIntoView() nsListControlFrame::ScrollIntoView() Probably need to change these to use something other than NS_PRESSHELL_SCROLL_ANYWHERE, probably a new scrolling constant. PresShell::ScrollFrameIntoView() Need to change this method so that if a frame is at least partially in view it is not scrolled. (if the new scrolling constant is passed in) Need to change this method so that if a frame is totally out of view horizontally or vertically it is scrolled into view in an intelligent way. Need to verify that tabbing through form elements/links still does something intelligent when off screen elements receive focus. Need to verify that when an offscreen element receives focus through javascript something intelligent happens. Need to verify that when an element that is at least partially onscreen, something intelligent happens.
*** Bug 24291 has been marked as a duplicate of this bug. ***
This is much worse today. On Win98, clicking in a text field (I used the first email field on the bugzilla query page) that is completely visible causes it to scroll vertically and horizontally so that it is completely off the screen. Raising severity to major, putting back on dogfood radar.
Severity: normal → major
Keywords: dogfood
Summary: [DOGFOOD] click in text field scrolls horizontally → Click in text field causes it to scroll out of view
Whiteboard: [PDT-]
Rod has already checked in a fix for this (he had a separate but parallel bug). I'm going to mark this one a dup of his. Please add any further issues to that bug report. Thanks! *** This bug has been marked as a duplicate of 18649 ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
Marking VERIFIED DUPLICATE on: - Linux6 2000-03-01-13 Commercial build - MacOS9 2000-03-01-13 Commercial build - Win98 2000-03-01-16 Commercial build
Status: RESOLVED → VERIFIED
No longer blocks: 24206
You need to log in before you can comment on or make changes to this bug.