I feel painful that the user app cannot listen to hardware button event. Currently every hardware button event is manipulated in the system app, but there are many cases that we would like to let app itself to deal with that. Use case#1 Dismiss alarm by volume key Use case#2 Reject call by volume key Use case#3 Disable home button when call incoming We need to write *many workarounds* to meet these requirements in system app(if we need those feature), because system app doesn't know who is dialer, who is clock app....I believe these requirement will grow up. I know this would not be v1, but I personally would love to see it happen in the future. David Flanagan, I c.c. you because you are the author of hardware button module in system app. The module is good though.

I think we made an explicit decision months ago not to allow apps access to the hardware keys. We didn't consider any of the cases you list here... I think the question was whether the camera would be able to use a hardware key as a shutter release. This seems like a UX issue. If UX is designing the dialer and alarm to have special behavior for hardware keys, maybe we should reconsider the general issue of allowing apps to see them. Maybe this is something we could re-consider for v2? I'm cc'ing Josh and putting UX in the whiteboard (though I don't know if that is the right flag) For v1, I think we just need to special case these, however. Alive, do alarms and incoming calls cause chrome events like the hardware keys do? If so, we might be able to extend hardware_buttons.js by adding new states to the finite state machine there to handle the alarm and incoming call states.

Per Josh's recent email, I'm changing the whiteboard to "interaction"

The use cases in bug descriptions are coming from 'late' UX input. See the bug numbers I marked as blocked. Too late before we invent the new hardware button module, written by you, which doesn't allow the app to get the event. I have to claim these feature as impossible function every time when the UX raises them. Yes, I open this bug just for the future: I think the same request would come again, after v1. So I don't nominate this bug for blocking. As your suggestion, this is a purely UX decision. But also a Dev decision, to tell UX that we just couldn't implement it or we will have this feature with dirty workaround which may be r- by reviewer. I look forward to third option. > For v1, I think we just need to special case these, however. Alive, do > alarms and incoming calls cause chrome events like the hardware keys do? If > so, we might be able to extend hardware_buttons.js by adding new states to > the finite state machine there to handle the alarm and incoming call states. No, they are totally different things, no Chrome Event. One is telephony API, one is mozAlarm API. Good point, but I don't think it's not another workaround to extend the module with these two APIs.

Hi Alive, good idea, and thanks for creating this bug. I'll also add this to my own v2 items tracking doc.

I'm currently writing a hardware testing app for Gaia team which can be a useful tool for developers. It can also be a util app for operators in factory to test whether the products works properly. Button test are the necessary part in the whole test.

(In reply to tjao from comment #5) > I'm currently writing a hardware testing app for Gaia team which can be a > useful tool for developers. It can also be a util app for operators in > factory to test whether the products works properly. Button test are the > necessary part in the whole test. I wonder if we run the factory mode app in-process, it may get mozChromeEvent for hardware button. Or, we could use system message to broadcast hardware button events, but I'm not sure this is a proper way.

Tim reminds me that system message would launch the app anyway...:/ My proposal: Hardware button event -> Shell.js -> BroadcastMessage with extra = {noLaunch: true} -> SystemMessageInternal -> Shell.js sends mozChromeEvents -> System app doesn't launch the app if it sees noLaunch = true. Or just prevent the |open-app| mozChromeEvent in shell.js(But I think fabrice would be unhappy with this approach.)

Fabrice, could you feedback the proposal in c7? Much thanks. Quick note: I want to use system message to broadcast hardware button event (now it's sent to system via mozChromeEvent in shell.js only) to user app, but I don't want to launch the app which is not launched in this case. My idea is using aExtra to tell system app not to launch the app. Or we could just ignore 'open-app' request in this case.

Gaia patch.

Gecko patch: broadcast hardware button events without launching the app.

Comment on attachment 798751 [details] [diff] [review] 820706-gecko.patch Review of attachment 798751 [details] [diff] [review]: ----------------------------------------------------------------- Clearing review for now, but in any case you did not include the changes to dom/messages

I'm not a big fan of using system messages instead of events here. If we really want apps to catch these, can't we figure a way to use proper key events?

I had tried DOM 3 KeyboardEvents (https://bugzilla.mozilla.org/show_bug.cgi?id=842927) but I'm unlucky to get it work... Also there's some reason that we use pageUp/pageDown key instead of volumeUp/volumeDown, so user app may not get the correct key events. See https://bugzilla.mozilla.org/show_bug.cgi?id=762362 (I don't know the reason why pageup/pagedown is mapped to volumeup/volumedown, will ask Tim..)

We use pagedown/pageup because we didn't have the media events when this was implemented. We should change that if media events are available.

After discussing w/ Tim: We shouldn't/cannot let app use keyboard events NOW (if it's working) since volumeUp/volumeDown isn't real. * Even volumeDown/volumeUp is correctly mapped, we shall resolve https://bugzilla.mozilla.org/show_bug.cgi?id=757486 side effect: non-mozbrowser iframe in mozbrowser iframe cannot pass key events to parent frame. * And what if user app prevents volumeUp/VolumeDown? Do we need to implement permission model in this case or just disable preventDefault(Don't know how yet)? Uh, a tough one :/

Hi alive, Do we have any update on this bug? >>We shouldn't/cannot let app use keyboard events NOW (if it's working) since volumeUp/volumeDown isn't >>real. Bug 674739 is fixed, but it dont have patch for gonk, so still we are getting pageup and pagedown only. >>Even volumeDown/volumeUp is correctly mapped, we shall resolve >>https://bugzilla.mozilla.org/show_bug.cgi?id=757486 side effect: non-mozbrowser iframe in mozbrowser >>iframe cannot pass key events to parent frame. I think this is working now, right now if we remove the keyboard blocking part in shell.js, apps are getting keyevents. >>And what if user app prevents volumeUp/VolumeDown? Do we need to implement permission model in this >>case or just disable preventDefault(Don't know how yet)? cant we let the apps handle the non critical hw keys like volume up and down? if app is not handling system app will handle it. ni? alive for his opinion.

See https://groups.google.com/forum/#!topic/mozilla.dev.b2g/hd0LGDeiILo

Should this be duped to bug 989198?

Well, dupe old bug to new bug is fresh, but anyway~

We tend to dup bugs to where the work is happening. The age of the bug is not the definite consideration all the time. Thanks.