Candidates WebAPIs list

[Mounir Lamouri]

Hi,

We've been working with Jonas to try to do an un-exhaustive list of APIs
that we might want to work on a mid-term period:

* App API (i.e. installing/uninstalling apps).
* Internet API (raw TCP/UDP + anonymous XS-XHR)
* Settings API
* Sensor API (proximity/ambient light)
* Resource-lock API (prevent screen from being turned off)
* Screen Orientation API
* Network information API (available networks,
names+signalstrength+crypto+mac+other meta for those networks, both for
wifi and cell)
* Media Storage API
* USB file-reading API
* Music Storage API? (might be merged as Media Storage API)
* Browser API
* Contacts API
* Bluetooth API, if that's not included in Network API
* Time/Clock API
* Idle API
* WebUSB
* Calendar API
* Web Intents or Web Activities

Side thing:
* Permissions Manager is definitely needed but that might not be a
proper WebAPI.

We should probably find owners for those APIs and find a WG to host
them. If you have any recommendations, want to work on something or
think an API is missing or should be removed, please, speak up :)

Cheers,
--
Mounir

[Matthew Phillips]

Device Capabilities API is needed. Old detection techniques are broken
since gecko supports features the device may not.

On Jan 25, 2012 6:32 AM, "Mounir Lamouri" <mou...@lamouri.fr> wrote:

> Hi,
>
> We've been working with Jonas to try to do an un-exhaustive list of APIs
> that we might want to work on a mid-term period:
>
> * App API (i.e. installing/uninstalling apps).
> * Internet API (raw TCP/UDP + anonymous XS-XHR)
> * Settings API
> * Sensor API (proximity/ambient light)
> * Resource-lock API (prevent screen from being turned off)
> * Screen Orientation API
> * Network information API (available networks, names+signalstrength+crypto+

> **mac+other meta for those networks, both for wifi and cell)

> * Media Storage API
> * USB file-reading API
> * Music Storage API? (might be merged as Media Storage API)
> * Browser API
> * Contacts API
> * Bluetooth API, if that's not included in Network API
> * Time/Clock API
> * Idle API
> * WebUSB
> * Calendar API
> * Web Intents or Web Activities
>
> Side thing:
> * Permissions Manager is definitely needed but that might not be a proper
> WebAPI.
>
> We should probably find owners for those APIs and find a WG to host them.
> If you have any recommendations, want to work on something or think an API
> is missing or should be removed, please, speak up :)
>
> Cheers,
> --
> Mounir

> ______________________________**_________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-webapi<https://lists.mozilla.org/listinfo/dev-webapi>
>

[Vivien]

On 25/01/2012 12:31, Mounir Lamouri wrote:
> Hi,
>
> We've been working with Jonas to try to do an un-exhaustive list of
> APIs that we might want to work on a mid-term period:
>
> * App API (i.e. installing/uninstalling apps).
> * Internet API (raw TCP/UDP + anonymous XS-XHR)
> * Settings API
> * Sensor API (proximity/ambient light)
> * Resource-lock API (prevent screen from being turned off)
> * Screen Orientation API
> * Network information API (available networks,

> names+signalstrength+crypto+mac+other meta for those networks, both

> for wifi and cell)
> * Media Storage API
> * USB file-reading API
> * Music Storage API? (might be merged as Media Storage API)
> * Browser API
> * Contacts API
> * Bluetooth API, if that's not included in Network API
> * Time/Clock API
> * Idle API
> * WebUSB
> * Calendar API
> * Web Intents or Web Activities
>

* Keyboard/IME API
* Suggestions API

[Mounir Lamouri]

On 01/25/2012 12:47 PM, Matthew Phillips wrote:
> Device Capabilities API is needed. Old detection techniques are broken
> since gecko supports features the device may not.

Indeed. It's not 100% we are going to use that but that's clearly
something that is worth being discussed. For example, it might impact
what Settings API will look like.

--
Mounir

[Mounir Lamouri]

On 01/25/2012 12:57 PM, Vivien wrote:
> * Keyboard/IME API
> * Suggestions API

Could you say what each API would do in two lines?
Should we add a Spellchecker API?

--
Mounir

[Vivien]

* Keyboard/IME:
The goal (at least for Gaia) is to be able to build a keyboard in HTML
that can generate key and composition events onto the browser. It should
also exists some events to know when to show/hide the ime as well as
some information about the currently focused area. Like the type, if
this is an <input type="tel"> for example. That's all we need for now
but I'm not sure this cover all the use cases.

