Music player controls on the lockscreen, etc.

[David Flanagan]

For version 1.2, we have a requirement to allow the music player app to
be controlled from the lockscreen. UX is working on a design, and the
discussion has also included thoughts about putting something in the
status bar and allowing the app to be controlled from the notification
tray. Or maybe including music controls with the volume level if music
is playing and the user uses the volume buttons.

If you've got thoughts about this, Rob (cc'ed) might be interested in
hearing them as he works on the design.

The design of this feature is being driven by the Media team, but I
imagine that a lot of the implementation will fall to the System team,
so I'm cc'ing Lucas. Tim and Fabrice: I'm cc'ing you two on this message
because you might be asked to help us estimate the engineering effort
involved in implementing this.

David

[Andreas Gal]

Can this be handled by a simple postMessage protocol between the music
app and the lock screen app?

Sent from Mobile.

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[David Flanagan]

On 6/10/13 4:22 PM, Andreas Gal wrote:
> Can this be handled by a simple postMessage protocol between the music
> app and the lock screen app?

Yes, I expect so. And if the lockscreen continues to be part of the
system app, that should be straightforward.

I forgot to mention that we probably also want the music app to be
controllable from bluetooth devices (headsets, car audio systems) and
will want to design a control protocol that works for both cases.

[Peter Dolanjski]

Rob, in terms of UX, IMO controlling tracks via physical buttons (hold volume keys to advance to next/previous track) is a huge benefit for the use cases where looking at the screen isn't feasible (jogging, driving a car, etc.).

Peter

[Rob MacDonald]

Hi Peter…

I agree physical buttons are helpful for changing tracks when not looking at the screen but I'd likely recommend against using the volume keys to do this. First, I'm not sure if this is what the user would expect. Second, I think that the volume should get priority and that building a delay in this (to detect the long press) circumvents the primary purpose of the button… which could be quite time sensitive. Finally, it also has the potential to conflict with the UX for the EU volume prompt, which prevents the user from increasing the volume to its maximum until the user acknowledges an on screen dialog.

