26019 2014-06-09 10:48:33 +0000 No way to initialize modifier states except "Alt", "Control", "Shift" and "Meta" at constructing DOM event with constructor 2015-02-11 01:59:48 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Windows NT RESOLVED FIXED P2 normal --- 27902 27903 1 masayuki travil annevk crimsteam mike www-dom public-webapps-bugzilla oldest_to_newest 107514 0 masayuki 2014-06-09 10:48:33 +0000 At creating a DOM event with its constructor, there is no way to initialize some modifier states which is only retrieved with .getModifierState(). E.g., "CapsLock", "NumLock", "ScrollLock", "OS", "AltGrapsh", "Super", "Hyper", etc. The reason why they *should* not be initializable with constructor, I think MouseEvent and KeyboardEvent should have .initModifierStates() which can take space separated modifier key name list as a DOMString. However, even if D3E spec defines such method, it should do nothing while the event is being dispatched. And also, if the event is trusted event, it should never work. 107544 1 travil 2014-06-09 17:13:19 +0000 Rather than introduce another method similar to the now deprecated init* methods, I would rather extend the initMouseEvent and initKeyboardEvent dictionaries with the relevant modifier initializers. Perhaps: * boolean modifierStateCapsLock * boolean modifierStateNumLock * boolean modifierStateScrollLock * boolean modifierStateOS * boolean modifierStateAltGraph * boolean modifierStateSuper * boolean modifierStateHyper etc. The dictionary format is perfect for this kind of extensibility. 107547 2 masayuki 2014-06-09 17:51:58 +0000 Yeah, if they can be initialized with constructor, it's the best. 107741 3 travil 2014-06-12 17:45:45 +0000 (In reply to Masayuki Nakano from comment #2) > Yeah, if they can be initialized with constructor, it's the best. I've got a private copy of this change now, and while writing it I made a few assumptions that I'd like to discuss: 1. Some of the getModifierState params duplicate existing attributes, e.g., "Alt" and the altKey IDL attribute. Consequently, I've not created the new initializers for "Alt", but have made it explicit (in the prose for the existing "altKey" initializer on the dictionary) that is also sets the internal modifier state of the event such that calls to getModifierState('Alt') also return true. This avoids the duplication. 2. When initializing "ctrlKey" or "metaKey" I define that the internal states for getModifierStates "Control" and "Meta" are set (as described above), but also that the virtual "Accel" modifier is also set. So initializing "ctrlKey" to true will cause calls to getModifierState("Control") and getModifierState("Accel") to also return true. 3. Given #2 above, I'm going to assume that if either "ctrlKey" OR "metaKey" is true, then "Accel" is also true, rather than using ("ctrlKey" AND "metaKey") logic. 107744 4 masayuki 2014-06-12 18:04:42 +0000 (In reply to Travis Leithead [MSFT] from comment #3) > (In reply to Masayuki Nakano from comment #2) > 1. Some of the getModifierState params duplicate existing attributes, e.g., > "Alt" and the altKey IDL attribute. Consequently, I've not created the new > initializers for "Alt", but have made it explicit (in the prose for the > existing "altKey" initializer on the dictionary) that is also sets the > internal modifier state of the event such that calls to > getModifierState('Alt') also return true. This avoids the duplication. I believe that it's right approach. If D3E allows two names for a state, following case is really a problem: new Event("", altKey: true, modifierStateAlt: false); So, I agree with that modifier states which can be represented by legacy fooKey shouldn't be initialized with modifierState*. > 2. When initializing "ctrlKey" or "metaKey" I define that the internal > states for getModifierStates "Control" and "Meta" are set (as described > above), but also that the virtual "Accel" modifier is also set. So > initializing "ctrlKey" to true will cause calls to > getModifierState("Control") and getModifierState("Accel") to also return > true. I think that it's not problem. Additionally, web apps can test which modifier is the "Accel". E.g., var ctrlEvent = new KeyboardEvent("", { ctrlKey: true }); var metaEvent = new KeyboardEvent("", { metaKey: true }); var accelText = ctrlEvent.getModifierState("Accel") ? "Ctrl" : metaEvent.getModifierState("Accel") ? "Command" : ...; Like this, web apps can show proper modifier key label dynamically. > 3. Given #2 above, I'm going to assume that if either "ctrlKey" OR "metaKey" > is true, then "Accel" is also true, rather than using ("ctrlKey" AND > "metaKey") logic. However, depending on the prefs on Firefox. Firefox can also set "Alt" or "OS" (and "Super", "Hyper" soon) as a modifier for acceleration. Although, it must be rare case. Anyway, modifierStateAccel should not exist in the dictionary. 107746 5 annevk 2014-06-12 18:14:29 +0000 Travis, note that if your initialization process is not covered by http://dom.spec.whatwg.org/#constructing-events we need to figure out how to make that work. You might have to define the entire constructor yourself. 107818 6 travil 2014-06-13 22:34:38 +0000 I landed v1 of this change. Anne, I need to look and see what magic flags may be available to define this more specifically--I wanted to land this much now, since it refactors some of the event dictionaries... 107819 7 travil 2014-06-13 22:34:54 +0000 (In reply to Travis Leithead [MSFT] from comment #6) > I landed v1 of this change. > > Anne, I need to look and see what magic flags may be available to define > this more specifically--I wanted to land this much now, since it refactors > some of the event dictionaries... https://dvcs.w3.org/hg/dom3events/rev/8034c1f1c711 107820 8 travil 2014-06-13 22:37:47 +0000 (In reply to Anne from comment #5) > Travis, note that if your initialization process is not covered by > http://dom.spec.whatwg.org/#constructing-events we need to figure out how to > make that work. You might have to define the entire constructor yourself. Mmm. DOM doesn't seem to have the hooks I need. I need some internal state that can represent the possible values used by the getModifierState function... I should be able to whip that up. 117843 9 travil 2015-02-11 01:59:48 +0000 (In reply to Travis Leithead [MSFT] from comment #8) > (In reply to Anne from comment #5) > > Travis, note that if your initialization process is not covered by > > http://dom.spec.whatwg.org/#constructing-events we need to figure out how to > > make that work. You might have to define the entire constructor yourself. > > Mmm. DOM doesn't seem to have the hooks I need. I need some internal state > that can represent the possible values used by the getModifierState > function... I should be able to whip that up. Committed a rough extension to Anne's algorithm in the DOM spec. https://dvcs.w3.org/hg/dom3events/rev/ad15280ceb0c