There is a proposal for building an IME from a webpage at
http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html but it seems
over complicated and it's focused on drawing letters on canvas (from
what I've understood).


* Suggestions API
That's just another name for the spellcheck API.
This is well described by the thread at
http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/22d2747a81af066a/927e58625c6b4741?q=spellchecking&lnk=ol&

[N.V. Balaji]

In the context of Mozilla joinig W3C DAP, Are you planning eventually to
get these APIs into W3C DAP?

Thanks
- Balaji N V

On Wed, Jan 25, 2012 at 5:01 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

> Hi,
>
> We've been working with Jonas to try to do an un-exhaustive list of APIs
> that we might want to work on a mid-term period:
>
> * App API (i.e. installing/uninstalling apps).
> * Internet API (raw TCP/UDP + anonymous XS-XHR)
> * Settings API
> * Sensor API (proximity/ambient light)
> * Resource-lock API (prevent screen from being turned off)
> * Screen Orientation API
> * Network information API (available networks, names+signalstrength+crypto+

> **mac+other meta for those networks, both for wifi and cell)

> * Media Storage API
> * USB file-reading API
> * Music Storage API? (might be merged as Media Storage API)
> * Browser API
> * Contacts API
> * Bluetooth API, if that's not included in Network API
> * Time/Clock API
> * Idle API
> * WebUSB
> * Calendar API
> * Web Intents or Web Activities
>

[Mounir Lamouri]

On 01/25/2012 01:28 PM, N.V. Balaji wrote:
> In the context of Mozilla joinig W3C DAP, Are you planning eventually to
> get these APIs into W3C DAP?

We are working on it. But AFAIK, the DAP charter is quite restrictive so
it might require a re-charter. I believe I can safely say that this is
definitely a goal for us.

--
Mounir

[N.V. Balaji]

On Wed, Jan 25, 2012 at 5:01 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

> Hi,
>
> We've been working with Jonas to try to do an un-exhaustive list of APIs
> that we might want to work on a mid-term period:
>

> * App API (i.e. installing/uninstalling apps).
>

I am not sure what exactly is planned as a part of this API set. However
this API set may be high risk one in terms of security as it has the
potential to expose all installed apps.

* Internet API (raw TCP/UDP + anonymous XS-XHR)

> * Settings API
> * Sensor API (proximity/ambient light)
>

W3C has some sensor API. Jose owns it. This could be re-used

> * Resource-lock API (prevent screen from being turned off)
> * Screen Orientation API
>

Are you planning to have some events in lines of window.*onorientationchange
*

[Robin Berjon]

On Jan 25, 2012, at 12:57 , Vivien wrote:
> * Keyboard/IME API

The WebApps WG is considering an IME API, but there was push back in the group to this proposal. If you're interested, I *strongly* recommend that you make that WG aware of your needs, lest it be dropped.

--
Robin Berjon - http://berjon.com/ - @robinberjon

[Vivien]

On 25/01/2012 13:50, N.V. Balaji wrote:
> On Wed, Jan 25, 2012 at 5:01 PM, Mounir Lamouri<mou...@lamouri.fr> wrote:
>
>> Hi,
>>
>> We've been working with Jonas to try to do an un-exhaustive list of APIs
>> that we might want to work on a mid-term period:
>>
>> * App API (i.e. installing/uninstalling apps).
>>
> I am not sure what exactly is planned as a part of this API set. However
> this API set may be high risk one in terms of security as it has the
> potential to expose all installed apps.

This is likely
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/apps/nsIDOMApplicationRegistry.idl

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

[Robin Berjon]

On Jan 25, 2012, at 13:28 , N.V. Balaji wrote:
> In the context of Mozilla joinig W3C DAP, Are you planning eventually to
> get these APIs into W3C DAP?

For those that are chartered in DAP, the group will certainly welcome inputs from Mozilla. For those that aren't we need to figure out a home.

[Robert Kaiser]

Mounir Lamouri schrieb:
> * USB file-reading API
> * WebUSB

Don't those relate closely, or is the former more generic file access
and actually not bound that much to USB?
I don't know details of what you're discussing, this just made me wonder
as an observer.

Robert Kaiser

[Jonas Sicking]

On Wed, Jan 25, 2012 at 7:04 AM, Robert Kaiser <ka...@kairo.at> wrote:
> Mounir Lamouri schrieb:
>>
>> * USB file-reading API