Instead, I was thinking of looking at having larger hit areas or perhaps even a horizontal swipe to move to the next track. So the affordance and ease of use could still be there, but perhaps not as a physical button. (We'll also have to weigh this against notifications, the PIN key, etc.)

Does that help?

Best regards,
Rob

---
Rob MacDonald
Sr. Interaction Designer, Firefox OS
Mozilla Corporation

[Peter Dolanjski]

It's just something that I've used heavily previously and found incredibly useful - but I'm not the target user.
I just want to clarify that the volume does remain the priority. The long press would be for track change, so it shouldn't affect the volume prompt.

Anyways, just a suggestion. I'll certainly defer to you on the design.

[David Flanagan]

On 6/10/13 4:22 PM, Andreas Gal wrote:
> Can this be handled by a simple postMessage protocol between the music
> app and the lock screen app?

Dietrich prompted me to read this more carefully... I don't know if
postMessage() works between apps like this. It sure would be awesome if
it did!

David

[Scott Michaud]

Two (mutually exclusive) options that, for better or worse, have yet to
be explored:

1. We could concede and offload this support to specific hardware.
1. In-line headphone controls as seen, recently, in Android (and
iOS for much longer).
2. Bluetooth controls.
3. Optional media buttons on the device itself.

Of course this would not be ideal for users left behind, but still
something to consider if the alternative is annoy every user with a bad
interface.

2. Modify the lock screen if an app, identifying as a media player, is
running music while the device is locked.
1. Big buttons with minimal places to accidentally click.
2. A tutorial-message/animation on how to control media with gestures.
3. A single touch target with gestures (ex: tap to pause, hold and
swipe one way or another to skip forward/back).

Of course this would create a context-sensitive lock screen, which will
give users anxiety about what else in the interface is modal (or worse,
encourage modal interfaces). But, this allows tailoring the situation
for the specific user needs.

Any other high-level options we haven't thought of? Any direction, of
the several mentioned in this thread, worth going a little deeper into
exploring?

-Scott Michaud

On 6/10/2013 8:13 PM, Rob MacDonald wrote:
> Hi Peter…
>
> I agree physical buttons are helpful for changing tracks when not looking at the screen but I'd likely recommend against using the volume keys to do this. First, I'm not sure if this is what the user would expect. Second, I think that the volume should get priority and that building a delay in this (to detect the long press) circumvents the primary purpose of the button… which could be quite time sensitive. Finally, it also has the potential to conflict with the UX for the EU volume prompt, which prevents the user from increasing the volume to its maximum until the user acknowledges an on screen dialog.
>
> Instead, I was thinking of looking at having larger hit areas or perhaps even a horizontal swipe to move to the next track. So the affordance and ease of use could still be there, but perhaps not as a physical button. (We'll also have to weigh this against notifications, the PIN key, etc.)
>
> Does that help?
>
> Best regards,
> Rob
>
> ---
> Rob MacDonald
> Sr. Interaction Designer, Firefox OS
> Mozilla Corporation
>
> On 2013-06-10, at 4:35 PM, Peter Dolanjski <pdola...@mozilla.com> wrote:
>
>> Rob, in terms of UX, IMO controlling tracks via physical buttons (hold volume keys to advance to next/previous track) is a huge benefit for the use cases where looking at the screen isn't feasible (jogging, driving a car, etc.).
>>
>> Peter
>>
>> ----- Original Message -----
>> From: "David Flanagan" <dfla...@mozilla.com>
>> To: "Andreas Gal" <andre...@gmail.com>
>> Cc: "Fabrice Desré" <fab...@mozilla.com>, "Tim Chien" <timd...@mozilla.com>, "Rob MacDonald" <rmacd...@mozilla.com>, "Lucas Adamski" <lada...@mozilla.com>, mozilla-...@lists.mozilla.org
>> Sent: Monday, 10 June, 2013 7:26:42 PM
>> Subject: Re: Music player controls on the lockscreen, etc.
>>

>> On 6/10/13 4:22 PM, Andreas Gal wrote:
>>> Can this be handled by a simple postMessage protocol between the music
>>> app and the lock screen app?

[Fabrice Desre]

On 06/10/2013 05:34 PM, David Flanagan wrote:
> On 6/10/13 4:22 PM, Andreas Gal wrote:
>> Can this be handled by a simple postMessage protocol between the music
>> app and the lock screen app?

> Dietrich prompted me to read this more carefully... I don't know if
> postMessage() works between apps like this. It sure would be awesome if
> it did!

If that works, I'd like to know why we abused the settings API in
similar situations.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Alive Kuo]

Hi David,

Dominic told me this yesterday.

My quick thought is, utilize current window.open feature, like what we do for attention screen and website bookmark,

var lockscreenWindow = window.open('lockscreen-control.html', title, 'lockscreen');

And, yes, use postMessage as communication way as parent music app and child lockscreen control window.

To be strict, this needs some further permission specified(at manifest), or we may need to hard code music app's origin/manifest in system app(I don't want this!),
to avoid any other un-authorized app could open a window on lockscreen.

Also, the window on lock screen should be involved in page visibility control,
and we could just apply the same rule as lockscreen itself. (Only be affected when screen change-event happens).

We could furthermore discuss the life cycle of the opened window on lock screen:
* Should we remove the window once the lock screen is unlocked?
- If yes, music app needs to know its sub-window is closed by us. I guess window.onclose will work.
* Should we open it once device boot up? ---- I don't think so because this needs us to invoke music app when device started.
* We should remove the sub window once music is closed or crashed.

A similar module like window manager is needed, but it's more simplified.
--
Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)

[Rob MacDonald]

Hi Peter…

It sounds like it works a bit differently than I assumed. I'm always open to exploring new options (in spite of what it sounded like in my last message). Can you send me some examples of devices that use this feature when you get a chance?

Thanks!

Rob

---
Rob MacDonald
Sr. Interaction Designer, Firefox OS
Mozilla Corporation

On 2013-06-10, at 5:31 PM, Peter Dolanjski <pdola...@mozilla.com> wrote:

> It's just something that I've used heavily previously and found incredibly useful - but I'm not the target user.
> I just want to clarify that the volume does remain the priority. The long press would be for track change, so it shouldn't affect the volume prompt.
>
> Anyways, just a suggestion. I'll certainly defer to you on the design.
>

> Peter
>
> ----- Original Message -----

