64170 - when textbox is focused, it needs to scroll to make insertion point visible

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Go to Prefs->MailNews->Address Books or
data:text/html,<input type=radio><input type="text" size="3" value="123456789">.
2. Click on the control that's before the tiny textbox.
3. Press tab.

Result: keyboard focus is switched to the textbox and the insertion point is 
put at the end of the text in the textbox, but the textbox doesn't scroll to 
make the insertion point visible.

Comment 1

[rods (gone)]

reassigning

Comment 2

[rubydoo123]

reassign to kin for review

Comment 3

[kinmoz]

Accepting bug.

Comment 4

[Vladimir Ermakov]

QA Contact Update

Comment 5

[Jesse Ruderman]

Fixing bug 28583, "Focusing text widget (except on click) should select widget",
would make this bug less important.  (Scripts would still be able to put the
insertion point at the end of a text field using selectionStart and selectionEnd.)

Comment 6

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 7

[Kevin McCluskey (gone)]

Set milestone to Moz1.1

Comment 8

[Jesse Ruderman]

*** Bug 51897 has been marked as a duplicate of this bug. ***

Comment 9

[Felix Miata]

How does a multi-platform, normal severity, priority one bug with more (but not
excessive) included commentary get duped to a later file, single platform, minor
priority bug, as bug 51897 was to this, and not acquire all those higher
priority attributes?

Comment 10

[saari (gone)]

invalid, should highlight the text instead (there is already a bug on it)

Comment 11

[Taras Tielkes]

saari, 

What do you mean, exactly?

Since when should bringing focus to a textfield highlight the whole field?

If this bug is about something else than what I understand, I'll re-open Bug 
51897 

Comment 12

[Taras Tielkes]

Does anyone understand the last comment from saari?

Hey saari, what about mentioning a bug number?

Comment 13

[Jesse Ruderman]

Saari is referring to bug 28583, "Focusing text widget (except on click) should
select widget contents".  I don't think fixing bug 28583 would be sufficient,
for two reasons:

1. Bug 28583 does not apply to textareas.
2. CSS3 may allow web pages to specify what happens when you tab to a text field
using the user-focus-key property (http://www.w3.org/TR/css3-userint#user-focus).

Comment 14

[Felix Miata]

Bug 51897 duped to this was:

OS-ALL
Priority-P1
Severity-normal

This bug should not have any of the same attributes set to a lower level than
the above. This is not a windoze only bug any more. There is no good reason for
a missing focus bug to be considered minor.

Comment 15

[Taras Tielkes]

Is there any traction on this?

Bug 51897 was reported two years ago, had high priorities, and is, all things 
considered, a Netscape 1.0-era usability problem.

A form puts focus on a field, and there is no visible indication of that. This 
applies to thousands of applications that worked correctly for years and years, 
and are broken with Netscape 6+

Comment 16

[Jesse Ruderman]

Attachment: testcase

Comment 17

[Jesse Ruderman]

This bug is still present in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030914
Firebird/0.6.1+

Comment 18

[Vidar Haarr (not reading bugmail)]

Attachment: version 0.1

bz: How does this look?

Essentially this makes any textarea or input=text scroll to the caret position
on focus.

I initially wanted to add it to
<http://lxr.mozilla.org/seamonkey/source/layout/forms/nsTextControlFrame.cpp#310>,
but mTextSelImpl is private to nsTextControlFrame ...

I'm not sure if we should do it for both inputs and text areas? I'd like to,
but some people might find it annoying, I don't know.

mpt: Any thoughts?

Comment 19

[Matthew T (active 1999-2002)]

Just three. (1) Tabbing to single-line fields should not scroll them, except 
as allowed by bug 172203. (2) Clicking to focus a field should never result 
in scrolling (even if a previous selection was off-field). (3) Thanks Vidar!

Comment 20

[Boris Zbarsky [:bzbarsky]]

Vidar, I'd need to apply that patch and play with it for a while to say anything
useful -- I don't really know that code very well...  You might want to try a
different reviewer, because I doubt I'll have the time to really look at this in
the near future (months, possibly).

Comment 21

[Vidar Haarr (not reading bugmail)]

Comment on attachment 196678 [details] [diff] [review]
version 0.1

Not quite sure who knows this code ...

Maybe dbaron ? :-)

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Have you tested that this does what comment 19 says?  What else have you tested, for HTML text inputs, XUL text inputs, and HTML textareas?

Comment 23

[Vidar Haarr (not reading bugmail)]

(In reply to comment #22)
> Have you tested that this does what comment 19 says?  What else have you
> tested, for HTML text inputs, XUL text inputs, and HTML textareas?

Hm, I can't remember which one, but I think one of the points in comment 19 gave unwanted behavior with the patch. Also, I don't think I tested XUL text inputs.

I'll hopefully get to testing this within a week or so. If anyone know any good testcases, please let me know.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 196678 [details] [diff] [review]
version 0.1

minusing review request until questions are answered; feel free to re-request

Comment 25

[Jesse Ruderman]

See also bug 353539, same bug for textareas.

Comment 26

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 27

[(no longer active)]

My patch in bug 353539 fixes this problem.

Comment 28

[(no longer active)]

Bug 353539 landed.

Comment 29

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381