This is intended to be an API for reading files from USB-keys, memory
cards and USB drives. I.e. from a USB perspective it's a pretty
high-level API since it'll only allow communicating with file systems
on block devices. No USB cameras or nerf guns.

A very nice thing about this API is that the security model is very
simple. You just can't cause that much harm with this API.

>> * WebUSB

This is low-level USB access to anything that you can plug in to a USB port.

A big problem with this API is the security model since we have no
idea what a given USB device will do and what the security/privacy
implications are of accessing it. Hence it's likely that access to
this API will be fairly restricted.

/ Jonas

[Chris Jones]

----- Original Message -----
> From: "N.V. Balaji" <nvba...@gmail.com>
> To: "Mounir Lamouri" <mou...@lamouri.fr>
> Cc: dev-w...@lists.mozilla.org
> Sent: Wednesday, January 25, 2012 4:50:38 AM
> Subject: Re: Candidates WebAPIs list
>
> On Wed, Jan 25, 2012 at 5:01 PM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
>
> > * Settings API
> > * Sensor API (proximity/ambient light)
> >
>
> W3C has some sensor API. Jose owns it. This could be re-used
>

We've been in communication with Jose Manuel and are planning on implementing a derivative of that API. See https://bugzilla.mozilla.org/show_bug.cgi?id=697361 .

Cheers,
Chris

[Chris Jones]

----- Original Message -----
> From: "Jonas Sicking" <jo...@sicking.cc>
> To: "Robert Kaiser" <ka...@kairo.at>
> Cc: mozilla-d...@lists.mozilla.org
> Sent: Wednesday, January 25, 2012 4:16:52 PM
> Subject: Re: Candidates WebAPIs list
>

> On Wed, Jan 25, 2012 at 7:04 AM, Robert Kaiser <ka...@kairo.at>
> wrote:
> > Mounir Lamouri schrieb:
> >>
> >> * USB file-reading API
>
> This is intended to be an API for reading files from USB-keys, memory
> cards and USB drives. I.e. from a USB perspective it's a pretty
> high-level API since it'll only allow communicating with file systems
> on block devices. No USB cameras or nerf guns.
>

How is this different than a file system API? What's USB specific? Is it, "the file system API, but only for pluggable drives"? What about SD cards etc.?

Cheers,
Chris

[Jonas Sicking]

The intent is that it'll be significantly simpler than the FileSystem
API. I've started sketching at it in the "MediaStorage API" thread.

> What about SD cards etc.?

I include that in "memory cards", so that's intended to be covered by this API.

/ Jonas

[Chris Jones]

Gotcha. So this isn't really a distinct spec/API.

Cheers,
Chris

[Mounir Lamouri]

On 01/26/2012 07:59 AM, Chris Jones wrote:
>>> * Settings API
>>> * Sensor API (proximity/ambient light)
>>>
>>
>> W3C has some sensor API. Jose owns it. This could be re-used
>>
>
> We've been in communication with Jose Manuel and are planning on implementing a derivative of that API. See https://bugzilla.mozilla.org/show_bug.cgi?id=697361 .

I think it would be interesting to discuss the API here or in DAP
mailing list if we want to change it compared to the current spec.

--
Mounir

[Robin Berjon]

I think it'd be interesting to discuss it in DAP, mostly I'd want to know who's interested in implementing it and amongst those what their feedback is.

[Mounir Lamouri]

On 01/25/2012 01:21 PM, Vivien wrote:
> * Keyboard/IME:
> The goal (at least for Gaia) is to be able to build a keyboard in HTML
> that can generate key and composition events onto the browser. It should
> also exists some events to know when to show/hide the ime as well as
> some information about the currently focused area. Like the type, if
> this is an <input type="tel"> for example. That's all we need for now
> but I'm not sure this cover all the use cases.

So, we need to know what kind of input is focused but isn't that doable
with: document.activeElement?
Knowing when to show or hide the keyboard, isn't that doable
proagramaticaly? I mean, we can imagine that a script is listening to
what is happening in a webapp and show the keyboard when needed?
We definitely need a way to generate trusted events though.

> There is a proposal for building an IME from a webpage at
> http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html but it seems
> over complicated and it's focused on drawing letters on canvas (from
> what I've understood).

I don't think this specification solves our use case. In which WG is that?

> * Suggestions API
> That's just another name for the spellcheck API.
> This is well described by the thread at
> http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/22d2747a81af066a/927e58625c6b4741?q=spellchecking&lnk=ol&