> From: "Rob MacDonald" <rmacd...@mozilla.com>
> To: "Peter Dolanjski" <pdola...@mozilla.com>
> Cc: "David Flanagan" <dfla...@mozilla.com>, "Fabrice Desré" <fab...@mozilla.com>, "Tim Chien" <timd...@mozilla.com>, "Lucas Adamski" <lada...@mozilla.com>, mozilla-...@lists.mozilla.org, "Andreas Gal" <andre...@gmail.com>

> On 6/10/13 4:22 PM, Andreas Gal wrote:
>
>
> Can this be handled by a simple postMessage protocol between the music
> app and the lock screen app?

> Yes, I expect so. And if the lockscreen continues to be part of the
> system app, that should be straightforward.
>
> I forgot to mention that we probably also want the music app to be
> controllable from bluetooth devices (headsets, car audio systems) and
> will want to design a control protocol that works for both cases.
>
>
>
> Sent from Mobile.
>
> On Jun 11, 2013, at 8:16, David Flanagan < dfla...@mozilla.com > wrote:
>
>
>

[Tim Chien]

David,

I tend to agree with Alive. The window.open widget frame on lock
screen look like the future proof approach (than implementing
postMessage() to provide a communication channel between System app
and Music app). For hardware controls, we might need to enable the
System app to redirect key events to specific frame (this is just a
rough idea -- not sure it is feasible).

And no, I refuse to estimate engineering effort becuase we have not
even decided how to implement it. No sensible estimation can be done
at this stage. I understand there are many managers that worships
their Gantt chart and hope everything can be determined on the chart
as soon as possible, but that's not how things done. We will probably
have a better idea next week once this thread converges to an
actionable conclusion.


Tim

> For version 1.2, we have a requirement to allow the music player app to be
> controlled from the lockscreen. UX is working on a design, and the
> discussion has also included thoughts about putting something in the status
> bar and allowing the app to be controlled from the notification tray. Or
> maybe including music controls with the volume level if music is playing and
> the user uses the volume buttons.
>
> If you've got thoughts about this, Rob (cc'ed) might be interested in
> hearing them as he works on the design.
>
> The design of this feature is being driven by the Media team, but I imagine
> that a lot of the implementation will fall to the System team, so I'm cc'ing
> Lucas. Tim and Fabrice: I'm cc'ing you two on this message because you might
> be asked to help us estimate the engineering effort involved in implementing
> this.
>
> David
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>

--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)

[Alive Kuo]

FYI, draft diagram of this idea:

Widget on lockscreen,
system app implementation draft:
https://docs.google.com/drawings/d/1Nc3GBNoOCrmwMaeDw26cprVg-WcQBRYDlEVXUQhHTck/edit?usp=sharing

--
Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)

[Vivien]

On 11/06/2013 04:21, Fabrice Desre wrote:
> On 06/10/2013 05:34 PM, David Flanagan wrote:

>> On 6/10/13 4:22 PM, Andreas Gal wrote:
>>> Can this be handled by a simple postMessage protocol between the music
>>> app and the lock screen app?

>> Dietrich prompted me to read this more carefully... I don't know if
>> postMessage() works between apps like this. It sure would be awesome if
>> it did!
> If that works, I'd like to know why we abused the settings API in
> similar situations.

It does not. There is no iframe.contentWindow object for remote iframes.

Also, as a side note, postMessage is the best way to create Gaia only
protocol. This is the things we used in the early days (before oop) in
order to prototype Gaia and it creates dedicated communication channel
between the system app and a dedicated app. It seems to me that this is
going the wrong way for an open platform.

IMHO the right way to implement this would be to have a dedicated Media
API similar to the Camera API. That would let people used their own
music player and would be a real enhancement.

Vivien.

>
> Fabrice

[Vivien]

On 11/06/2013 04:25, Alive Kuo wrote:
> Hi David,
>
> Dominic told me this yesterday.
>
> My quick thought is, utilize current window.open feature, like what we do for attention screen and website bookmark,
>
> var lockscreenWindow = window.open('lockscreen-control.html', title, 'lockscreen');

I like this in theory. In practice the main issue will be that the music
app will have to be started (and so a new process will be created) in
order for the user to start playing music from the lockscreen. So every
time the phone will be turned on, the app needs to be started if it has
been closed previously and it can potentially kill the last thing you
were doing on the phone (like writing a sms before beeing interupt).
Also it means the app would be alive most of the time and as a side
effect the music app will compete with the rest of your apps when you're
listening music and will likely be killed if you start to browse the web.

