chrome/content/shell.js: remove 'home' event and other non-standard event types

RESOLVED FIXED in PreProduction


8 years ago
8 years ago


(Reporter: djf, Assigned: vingtetun)


Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)

chrome/content/shell.js currently sends a 'home' event when the Home key is pressed.

This patch changes it so that a 'home' event is sent on key up after a short press, and a 'switcher' event is sent if the home button is held down for 1 second.

This is needed to resolve:
Attachment #600515 - Attachment is patch: true
Attachment #600515 - Flags: review?(jones.chris.g)
Attachment #600515 - Flags: review?(fabrice)
Why do you want to do such code here? This code can live on the Gaia side, right? (This behavior and the switcher event sound really specific to Gaia)
Comment on attachment 600515 [details] [diff] [review]
patch to b2g/chrome/content/shell.js

I agree with Vivien.
Attachment #600515 - Flags: review?(jones.chris.g) → review-

The code has to be here because shell.js currently sends the 'home' event on keypress.  I.e. it doesn't wait for the button to be released.  But for the new behavior we want in Gaia, we need it to send the home event when the button is released. 

Or we need to just get rid of the home event completely and do everything with keyup and keydown events in Gaia.  Either way, changes are needed here.
The home HW button should behave like a key.  If it doesn't we should fix that.

let's replace the 'sepcial' key events at y normal key events and let the content (Gaia) handle them normally.

nsAppShell.cpp already sends the Home key as a regualar key event.  It looks like menu, search and volume up and volume down are sent as "special" key events.

It is the shell.js file that I'm patching that turns these regular key events into a special, non-standard "home" event. 

I assumed that there was some good reason for that "home" event to be there in shell.js, which is why I modified the file to add a new event type.  But I agree that if we can just remove "home" events from shell.js, then we can handle the short press vs. long press distinction in content rather than chrome.

I assume those other key events are "special" because there is not an existing key code that they can use, but I don't know.  In any case, if they need to be changed in nsAppShell.cpp, that is a different bug, I think.
Summary: chrome/content/shell.js: make long press on home key send 'switcher' event instead of 'home' → chrome/content/shell.js: remove 'home' event and other non-standard event types
Attachment #600515 - Attachment is obsolete: true
Attachment #600515 - Flags: review?(fabrice)
I've changed the title of the bug to match the discussion here, and have marked the attached patch as obsolete.
Posted patch Patch (obsolete) — Splinter Review
The patch remove all non-standards events from b2g/ (except showime/hideime but this is the scope of the mozKeyboard API).

There is some black magic to redirect key events to the homescreen if they are fired on an an other iframes and if they have not been cancelled.
The magic also always notify the homescreen of a keydown/press/up on the home button to ensure nobody prevent the user to go back to the homescreen.
Assignee: nobody → 21
Attachment #601313 - Flags: review?(jones.chris.g)
Posted patch Patch v0.2Splinter Review
This version sounds easier to understand.
Attachment #601313 - Attachment is obsolete: true
Attachment #601551 - Flags: review?(jones.chris.g)
Attachment #601313 - Flags: review?(jones.chris.g)
Comment on attachment 601551 [details] [diff] [review]
Patch v0.2

Review of attachment 601551 [details] [diff] [review]:

\o/ for removing commandUtils.js
Attachment #601551 - Flags: review?(jones.chris.g) → review+
OS: Linux → Gonk
Hardware: x86_64 → ARM
Target Milestone: --- → PreProduction
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.