148249 - accesskey does not work for <input> or <textarea> fields

Status: RESOLVED FIXED

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

Description

[:deanis74]

You can't set an accesskey for input or textarea fields.  It works properly in
IE, and according to the w3c it should be supported.  From
http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey:

  The following elements support the accesskey attribute: A, AREA, BUTTON,
  INPUT, LABEL, and LEGEND, and TEXTAREA

Comment 1

[:deanis74]

Attachment: This doesn't work, nor does it work if you change <INPUT> to <TEXTAREA>

Comment 2

[:deanis74]

Attachment: Using <LABEL> works, of course, also does if you change <INPUT> to <TEXTAREA>

Comment 3

[Shotaro Kamio]

worksforme? Both two test cases works well on 1.0RC3/Linux.

Comment 4

[rods (gone)]

-->

Comment 5

[:deanis74]

Huh, maybe this is a windows-only bug?  The first test case still fails on Win2K
using 2002060308.  The second test case is for reference only, showing that the
'B' access key will override the 'B' for the Bookmarks menu.

Comment 6

[Jesse Ruderman]

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

Comment 7

[Sander]

confirmed using 2002061104 - win98
Accesskeys in buttons and submits doesn't work either; this change was
introduced somewhere between 1.0 and 1.1 alpha, I'll go and narrow that down
later on.
Can bug 149202 be taken as a dupe and be used to change platform and OS to all?
(Not sure since it's a Chimera bug and I don't know how many changes there are
between Mozilla and Chimera.)

Very annoying problem this, as I do a lot of processing information in forms
where alt-s submits the form; now I actally have to reach over to the mouse to
click something. (Which may not sound so bad, except when you submit information
at the rate of two forms a minute...)

Comment 8

[Aaron Leventhal]

It would be great if someone could track down when this broke.
WFM in Netscape 7 beta.

Comment 9

[Aaron Leventhal]

-> Jag, any ideas?

Comment 10

[jag (Peter Annema)]

-> default owner.

Nope, no idea.

Comment 11

[Sander]

I've tracked down the day where this broke.
2002052008 works
2002052108 doesn't work

*heads off to bonsai to see if he can identify what changed, though doesn't have
much hope of that*

Comment 12

[Sander]

I suspect the patch for bug 96813 to be guilty of this (at least, it's the only
one I could find which changes things about accesskeys) - cc'ing dbaron

Comment 13

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

Did you get that regression window right.  The checkins that fit it are
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2002-05-20+06%3A00&maxdate=2002-05-21+09%3A00&cvsroot=%2Fcvsroot

Comment 14

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

Attachment: patch

This fixes it.	It was a regression from jst's checkin.

Comment 15

[Aaron Leventhal]

Comment on attachment 88506 [details] [diff] [review]
patch

r=aaronl

Ah yeess - I noticed that before as I was working on underlining HTML
accesskey. Thought it was strange at the time, should have reported it.

Comment 16

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

Taking.

Comment 17

[Johnny Stenback (:jst)]

Comment on attachment 88506 [details] [diff] [review]
patch

sr=jst

Comment 18

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

Fix checked in 2002-06-20 13:44 PDT.

Comment 19

[Sander]

*blinks* woaw, that was fast. :)
I didn't narrow my bonsai search down beyond simply the two days as I had no
idea which components use which timezones.
I'm now assuming both bonsai and the buildid are GMT?

Comment 20

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

No, they're both PDT (GMT-0700) or PST (GMT-0800), depending on the season.