Thank you two for replying! [email protected] 於 2013/9/4 下午5:58 寫道： >> >> We could change the mapping. With DOM3 KeyboardEvents those key should >> have evt.key == 'VolumeDown' or 'VolumeUp'. > Indeed.
Is the mapping change could be done in gecko? >> I think we should broaden the definition of the DOM event flow. The >> event flows like 'B2G Chrome'-->'Window Manager (System app)'-->'Currently >> focused app' >> >> And we could define the default action of those events. System app could >> catch the event even if the app tries to preventDefault it (if it's >> cancelable) > So we'd want to propagate event back from focused app to chrome/system? That > is of course asynchronous, but should be ok. > We do have some support for that in > TabParent/TabChild/nsIFrameLoader.activateFrameEvent() and in DOM events (we > can serialize/deserialize certain > types of events), however I'm not aware that being used currently. Looks like > key events aren't supported currently, but > if this mechanism would be useful for b2g, adding ::Serialize/::Deserialize > to nsDOMKeyboardEvent should be easy. A little - no, much out of my knowledge (: Could we have a bug about this? IMO, there shall be some events which are critical to be canceled by user app: power, home button is the case. Some events are not that critical to be canceld: volumeUp, volumeDown is the case. I don't mind if we couldn't choose but just forbid user app to consume all hardware button event. -- Alive C. Kuo, Front-end Engineer, FirefoxOS, MoCo. Taiwan, Taipei office. [email protected] _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