I like the idea of letting an app control the lockscreen but I'm not
convinced (maybe yet!) that it fits here. I'm not a big fan of adding a
new API for that but a widget system based on process seems painful to
me (this is more or less how works the costcontrol app in the
notification tray but it will create more issues in this case since the
lockscreen is way more often visible).

Does the webapi team has been asked for a solution here?

> And, yes, use postMessage as communication way as parent music app and child lockscreen control window.
>
> To be strict, this needs some further permission specified(at manifest), or we may need to hard code music app's origin/manifest in system app(I don't want this!),
> to avoid any other un-authorized app could open a window on lockscreen.

<3 for not hardcoding anything.

[Alive Kuo]

Vivien <vnic...@mozilla.com> 於 2013/6/11 下午6:01 寫道：

> I like the idea of letting an app control the lockscreen but I'm not
> convinced (maybe yet!) that it fits here. I'm not a big fan of adding a
> new API for that but a widget system based on process seems painful to
> me (this is more or less how works the costcontrol app in the
> notification tray but it will create more issues in this case since the
> lockscreen is way more often visible).

IMO in this idea, the visibility state of lock screen widget is:
1) True if: lockscreen is on and screen is on.
*2) False if: unlocked and current active app isn't music app. So we could kill music if memory is tight.*
3) True if: current active app is music app.(Widget opener)

It's the same situation if we have the Media API you suggested in previous mail.
We still need to consider the app recycle.

Does this make sense? I think I didn't describe my design detail very well so got you misunderstand.

[Alive Kuo]

Vivien <vnic...@mozilla.com> 於 2013/6/11 下午6:01 寫道：

> On 11/06/2013 04:25, Alive Kuo wrote:

> I like the idea of letting an app control the lockscreen but I'm not
> convinced (maybe yet!) that it fits here. I'm not a big fan of adding a
> new API for that but a widget system based on process seems painful to
> me (this is more or less how works the costcontrol app in the
> notification tray but it will create more issues in this case since the
> lockscreen is way more often visible).

About cost control, I have to say, right.
I don't like current implementation of cost control in system app.
It does hardcode an page url of the cost control and embed it in utility tray.

I have thought how to resolve this, but we leak some gecko support here:
A background service or something like that API:
1) App(cost control) register the background service(in the manifest?).
2) Gecko sends (widget-launch) event to system app(after device booting).
3) System app opens the iframe specified in the event in the area it specified.
4) System app manages the widget iframe per the area it is belong to.
For example, if the widget is on utility-tray, all widget iframe's visibility is turned to false when utility tray is pulled up.
The same as lockscreen case.
And system app would "restart" the widget iframe if it's "persistent" type and it's killed. Music on lockscreen should not be persistent once music is closed.

BTW, maybe an new API/permission about widget is in the long run necessary,
if we wants the widget live in home screen and I don't think home screen should have mozBrowser API permission for this purpose.

[Vivien]

On 11/06/2013 12:09, Alive Kuo wrote:
> Vivien <vnic...@mozilla.com> 於 2013/6/11 下午6:01 寫道：
>
>> I like the idea of letting an app control the lockscreen but I'm not
>> convinced (maybe yet!) that it fits here. I'm not a big fan of adding a
>> new API for that but a widget system based on process seems painful to
>> me (this is more or less how works the costcontrol app in the
>> notification tray but it will create more issues in this case since the
>> lockscreen is way more often visible).

> IMO in this idea, the visibility state of lock screen widget is:
> 1) True if: lockscreen is on and screen is on.
> *2) False if: unlocked and current active app isn't music app. So we could kill music if memory is tight.*
> 3) True if: current active app is music app.(Widget opener)

I assume 4) False if: screen is off.


What makes me worried is a sequence of 2-4-1: For example the user is
not listening any music, but he/she wrote an email. He got distracted a
few seconds so the phone goes to sleep, or he has to turn off the phone.
Then the user turns the phone on again to finish the email and the
lockscreen is displayed, which result in starting the music app which
can kill the email app behind.
All those happens even if the user is not listening any music :/

(Also this is without speaking of the difficulties to have the 'widget'
beeing loaded smoothly on the lockscreen).