IIRC, the only issue that still applies with that API is that spellcheck
and suggestions are clearly not the same thing: suggestions should
propose words based on what and how I typed something while spellcheck
should assume I might have mispelled the word and will try to propose a
correction. Implementing suggestions like spellcheck would be a mistake.
That issue was raised by Justin Lebar in the thread you mentioned but no
one replied IIRC.

--
Mounir

[Mounir Lamouri]

On 01/25/2012 01:50 PM, N.V. Balaji wrote:
> I am not sure what exactly is planned as a part of this API set. However
> this API set may be high risk one in terms of security as it has the
> potential to expose all installed apps.

This is going to be a privileged app.

>> * Screen Orientation API
>>
>
> Are you planning to have some events in lines of window.*onorientationchange

This will live in window.screen.

--
Mounir

[Mounir Lamouri]

On 01/25/2012 04:04 PM, Robert Kaiser wrote:
> Mounir Lamouri schrieb:
>> * USB file-reading API

>> * WebUSB
>
> Don't those relate closely, or is the former more generic file access
> and actually not bound that much to USB?
> I don't know details of what you're discussing, this just made me wonder
> as an observer.

WebUSB is an API to access USB devices.
USB file-reading API is an API to be able to read the device files from
another device trough USB. IIRC, the idea is to be able to use the
device as a regular storage media. I don't know the details for that though.

--
Mounir

[Vivien]

On 26/01/2012 16:15, Mounir Lamouri wrote:
> On 01/25/2012 01:21 PM, Vivien wrote:
>> * Keyboard/IME:
>> The goal (at least for Gaia) is to be able to build a keyboard in HTML
>> that can generate key and composition events onto the browser. It should
>> also exists some events to know when to show/hide the ime as well as
>> some information about the currently focused area. Like the type, if
>> this is an<input type="tel"> for example. That's all we need for now
>> but I'm not sure this cover all the use cases.
> So, we need to know what kind of input is focused but isn't that doable
> with: document.activeElement?
> Knowing when to show or hide the keyboard, isn't that doable
> proagramaticaly? I mean, we can imagine that a script is listening to
> what is happening in a webapp and show the keyboard when needed?
> We definitely need a way to generate trusted events though.

This could potentially make it but the assuming the script is not loaded
by the app itself the keyboard application has to track every iframes,
and do some polling over document.activeElement.
I'm also not sure we can identify the window that is currently active
from JS?

Another aspect of this bug is related to the web browser. If we want the
keyboard to be showned only when there is a user action, tracking the
focus is not enough since web site can do element.focus();. We need a
low level support for that.

And generating trusted events is not enough since you don't really know
which window has the focus. In gecko you have to go thought
nsIDOMWindowUtils.sendKeyEvent (chrome-only) that dispatch the event at
the widget level.

>> There is a proposal for building an IME from a webpage at
>> http://dvcs.w3.org/hg/ime-api/raw-file/tip/Overview.html but it seems
>> over complicated and it's focused on drawing letters on canvas (from
>> what I've understood).
> I don't think this specification solves our use case. In which WG is that?

I don't think it solve our use case too. I was just mentionning it
because it exists :)

>> * Suggestions API
>> That's just another name for the spellcheck API.
>> This is well described by the thread at
>> http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/22d2747a81af066a/927e58625c6b4741?q=spellchecking&lnk=ol&
> IIRC, the only issue that still applies with that API is that spellcheck
> and suggestions are clearly not the same thing: suggestions should
> propose words based on what and how I typed something while spellcheck
> should assume I might have mispelled the word and will try to propose a
> correction. Implementing suggestions like spellcheck would be a mistake.
> That issue was raised by Justin Lebar in the thread you mentioned but no
> one replied IIRC.

I have no strong opinions on that so 2 APIs works for me.

[Jonas Sicking]

On Thu, Jan 26, 2012 at 12:55 AM, Chris Jones <cjo...@mozilla.com> wrote:
> ----- Original Message -----
>> From: "Jonas Sicking" <jo...@sicking.cc>
>> To: "Chris Jones" <cjo...@mozilla.com>
>> Cc: mozilla-d...@lists.mozilla.org, "Robert Kaiser" <ka...@kairo.at>
>> Sent: Thursday, January 26, 2012 12:23:50 AM
>> Subject: Re: Candidates WebAPIs list
>>
>> On Wed, Jan 25, 2012 at 11:01 PM, Chris Jones <cjo...@mozilla.com>
>> wrote:
>> > ----- Original Message -----
>> >> From: "Jonas Sicking" <jo...@sicking.cc>
>> >> To: "Robert Kaiser" <ka...@kairo.at>
>> >> Cc: mozilla-d...@lists.mozilla.org
>> >> Sent: Wednesday, January 25, 2012 4:16:52 PM
>> >> Subject: Re: Candidates WebAPIs list
>> >>
>> >> On Wed, Jan 25, 2012 at 7:04 AM, Robert Kaiser <ka...@kairo.at>

