We should fire key events on the parent of the selected text

NEW
Unassigned

Status

()

Core
DOM: Events
P5
normal
16 years ago
3 months ago

People

(Reporter: Doron Rosenberg (IBM), Unassigned)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
This should work:

  <table>
    <tr>
      <td onkeydown="javascript:alert('You pressed the a keyboard
button')">highlight me and press a key</td>
    </tr>
  </table>

Its not a standard, but IE and Opera support it, and for Web Apps, such things
are starting to become important.  I've heard about this from 2 seperate large
companies.

Comment 2

16 years ago
Created attachment 110174 [details]
testcase

Comment 3

16 years ago
Created attachment 110176 [details]
Testcase

This testcase shows that events do go the TD if an element inside of TD has
focus. However if the element inside is plain text it does not recive focus
when selected. In IE it does. Not sure if this is appropriate.
Attachment #110174 - Attachment is obsolete: true

Updated

16 years ago
Priority: -- → P4
Summary: <table> should support onkey* and onfocus → We should fire key events on the parent of the selected text

Comment 4

16 years ago
Since there is *no* standard for key events, I think that compatibility with the
other browsers is paramount. If/When they ever do get on the ball and specify a
standard for key events, they can follow the implementations.

joki is no longer at netscape afaik. 

vladimere, who is the appropriate person to take this? jkeiser@netscape.com ?

Can you take the lead and find out who should own this component?

Comment 5

16 years ago
Good point, I'll find out.

Comment 6

16 years ago
What I think Vladimir has just shown is that this is a focus bug, not an events
bug.  It is a general rule that keypresses go to the currently focused element,
whatever that is.  In Mozilla, text cannot receive focus.  In IE, apparently, it
can.

I don't know what component focus bugs go to.

And if this should be done at all, this deserves at least a normal importance.
Priority: P4 → P3

Comment 7

16 years ago
Created attachment 110231 [details]
previous test case using element.focus()

I think the definition of focus is the ability to receive keyevents.

The td3 listener is just picking up the key event as it bubbles from the input
which can have focus.

This new test case sets the focus to the td using the IE proprietary method
focus() and shows that although tabbing will not set focus to the td, you can
set the td to have focus and receive keyevents in IE. We have several
evangelism bugs where people use focus() on elements which do not strictly have
a focus method according to the standard. Is that somethine we want to do?

Comment 8

12 years ago
Created attachment 218022 [details]
Enhanced TD/Input downkey event tester

Revised and enhanced earlier test case to include .addEventListener, and it also works with IE.

Csaba Gabor from Vienna

Comment 9

12 years ago
Created attachment 218025 [details]
Enhanced TD/Input downkey event tester

Phooey!  Submitted a previous version.
But since I'm resubmitting this, let me just note that with FF, when you are in an input element and press a key, that character will be doubled on account of the alert.  With IE, you get the expected character just once.  That is why, if you try to tab out of the first input element, you wind up in the third one.

If, instead of the showEventInfo(e); call (which contains the alert), you use something like
window.setTimeout(function (evt) { return function() { showEventInfo(evt); } }(e), 50);
then you don't have this problem.
Attachment #218022 - Attachment is obsolete: true
Assignee: joki → nobody
QA Contact: vladimire → events
Bulk priority change, per :mdaly
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.