The API mechamism will let the UI beeing part of the lockscreen and so
one music app will be allow to be opened and controlled by it (could be
a setting like the homescreen / keyboard). The music app won't be opened
if the user is not listening music and the no extra memory consumption
app will be involved.
Maybe a Media API is wrong and a generic API, close too but not system
message, can address this issue. As a side effect it could potentially
let us get rid of the dirty little code that opens the settings in the
notification tray. As well as a way to address wired/bt headset buttons
to a specific app without waking up all the listeners.

Again I really like the idea of letting an application (even a third
party app) takes over a part of the lockscreen to display custom things.
But widgets-like mechanism makes me uncomfortable in a world where
memory is rare. I would prefer a data-store based mechanism where the UI
of the 'widget' is already present into the lockscreen / notification
panel and where third party apps can feed it with their own data. That
would be memory efficient and could offer a wide range of built-in
capabilities.

[Peter Dolanjski]

I believe there are a number of third party solutions for this on iOS (but I believe they require jailbreak). Here's an example:
http://www.youtube.com/watch?v=xr73bqnM9Us

Android has the same in a number of ROMs: http://lifehacker.com/5829904/change-tracks-with-the-volume-buttons-in-android-music-players or in the PowerAMP app: https://play.google.com/store/apps/details?id=com.maxmpz.audioplayer

BlackBerry OS devices (OS 5.0-7.1) have had this as the stock experience for years. (not sure about BlackBerry 10)

----- Original Message -----

From: "Rob MacDonald" <rmacd...@mozilla.com>
To: "Peter Dolanjski" <pdola...@mozilla.com>
Cc: "David Flanagan" <dfla...@mozilla.com>, "Fabrice Desré" <fab...@mozilla.com>, "Tim Chien" <timd...@mozilla.com>, "Lucas Adamski" <lada...@mozilla.com>, mozilla-...@lists.mozilla.org, "Andreas Gal" <andre...@gmail.com>
Sent: Tuesday, 11 June, 2013 2:42:35 AM
Subject: Re: Music player controls on the lockscreen, etc.


Hi Peter…

On 6/10/13 4:22 PM, Andreas Gal wrote:


Can this be handled by a simple postMessage protocol between the music
app and the lock screen app?

Yes, I expect so. And if the lockscreen continues to be part of the
system app, that should be straightforward.

I forgot to mention that we probably also want the music app to be
controllable from bluetooth devices (headsets, car audio systems) and
will want to design a control protocol that works for both cases.



Sent from Mobile.

On Jun 11, 2013, at 8:16, David Flanagan < dfla...@mozilla.com > wrote:

[Peter Dolanjski]

You could certainly make it a user option which is off by default. The reality is that most people will stick with the stock headphones, so they won't have headphone controls (for most phones). Forcing the user to turn on and direct their attention to the screen to switch tracks, for situations where that isn't the easiest option (walking down the street, jogging, driving a car, etc.), doesn't seem like the best experience and can be a user safety issue. I agree that conceptually using the volume buttons for this purpose isn't the best, but they are basically the only buttons that you're pretty much guaranteed to have on all phones.

Just my two cents.

Peter

----- Original Message -----
From: "Matthew R. MacPherson" <mmacp...@mozilla.com>
To: "Peter Dolanjski" <pdola...@mozilla.com>
Cc: "Rob MacDonald" <rmacd...@mozilla.com>, "Andreas Gal" <andre...@gmail.com>, "David Flanagan" <dfla...@mozilla.com>, mozilla-...@lists.mozilla.org, "Fabrice Desré" <fab...@mozilla.com>, "Lucas Adamski" <lada...@mozilla.com>, "Tim Chien" <timd...@mozilla.com>
Sent: Tuesday, 11 June, 2013 9:46:37 AM
Subject: Re: Music player controls on the lockscreen, etc.

Conceptually, hardware buttons don't change and their use should be consistent across the entire device. That's why software keyboards, lockscreen controls, etc are great: they're dynamic. I find iOS's "touch the volume button to take a photo" behaviour really bizarre and surprising.

Using headphone controls for seek is great, but using long-presses for volume for said task seems bizarre and unexpected, with a relatively low increase in usability for those who actually expect and understand such behaviour.

- tofumatt (Sent from mobile)