>> >> wrote:
>> >> > Mounir Lamouri schrieb:
>> >> >>
>> >> >> * USB file-reading API
>> >>

>> >> This is intended to be an API for reading files from USB-keys,
>> >> memory
>> >> cards and USB drives. I.e. from a USB perspective it's a pretty
>> >> high-level API since it'll only allow communicating with file
>> >> systems
>> >> on block devices. No USB cameras or nerf guns.
>> >>
>> >
>> > How is this different than a file system API?  What's USB specific?
>> >  Is it, "the file system API, but only for pluggable drives"?
>>
>> The intent is that it'll be significantly simpler than the FileSystem
>> API. I've started sketching at it in the "MediaStorage API" thread.
>>
>
> Gotcha.  So this isn't really a distinct spec/API.

I had originally imagined it to be, but on second thought I think it
can be merged with the MediaStorage API. I think we'll know better as
we nail down the API.

/ Jonas

[Mounir Lamouri]

On 01/26/2012 04:41 PM, Vivien wrote:
> On 26/01/2012 16:15, Mounir Lamouri wrote:
>> On 01/25/2012 01:21 PM, Vivien wrote:
>>> * Keyboard/IME:
>>> The goal (at least for Gaia) is to be able to build a keyboard in HTML
>>> that can generate key and composition events onto the browser. It should
>>> also exists some events to know when to show/hide the ime as well as
>>> some information about the currently focused area. Like the type, if
>>> this is an<input type="tel"> for example. That's all we need for now
>>> but I'm not sure this cover all the use cases.
>> So, we need to know what kind of input is focused but isn't that doable
>> with: document.activeElement?
>> Knowing when to show or hide the keyboard, isn't that doable
>> proagramaticaly? I mean, we can imagine that a script is listening to
>> what is happening in a webapp and show the keyboard when needed?
>> We definitely need a way to generate trusted events though.
>
> This could potentially make it but the assuming the script is not loaded
> by the app itself the keyboard application has to track every iframes,
> and do some polling over document.activeElement.
> I'm also not sure we can identify the window that is currently active
> from JS?

You can detect if an iframe has the focus, see:
data:text/html,<iframe src="data:text/html,<input>"></iframe><iframe
src="data:text/html,<input>"></iframe><div></div><script>setInterval(function()
{ document.getElementsByTagName('div')[0].innerHTML += "active: " +
document.activeElement + "<br>"; }, 1000);</script>

> Another aspect of this bug is related to the web browser. If we want the
> keyboard to be showned only when there is a user action, tracking the
> focus is not enough since web site can do element.focus();. We need a
> low level support for that.

We should think about that. Between engineers but also with UX people: I
guess we mostly want to prevent abuse like .focus()/.blur() being called
continuously. Though, is that less annoying on the desktop?
Personally, I would prefer to have pages like google.com having the
focus on the input field when loaded.

> And generating trusted events is not enough since you don't really know
> which window has the focus. In gecko you have to go thought
> nsIDOMWindowUtils.sendKeyEvent (chrome-only) that dispatch the event at
> the widget level.

Should we expose this in an API? Or allow an event to be set trusted by
the app if some permissions are granted? I wonder what Ehsan and Olli
think about that.

--
Mounir

[Mounir Lamouri]

On 01/26/2012 04:41 PM, Vivien wrote:

>>> * Suggestions API
>>> That's just another name for the spellcheck API.
>>> This is well described by the thread at
>>> http://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/22d2747a81af066a/927e58625c6b4741?q=spellchecking&lnk=ol&
>>>
>> IIRC, the only issue that still applies with that API is that spellcheck
>> and suggestions are clearly not the same thing: suggestions should
>> propose words based on what and how I typed something while spellcheck
>> should assume I might have mispelled the word and will try to propose a
>> correction. Implementing suggestions like spellcheck would be a mistake.
>> That issue was raised by Justin Lebar in the thread you mentioned but no
>> one replied IIRC.
>
> I have no strong opinions on that so 2 APIs works for me.

