We've discussed about "Accel" virtual modifier key value in the TPAC 2015. Then, we agreed with removing "Accel" virtual modifier key from the spec because no API can provide the caption of actual "Accel" modifier (i.e., "Accel" virtual modifier cannot remove platform check completely). However, this is still useful our internal code. So, we should rename "Accel" to "MozAccel".
Hmm, MozAccel? That must not be exposed to the web. We have already have exposed 'Accel' to the web, right? Why is there backwards incompatible change to the spec?
Though, I do agree that previous versions of the spec were very vague about 'Accel' usage.
> Hmm, MozAccel? That must not be exposed to the web. Okay, it's possible. The virtual modifier is valid only with .getModifierState(). So, we can check if the context is chrome or content. > We have already have exposed 'Accel' to the web, right? Why is there backwards incompatible change to the spec? Yes, we've done. Gary claimed that there are only a few web applications which implement their own shortcut keys. It doesn't make sense to define this incomplete feature only for the minor applications. I agree with that actually, no applications are now using this new feature actually. So, I think no web applications will be broken by this change.
I wonder if we could add telemetry to detect if web pages use 'Accel'
(In reply to Olli Pettay [:smaug] from comment #4) > I wonder if we could add telemetry to detect if web pages use 'Accel' Although, I don't know how to do that, it's enough safe because other browsers never support "Accel" yet. Another possible way is, we don't drop "Accel". It's not exposed as KeyboardEvent.key. It's only valid with getModifierState() and an alias of a modifier. So, even if we don't drop to support "Accel", nothing won't changed except the result of getModifierState("Accel").
You need to log in before you can comment on or make changes to this bug.