[Fred Lin]

Hi Alive,

In my knowledge cost control app has a widget on utility tray,
does this diagram use the same flow to show music on lockscreen,
or any new topics worth to be addressed?


regards
--
Fred Lin



----- origin -----
"Alive Kuo" <al...@mozilla.com>

FYI, draft diagram of this idea:

Widget on lockscreen,
system app implementation draft:
https://docs.google.com/drawings/d/1Nc3GBNoOCrmwMaeDw26cprVg-WcQBRYDlEVXUQhHTck/edit?usp=sharing

--
Alive C. Kuo, Front-end Eng., Mozilla Corp. (Taiwan, Taipei)

Alive Kuo <al...@mozilla.com> 於 2013/6/11 上午10:25 寫道：

> Hi David,
>
> Dominic told me this yesterday.
>
> My quick thought is, utilize current window.open feature, like what we do for attention screen and website bookmark,
>
> var lockscreenWindow = window.open('lockscreen-control.html', title, 'lockscreen');
>

> And, yes, use postMessage as communication way as parent music app and child lockscreen control window.
>
> To be strict, this needs some further permission specified(at manifest), or we may need to hard code music app's origin/manifest in system app(I don't want this!),
> to avoid any other un-authorized app could open a window on lockscreen.
>

[Matthew R. MacPherson]

[David Flanagan]

On 6/11/13 4:18 AM, Vivien wrote:
> On 11/06/2013 12:09, Alive Kuo wrote:
>> Vivien <vnic...@mozilla.com> 於 2013/6/11 下午6:01 寫道：
>>
>>> I like the idea of letting an app control the lockscreen but I'm not
>>> convinced (maybe yet!) that it fits here. I'm not a big fan of adding a
>>> new API for that but a widget system based on process seems painful to
>>> me (this is more or less how works the costcontrol app in the
>>> notification tray but it will create more issues in this case since the
>>> lockscreen is way more often visible).
>> IMO in this idea, the visibility state of lock screen widget is:
>> 1) True if: lockscreen is on and screen is on.
>> *2) False if: unlocked and current active app isn't music app. So we could kill music if memory is tight.*
>> 3) True if: current active app is music app.(Widget opener)
> I assume 4) False if: screen is off.
>
>
> What makes me worried is a sequence of 2-4-1: For example the user is
> not listening any music, but he/she wrote an email. He got distracted a
> few seconds so the phone goes to sleep, or he has to turn off the phone.
> Then the user turns the phone on again to finish the email and the
> lockscreen is displayed, which result in starting the music app which
> can kill the email app behind.
> All those happens even if the user is not listening any music :/

My understanding of Alive's proposal is that this would not happen if
the music app was not running. It is the call to window.open() in the
music app that would open up a widget on the lockscreen, and the music
app would control the content of that widget.

It seems like a cool idea, if we want to define a more general widget
capability for our apps.

> (Also this is without speaking of the difficulties to have the 'widget'
> beeing loaded smoothly on the lockscreen).
>
> The API mechamism will let the UI beeing part of the lockscreen and so
> one music app will be allow to be opened and controlled by it (could be
> a setting like the homescreen / keyboard). The music app won't be opened
> if the user is not listening music and the no extra memory consumption
> app will be involved.
> Maybe a Media API is wrong and a generic API, close too but not system
> message, can address this issue. As a side effect it could potentially
> let us get rid of the dirty little code that opens the settings in the
> notification tray. As well as a way to address wired/bt headset buttons
> to a specific app without waking up all the listeners.

I think I like this general approach better, where the player controls
would be part of the lockscreen and communication would be via system
messages or a new API. If the new API is something that would be useful
on the desktop as well to integrate with media player control keys on
the keyboard, then I'd vote for defining a new API.

Separately, on the issue of using long presses on the volume keys to
skip forward and back to the next or previous song, I like the idea, but
it conflicts with the autorepeat behavior we have for those keys. As
discussed, there could be a setting to trade autorepeat for song
control, I suppose. And we could continue to autorepeat on long press if
no music was playing... But the modal difference in behavior might be
weird.

David

[Jan Jongboom]

On a side note: In general I'd like a better way to do IPC between the system app and other applications. A working postMessage like protocol that allows system to talk to open applications would make quite some things a lot easier without having to patch B2G all the time.