We had a talk with Vivien today and he agrees that the Spellcheck API
will not solve what he wants to do. Basically, suggestions in a virtual
keyboard has nothing to do with spellchecking.
For example, try to press to type "Wz" on an Android virtual keyboard.
The first result I have on my phone is "Ex" because W is close to E and
z is close to x. This has nothing to do with spellchecking.

The conclusion of our discussion is that the logic of suggestion should
be part of the virtual keyboard application because the keys disposition
is required, the exact position of touch might be needed and the input
method too (pressing keys VS drawing lines for example).

Then, the only missing part is having the list of available words. The
keyboard can access to some information in the phone (like Contacts
name) but should mostly have access to the dictionary which is currently
not doable. Thus, we should add an API for that.

Basically, this API should allow the developers to:
- add an entry in the personal dictionnary;
- remove an entry from the personal dictionnary;
- read entries in the dictionnary;
- be informed when the dictionnary changes;
- knows if a word is part of the personal dictionnary.

A quick draft of the API gives us:

interface DictionaryNavigator {
Dictionary getDictionary(in DOMString lang);
};

interface Navigator implements DictionaryNavigator;

interface Dictionary {
// request.result = whether the word has been adedd.
DOMRequest add(in DOMString word);
// request.result = whether the word has been removed.
DOMRequest remove(in DOMString word);

// request.result = DOMString[] with all words from the dictionary.
DOMRequest read();
// request.result = DOMString[] with all words from the personal
dictionary.
DOMRequest readPersonal();

// 'change' event can be sent to the Dictionnary object.
// It is using DictionaryChange interface.
Function onchange;
};

[Constructor(DOMString type, optional DictionaryEventInit dicEventInitDict)]
interface DictionaryChange : Event {
readonly attribute DOMString entry;
readonly attribute DOMString operation;
// type can be "added" or "removed".
}

dictionary DictionaryEventInit : EventInit {
DOMString entry;
DOMString operation;
};

Cheers,
--
Mounir

[Ehsan Akhgari]

On Mon, Jan 30, 2012 at 1:30 PM, Olli Pettay <Olli....@helsinki.fi>wrote:

> And generating trusted events is not enough since you don't really know
>>> which window has the focus. In gecko you have to go thought
>>> nsIDOMWindowUtils.sendKeyEvent (chrome-only) that dispatch the event at
>>> the widget level.
>>>
>>
>> Should we expose this in an API? Or allow an event to be set trusted by
>> the app if some permissions are granted? I wonder what Ehsan and Olli
>> think about that.
>>
>
>

I'm lacking some context here, I think. Why do we need the event to be
trusted if it's coming from a web page?

--
Ehsan
<http://ehsanakhgari.org/>

[Mounir Lamouri]

B2G needs a Virtual Keyboard and it will be written in HTML. It might
ask for special privileges though.

--
Mounir

[Olli Pettay]

CCing Masayuki

On 01/30/2012 08:26 PM, Mounir Lamouri wrote:
> On 01/26/2012 04:41 PM, Vivien wrote:

>> And generating trusted events is not enough since you don't really know
>> which window has the focus. In gecko you have to go thought
>> nsIDOMWindowUtils.sendKeyEvent (chrome-only) that dispatch the event at
>> the widget level.
>
> Should we expose this in an API? Or allow an event to be set trusted by
> the app if some permissions are granted? I wonder what Ehsan and Olli
> think about that.
>

> --
> Mounir

[Ehsan Akhgari]

As long as we make sure that regular web content cannot raise trusted
events, it should be fine.

--
Ehsan
<http://ehsanakhgari.org/>

On Mon, Jan 30, 2012 at 7:15 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:

> On 01/30/2012 10:34 PM, Ehsan Akhgari wrote:
> > On Mon, Jan 30, 2012 at 1:30 PM, Olli Pettay <Olli....@helsinki.fi
> >wrote:
> >

> >> And generating trusted events is not enough since you don't really know
> >>>> which window has the focus. In gecko you have to go thought
> >>>> nsIDOMWindowUtils.sendKeyEvent (chrome-only) that dispatch the event
> at
> >>>> the widget level.
> >>>>
> >>>
> >>> Should we expose this in an API? Or allow an event to be set trusted by
> >>> the app if some permissions are granted? I wonder what Ehsan and Olli
> >>> think about that.
> >>>
> >>
> >>

[Mounir Lamouri]

Would anyone be interested in drafting the API?

--
Mounir