Open Bug 839446 Opened 12 years ago Updated 2 years ago

Implement DOM3 KeyboardEvent types for media

Categories

(Core :: DOM: Events, defect, P3)

Product:
Core
Component:
DOM: Events
Type:
defect

Tracking

()

People

(Reporter: blassey, Unassigned)

References

Details

(Whiteboard: [tech-p3])

Spinning out a separate bug from bug 674739 to handle media key events
Summary: Implement DOM3 KeyboardEvent types for audio/media → Implement DOM3 KeyboardEvent types for media
Masayuki, what key codes are free to map to the media key events? Also, is there a list of them somewhere to refer to (rather than asking you every time)?
Does it necessary ASAP? I think that we shouldn't define new DOM keyCode values anymore as far as possible.
There is desire for these now as we're implementing WebRTC and bringing h.264 support online (such that the video tag is actually getting used).
Shouldn't we implement D3E instead of adding more Mozilla proprietary stuff?
Yes. D3E key event stuff just happens to be quite major thing. If we absolutely need to improve our DOM0 APIs before D3E key events, we can.
The blocker issue of D3E KeyboardEvent.key is the value of printable keys with some modifier keys. W3C have never replied about that clearly. It seems that if we set "Unidentified" (or empty string) to all printable keys for now, we can implement KeyboardEvent.key without compatibility issue in the future.
Masayuki: If you need help with getting feedback on the W3C lists, either Olli, Mounir or I can help. I definitely agree that we need to get W3C to move on something here. If other vendors aren't responding on the list, saying that we have a solution in the works tend to get attention. And as a last-resort implement something and making sure it's horribly named enough that we won't collide with whatever W3C comes up with.
Masayuki: Wearable device (headset) manufactures will have a few key press events that will likely need to be brought up in the W3C. From a Bluetooth headset, media button events that are vendor agnostic are: Power Hook flash (answer/hangup call) Mute Volume up Volume down Play Pause Forward Rewind Next Previous Stop My company currently is not participating in the W3C, but I am more than happy to help give input to the list from the wearable device perspective.
(In reply to cary.bran from comment #8) > Power > Hook flash (answer/hangup call) Can't see anything related to these in D3E. > Mute D3E has VolumeMute > Volume up D3E has VolumeUp > Volume down D3E has VolumeDown > Play D3E has MediaPlay > Pause D3E has MediaPause > Forward > Rewind > Next > Previous D3E has few values related to these, PlaySpeedUp and MediaNextTrack and FastFwd etc > Stop MediaStop > My company currently is not participating in the W3C, but I am more than > happy to help give input to the list from the wearable device perspective. Could you just send email to www-dom mailing list?
(In reply to Jonas Sicking (:sicking) from comment #7) > Masayuki: If you need help with getting feedback on the W3C lists, either > Olli, Mounir or I can help. Thanks.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6) > The blocker issue of D3E KeyboardEvent.key is the value of printable keys > with some modifier keys. W3C have never replied about that clearly. > > It seems that if we set "Unidentified" (or empty string) to all printable > keys for now, we can implement KeyboardEvent.key without compatibility issue > in the future. Smaug, how do you feel about this my idea? I think that it's very useful if we implement KeyboardEvent.key only for non-printable keys. And we don't need to define new legacy DOM keyCode anymore except for compatibility with other browsers. Then, the patches become simple. If you agree with this idea, I'll make them at first of my queue. And if so, I'd like to know your idea about the temporary key value for printable keys. I think that either "Unindentified" or "" (empty string) is okay for now.
Flags: needinfo?(bugs)
I filed bug 842927. After that, we can avoid adding new legacy keyCode values anymore.
Flags: needinfo?(bugs)
In the b2g use case, we need this to clean up some hacks and move onto standards.
Whiteboard: [tech-p3]
(In reply to Chris Jones [:cjones] [:warhammer] from comment #14) > In the b2g use case, we need this to clean up some hacks and move onto > standards. See bug 842927.
Now, bug 842927 is fixed. So, you can use most of the keys with KeyboardEvent.key or nsKeyEvent::mKeyNameIndex. You can check the mapping here: https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#keyname_table_android Unfortunately, >> Hook flash (answer/hangup call) > Can't see anything related to these in D3E. This hasn't supported yet due to https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.