Open
Bug 839446
Opened 12 years ago
Updated 2 years ago
Implement DOM3 KeyboardEvent types for media
Categories
(Core :: DOM: Events, defect, P3)
Core
DOM: Events
Tracking
()
NEW
People
(Reporter: blassey, Unassigned)
References
Details
(Whiteboard: [tech-p3])
Spinning out a separate bug from bug 674739 to handle media key events
Reporter | ||
Updated•12 years ago
|
Summary: Implement DOM3 KeyboardEvent types for audio/media → Implement DOM3 KeyboardEvent types for media
Reporter | ||
Comment 1•12 years ago
|
||
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)?
Comment 2•12 years ago
|
||
Does it necessary ASAP? I think that we shouldn't define new DOM keyCode values anymore as far as possible.
Reporter | ||
Comment 3•12 years ago
|
||
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).
Comment 4•12 years ago
|
||
Shouldn't we implement D3E instead of adding more Mozilla proprietary stuff?
Comment 5•12 years ago
|
||
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.
Comment 6•12 years ago
|
||
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.
Comment 9•12 years ago
|
||
(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?
Comment 10•12 years ago
|
||
(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.
Comment 11•12 years ago
|
||
(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)
Comment 12•12 years ago
|
||
I filed bug 842927. After that, we can avoid adding new legacy keyCode values anymore.
Flags: needinfo?(bugs)
Updated•12 years ago
|
Blocks: b2g-v-next
In the b2g use case, we need this to clean up some hacks and move onto standards.
Whiteboard: [tech-p3]
Comment 15•12 years ago
|
||
(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.
Comment 16•12 years ago
|
||
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
Comment 18•6 years ago
|
||
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
Comment 19•6 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•