63227 - TAB into input TEXT does not keep object scope

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Wayne Schroeder]

I am a software developer with sprint.  I have a html form which, unless the
user selects 'other' from a select list, the value of a text field should be
read only.  The way I have done this is to bind the onFocus of the text field to
a function which checks for this.. if it is not to be modified.. it calls the
blur method.  This works fine for mouse click focus.  Tab focus on the other
hand does not call the onFocus event.

This is on the 0.6 milestone release.

Wayne

Comment 1

[Phil Schwartau]

Browser, not engine ---> Event Handling


Wayne, would you be able to attach a reduced testcase to this bug? 
(See "create a new attachment" above). Or is there a URL we can 
go to in order to reproduce this? Thanks -

Comment 2

[Wayne Schroeder]

I have changed the summary to better describe the issue.  I will next attach a
test case which demonstrates the problem at hand.

-Wayne

Comment 3

[Wayne Schroeder]

Attachment: Test case.. follow on page instructions to reproduce error

Comment 4

[Fabian Guisset]

I can reproduce with the testcase. The following is from the testcase :
blur() doesn't work when the text area is accessed with a tab,
self.blur() works when the text area is accessed with a tab,
both work when the text area is accessed with a mouse click.

Comment 5

[Keyser Sose]

VERIFIED
Platform:PC
OS: Linux 2.2.16
Mozilla: 2000122808 M18 Trunk


Marking NEW.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Clearing milestone.

Comment 7

[Loco]

Confirming on Mac OS 01-04-08.  Just for reference, if you click in the top field 
one, you can tab into top field two and type something.  In the bottom set, you 
can click in field one and tab into fiedl two, but no typing is allowed.

Changing Plat/OS to ALL/ALL.

Comment 8

[joki (gone)]

Might not be to hard.  Might be really hard.  I'll have to see how easily we can 
get to the object info there.  I'll try it soon either way.

Comment 9

[Hixie (not reading bugmail)]

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

Comment 10

[clayton]

Pushing out one milestone.  Joki has too much to do.

Comment 11

[Madhur Bhatia]

QA contact updated

Comment 12

[joki (gone)]

Moving lower priority bugs out of .9.2 milestone.

Comment 13

[Blake Ross]

Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.

Comment 14

[saari (gone)]

->0.9.5

Comment 15

[joki (gone)]

Moving to 0.9.6

Comment 16

[Jesse Ruderman]

onfocus=blur() is not a good way to make a text field read-only, for two 
reasons:

1. Read-only fields are normally focusable with Tab, allowing the user to copy 
information out of the field.

2. If a user tabs into the field, focus will be lost.  Once the user realizes 
that focus was lost, he will have to tab from the beginning of the page.  (Many 
advanced users use tab to get to the next form field, and blind users rely on 
that method because they can't use pointing devices effectively.)

Instead of using javascript event tricks, you should make the field disabled 
(unfocusable and gray) or read-only (focusable but uneditable, and not visually 
distinct).  I think disabled is more appropriate for this situation.  (Or, if 
you really want to avoid confusing the user, you could just put the text "If 
other:" before the text field.)

Comment 17

[joki (gone)]

0.9.6 has passed, moving to 0.9.7.  Load balancing 0.9.7 list shortly

Comment 18

[joki (gone)]

Moving bugs from 0.9.7 for triaging in 0.9.8

Comment 19

[joki (gone)]

Moving to 1.1.

Note, recheck for validity, has not been checked in some time.

Comment 20

[Pham]

.

Comment 21

[Vedran Miletic]

retargeting