Should the virtual keyboard be part of Gaia or part of Gecko?

[David Flanagan]

Currently the B2G virtual keyboard is implemented as part of the Gaia
homescreen, and uses some baroque hacks to go back and forth between
content and chrome (which it needs to be able to do to generate key
events in cross-origin app windows). Supporting the keyboard seems to
make the homescreen architecture quite a bit more complicated than it
would otherwise need to be.

It seems to me that a virtual keyboard is an OS-level service, and that
it should properly be part of Gecko (where it might be of use in Fennec,
or even on the desktop for entry of accented characters, for example).

If, on the other hand, the consensus is that the keyboard should be part
of Gaia, then who is working on the mozKeyboard API that will be needed
to make it work cleanly? There's nothing in the WebAPI wiki about this.

Is this an architectural decision that has already been made?

David

[Vivien]

On 06/03/2012 09:26, David Flanagan wrote:
> Currently the B2G virtual keyboard is implemented as part of the Gaia
> homescreen, and uses some baroque hacks to go back and forth between
> content and chrome (which it needs to be able to do to generate key
> events in cross-origin app windows). Supporting the keyboard seems to
> make the homescreen architecture quite a bit more complicated than it
> would otherwise need to be.
>

The keyboard should be pretty much self contained. The only place it
should collapse with the window manager is when a window needs to be
resized to show/hide the keyboard.

>
> If, on the other hand, the consensus is that the keyboard should be
> part of Gaia, then who is working on the mozKeyboard API that will be
> needed to make it work cleanly? There's nothing in the WebAPI wiki
> about this.
>

See
https://groups.google.com/forum/#!msg/mozilla.dev.webapi/Vkn7EIUUTRM/WaSpIHL7e1wJ

Vivien.

[Timothy Chien]

The idea for keyboard and IME is to eventually make each keyboard
self-contain, managed as mozbrowser iframes in homescreen, and accept
3rd party keyboard apps.

Keyboards with Latin alphabets is pretty standard, and there is no much
difference for extra features (auto-completion, correction, etc.). But
for Asian IMEs, there is a sizable community and market which companies
develops new IMEs or improved conversion engine. There is an absolute
necessary to support this community and market.

This is how OSes works _today_, with the exception of iOS. For example,
I can go to Chewing project website and download chewing-win32.exe,
double click the installer, and the free software IME will integrated
with the Windows OS and available in the Language Bar to be switched for
all text input fields.

Even for the case of iOS, people sometimes jailbreak their iPhone just
because they want to install a customized IME or keyboard.

Moving the keyboard to chrome/Gecko will deny these abilities. It also
doesn't make sense for Gecko to draw that big part of UI because the
goal of B2G is to deliver a platform run by web apps entirely.

MozKeyboard is a temporary API for us to make keyboard on homescreen
right now. A complete but yet to discussed solution for the permission
would be the IME API proposed here [1].

[1] http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html

Just because we are hacking in chrome doesn't necessary means the entire
function need to live in chrome; if so, we should move entire homescreen
to chrome and run web apps as Tabs in Firefox; our job will be much much
easier with this, but then the project would be "Boot to Firefox"
instead of "Boot to the Web".

I agree that homescreen is a bit messy if it would also need to deal
with keyboard states, and it will be more so as we move on and develop
the features mentioned above. Still, that's what need to be some for a
new OS. We actually need your Javascript talent to sort this out, David.

I hope I'd cover the whole picture and the vision of the keyboard/IME here.


Tim

[Ben Francis]

I agree with Tim. And if there's anything missing to make keyboard apps
possible we need to add it into the platform.

Ben

On Wed, Mar 7, 2012 at 3:11 PM, Timothy Chien <timd...@gmail.com> wrote:

> The idea for keyboard and IME is to eventually make each keyboard
> self-contain, managed as mozbrowser iframes in homescreen, and accept 3rd
> party keyboard apps.
>
> Keyboards with Latin alphabets is pretty standard, and there is no much
> difference for extra features (auto-completion, correction, etc.). But for
> Asian IMEs, there is a sizable community and market which companies
> develops new IMEs or improved conversion engine. There is an absolute
> necessary to support this community and market.
>
> This is how OSes works _today_, with the exception of iOS. For example, I
> can go to Chewing project website and download chewing-win32.exe, double
> click the installer, and the free software IME will integrated with the
> Windows OS and available in the Language Bar to be switched for all text
> input fields.
>
> Even for the case of iOS, people sometimes jailbreak their iPhone just
> because they want to install a customized IME or keyboard.
>
> Moving the keyboard to chrome/Gecko will deny these abilities. It also
> doesn't make sense for Gecko to draw that big part of UI because the goal
> of B2G is to deliver a platform run by web apps entirely.
>
> MozKeyboard is a temporary API for us to make keyboard on homescreen right
> now. A complete but yet to discussed solution for the permission would be
> the IME API proposed here [1].
>

> [1] http://dvcs.w3.org/hg/ime-api/**raw-file/default/use-cases/**
> Overview.html<http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html>

>
> Just because we are hacking in chrome doesn't necessary means the entire
> function need to live in chrome; if so, we should move entire homescreen to
> chrome and run web apps as Tabs in Firefox; our job will be much much
> easier with this, but then the project would be "Boot to Firefox" instead
> of "Boot to the Web".
>
> I agree that homescreen is a bit messy if it would also need to deal with
> keyboard states, and it will be more so as we move on and develop the
> features mentioned above. Still, that's what need to be some for a new OS.
> We actually need your Javascript talent to sort this out, David.
>
> I hope I'd cover the whole picture and the vision of the keyboard/IME here.
>
>
> Tim
>
>
>
> On 3/6/12 6:59 PM, Vivien wrote:
>

>> https://groups.google.com/**forum/#!msg/mozilla.dev.**webapi/Vkn7EIUUTRM/
>> **WaSpIHL7e1wJ<https://groups.google.com/forum/#%21msg/mozilla.dev.webapi/Vkn7EIUUTRM/WaSpIHL7e1wJ>
>>
>>
>> Vivien.
>>
> ______________________________**_________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-b2g<https://lists.mozilla.org/listinfo/dev-b2g>
>



--
Ben Francis
http://tola.me.uk

[David Flanagan]

On 3/7/12 7:11 AM, Timothy Chien wrote:
> The idea for keyboard and IME is to eventually make each keyboard
> self-contain, managed as mozbrowser iframes in homescreen, and accept
> 3rd party keyboard apps.
>
> Keyboards with Latin alphabets is pretty standard, and there is no
> much difference for extra features (auto-completion, correction,
> etc.). But for Asian IMEs, there is a sizable community and market
> which companies develops new IMEs or improved conversion engine. There
> is an absolute necessary to support this community and market.
>
> This is how OSes works _today_, with the exception of iOS. For
> example, I can go to Chewing project website and download
> chewing-win32.exe, double click the installer, and the free software
> IME will integrated with the Windows OS and available in the Language
> Bar to be switched for all text input fields.
>
> Even for the case of iOS, people sometimes jailbreak their iPhone just
> because they want to install a customized IME or keyboard.

I can't use an Asian IME myself, but I think I understand the issues.
And I agree that installable IMEs are an absolute requirement.

>
> Moving the keyboard to chrome/Gecko will deny these abilities. It also
> doesn't make sense for Gecko to draw that big part of UI because the
> goal of B2G is to deliver a platform run by web apps entirely.
>

Firefox has add-ons. Why can't B2G have something similar? The way
you've described chewing-win32.exe, it sounds to me as if it is more
like a device driver than an end-user application. If Gecko is the OS,
then chrome add ons would be the device drivers.

I want installable IMEs and installable custom homescreens. But I don't
think that those things have to be open web apps. (And, in fact,
they're going to be using so many custom proposed but not yet
standardized apis, that calling them "open" will be a bit of a stretch.)

I gather that the ship has already sailed on this though, so I'll try to
shut up about it...

> MozKeyboard is a temporary API for us to make keyboard on homescreen
> right now. A complete but yet to discussed solution for the permission
> would be the IME API proposed here [1].
>
> [1]

> http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html
>
Thank you. I was unaware of that work. Should we have a link to this
from the WebAPI wiki even though it seems to be a Google proposal?

> Just because we are hacking in chrome doesn't necessary means the
> entire function need to live in chrome; if so, we should move entire
> homescreen to chrome and run web apps as Tabs in Firefox; our job will
> be much much easier with this, but then the project would be "Boot to
> Firefox" instead of "Boot to the Web".
>

I think of the homescreen as the equivalent of Firefox chrome, which is
why I think it should be written in chrome. But I think I promised
above to stop talking about that!

> I agree that homescreen is a bit messy if it would also need to deal
> with keyboard states, and it will be more so as we move on and develop
> the features mentioned above. Still, that's what need to be some for a
> new OS. We actually need your Javascript talent to sort this out, David.
>
> I hope I'd cover the whole picture and the vision of the keyboard/IME
> here.
>
>
> Tim
>
>
> On 3/6/12 6:59 PM, Vivien wrote:

[Mounir Lamouri]

On 03/07/2012 07:43 PM, David Flanagan wrote:
>> MozKeyboard is a temporary API for us to make keyboard on homescreen
>> right now. A complete but yet to discussed solution for the permission
>> would be the IME API proposed here [1].
>>
>> [1]
>> http://dvcs.w3.org/hg/ime-api/raw-file/default/use-cases/Overview.html
>>
> Thank you. I was unaware of that work. Should we have a link to this
> from the WebAPI wiki even though it seems to be a Google proposal?

I'm not sure how this proposal is going to fit with what we want.
I spoke with Vivien about an API for the virtual keyboard and we came
out with something quite different (you should find a thread about that
in dev-webapi archives).

--
Mounir

[Timothy Chien]

I am not sure either actually. The use cases does cover an Javascript
IME but I don't understand how it would work after studying it.

>
> --
> Mounir

[lkcl luke]

On Tue, Mar 6, 2012 at 8:26 AM, David Flanagan <dfla...@mozilla.com> wrote:
> Currently the B2G virtual keyboard is implemented as part of the Gaia
> homescreen, and uses some baroque hacks to go back and forth between content
> and chrome (which it needs to be able to do to generate key events in
> cross-origin app windows).  Supporting the keyboard seems to make the
> homescreen architecture quite a bit more complicated than it would otherwise
> need to be.
>

> It seems to me that a virtual keyboard is an OS-level service,

... and thus, the work of OS-level services should be emulated.
actually, that's not quite right: virtual keyboard is a
*window-managed* service.

thus as do others i concur with tim's assessment, because the
secure/isolated-frames system which is being worked on is the
corresponding direct equivalent of "window management" in B2G which
you would find in say X-Windows.

to build an actual implementation of a virtual keyboard hard-coded
into the B2G source code as c++ would be a mistake. however if you
build in the concept of event passing such that *any* input device can
be created - using any programming language - now you're onto a
winner.

this project is basically all about turning B2G into a Window Manager.

it's basically an implementation of the concept of "Active Desktop"
which was so scorned and rejected when microsoft first created it.

l.

[lkcl luke]

On Tue, Mar 6, 2012 at 8:26 AM, David Flanagan <dfla...@mozilla.com> wrote:

> If, on the other hand, the consensus is that the keyboard should be part of
> Gaia, then who is working on the mozKeyboard API that will be needed to make
> it work cleanly?

in the secure-frames-based stuff that tim refers to, you do not need
to have a keyboard API. all you need to be able to do is create key
events in one frame / context (the one in which the on-screen keyboard
is displayed) and to be able to fire those events at its target frame
(the application).

the concept of creating events and firing them is not new: we use it
in pyjamas to cater for bugs in various web browser implementations,
for example, to create and fire events that *should* have happened but
did not. selenium records *and* re-plays events, which is the whole
fundamental reason for selenium's existence.

the bit about firing events across secure-frame boundaries however
*is* new. you're really going to have to think hard about that. i
would recommend that the design of SE/Linux be investigated here (and
the FLASK security model analysed).

l.

[David Flanagan]

On 3/8/12 6:20 PM, lkcl luke wrote:
> On Tue, Mar 6, 2012 at 8:26 AM, David Flanagan<dfla...@mozilla.com> wrote:

>> Currently the B2G virtual keyboard is implemented as part of the Gaia
>> homescreen, and uses some baroque hacks to go back and forth between content
>> and chrome (which it needs to be able to do to generate key events in
>> cross-origin app windows). Supporting the keyboard seems to make the
>> homescreen architecture quite a bit more complicated than it would otherwise
>> need to be.
>>
>> It seems to me that a virtual keyboard is an OS-level service,
> ... and thus, the work of OS-level services should be emulated.
> actually, that's not quite right: virtual keyboard is a
> *window-managed* service.
>
> thus as do others i concur with tim's assessment, because the
> secure/isolated-frames system which is being worked on is the
> corresponding direct equivalent of "window management" in B2G which
> you would find in say X-Windows.

I don't see the point in keeping these low-level things in content
rather than chrome unless we can get the APIs standardized. And if the
only use case for the API is "we need it for B2G", then I have my doubts
about our ability to get it standardized, especially where the API isn't
a device API like the battery or vibration API, but strikes at the heart
of DOM and HTML.

> to build an actual implementation of a virtual keyboard hard-coded
> into the B2G source code as c++ would be a mistake.

I'd keep the keyboard in JavaScript, but as part of chrome rather than
content.

Its moot, though, as I think this decision has already been made.

> in the secure-frames-based stuff that tim refers to, you do not need
> to have a keyboard API. all you need to be able to do is create key
> events in one frame / context (the one in which the on-screen keyboard
> is displayed) and to be able to fire those events at its target frame
> (the application).

That's not quite all. We also need an event that tells us when keyboard
input is needed. That is, when the user clicks in a form element, gecko
needs to tell us to pop up the keyboard.

David

[Timothy Chien]

On 3/9/12 10:27 AM, lkcl luke wrote:
> On Tue, Mar 6, 2012 at 8:26 AM, David Flanagan<dfla...@mozilla.com> wrote:
>
>> If, on the other hand, the consensus is that the keyboard should be part of
>> Gaia, then who is working on the mozKeyboard API that will be needed to make
>> it work cleanly?
>
> in the secure-frames-based stuff that tim refers to, you do not need
> to have a keyboard API. all you need to be able to do is create key
> events in one frame / context (the one in which the on-screen keyboard
> is displayed) and to be able to fire those events at its target frame
> (the application).

Right, that's one way to do it.

Justin Lebar has been talking about adding an feature to mozbrowser
which the homecreen that creates the mozbrowser iframe gets to inject
script it want to into the iframe content. Such script can surely (A)
catches keyboard events created by keyboard app, extract it, and (B)
create the event again in content app and inject the character(s) to the
given input/textarea.

One downside about this is that this is really complex :( It's already
complex when I describe it in English right? That's why for part (B) we
some how need a browser API to generate the key events (and text input,
"text event" internally in Gecko) from homescreen. For part (A) it is
simply a mozKeyboard.sendKey() hack right now.

Another problem is that such keyboard app - Gaia homescreen interface is
not something standardize-able. By asking user-agent to pass the events
for us in part (A), keyboard app - Gaia homescreen interface can be
standardized. Another interface, or the mozbrowser injected script can
then do the part (B).

Does anyone know the status of IME API right now?

[lkcl luke]

On Fri, Mar 9, 2012 at 8:26 AM, Timothy Chien <timd...@gmail.com> wrote:

> One downside about this is that this is really complex :( It's already
> complex when I describe it in English right? That's why for part (B) we some
> how need a browser API to generate the key events (and text input, "text
> event" internally in Gecko) from homescreen. For part (A) it is simply a
> mozKeyboard.sendKey() hack right now.

ok... then how about creating an environment where that code can be
written... in javascript (or any other programming language) and the
API added to... *at runtime*... *in JAVASCRIPT*?

you have XPCOM: this should not be hard to do.

to be more explicit: you should be able to add a *JAVASCRIPT*
implementation of mozKeyboard *NOT* a c or c++-based one that adds
objects directly into the global scope (alongside global variables
window, parent, document etc.)

obviously this should only be possible at the top-level such that
apps are completely restricted and sand-boxed so that *they* cannot
pull off that kind of trick (and thus conform to W3C DOM approved
standards), but at the top level it's a different ballgame: you _want_
the flexibility to do these kinds of things.

l.

[David Flanagan]

On 3/9/12 6:32 AM, lkcl luke wrote:
> On Fri, Mar 9, 2012 at 8:26 AM, Timothy Chien<timd...@gmail.com> wrote:
>
>> One downside about this is that this is really complex :( It's already
>> complex when I describe it in English right? That's why for part (B) we some
>> how need a browser API to generate the key events (and text input, "text
>> event" internally in Gecko) from homescreen. For part (A) it is simply a
>> mozKeyboard.sendKey() hack right now.
> ok... then how about creating an environment where that code can be
> written... in javascript (or any other programming language) and the
> API added to... *at runtime*... *in JAVASCRIPT*?
>
> you have XPCOM: this should not be hard to do.

Luke,

It wouldn't be hard to do at all. The decision has apparently been
made, however: the keyboard and the homescreen itself will be ordinary
web apps, installable like any other web app. I don't understand the
decision, and I'm skeptical about our ability to standardize the APIs we
need, but that's the direction we're going in.

Tim,

mozKeyboard.sendKey doesn't seem at all like a hack to me. It seems
like the first part of the mozKeyboard API we'll need. I'd additionally
make mozKeyboard into an EventTarget and give it ondisplaykeyboard and
onhidekeyboard properties. Then the homescreen can listen for
"displaykeyboard" and "hidekeyboard" so that they know when to show and
hide the keyboard app. If the sendKey() function just sends the event
to whatever has focus, then we're done. If sendKey() must be passed a
window object to send the key to, then the displaykeyboard event could
include that window object to specify where the keyboard events should go.

David

[lkcl luke]

On Fri, Mar 9, 2012 at 5:25 PM, David Flanagan <dfla...@mozilla.com> wrote:
> On 3/9/12 6:32 AM, lkcl luke wrote:
>>
>> On Fri, Mar 9, 2012 at 8:26 AM, Timothy Chien<timd...@gmail.com>  wrote:
>>
>>> One downside about this is that this is really complex :( It's already
>>> complex when I describe it in English right? That's why for part (B) we
>>> some
>>> how need a browser API to generate the key events (and text input, "text
>>> event" internally in Gecko) from homescreen. For part (A) it is simply a
>>> mozKeyboard.sendKey() hack right now.
>>
>>  ok... then how about creating an environment where that code can be
>> written... in javascript (or any other programming language) and the
>> API added to... *at runtime*... *in JAVASCRIPT*?
>>
>> you have XPCOM: this should not be hard to do.
>
> Luke,
>
> It wouldn't be hard to do at all.  The decision has apparently been made,
> however: the keyboard and the homescreen itself will be ordinary web apps,
> installable like any other web app.  I don't understand the decision, and
> I'm skeptical about our ability to standardize the APIs we need, but that's
> the direction we're going in.

well, that's the point: by adding in the generic ability of an
XPT-based (or some-such) plugin being allowed to extend the namespace
of the top-level B2G frame, you could write not only the user-facing
keyboard as "an ordinary web app" (which is a term that is becoming
rather misleading now) but also you could write the API which that
user-facing keyboard *uses* as "an ordinary web app" as well.

under such circumstances, the "decision" in this case "keyboard in
javascript and using the global variable mozKeyboard" could be left
as-is, but modifications _to_ that global variable "mozKeyboard" and
its entire API could be done *without* requiring a whopping-great
rebuild of B2G.

in other words what i'm proposing actually massively accelerates the
development process of B2G.

l.

[David Flanagan]

On 3/9/12 12:21 PM, lkcl luke wrote:
> well, that's the point: by adding in the generic ability of an
> XPT-based (or some-such) plugin being allowed to extend the namespace
> of the top-level B2G frame, you could write not only the user-facing
> keyboard as "an ordinary web app" (which is a term that is becoming
> rather misleading now) but also you could write the API which that
> user-facing keyboard *uses* as "an ordinary web app" as well. under
> such circumstances, the "decision" in this case "keyboard in
> javascript and using the global variable mozKeyboard" could be left
> as-is, but modifications _to_ that global variable "mozKeyboard" and
> its entire API could be done *without* requiring a whopping-great
> rebuild of B2G. in other words what i'm proposing actually massively
> accelerates the development process of B2G. l.

I'm not sure I follow what you're proposing technically.

But I sure hear you about the whopping great rebuild process. And even
worse than that is that the changes to the gecko stuff go to a different
tree and have a different review process than those going into gaia.

I'd like to see the chrome code in gecko/b2g/chrome/content/*.js moved
into the gaia repo and have gecko load them through a file:// URL
instead of a chrome:// URL (assuming that is possible). This way, Gaia
devs could keep our chrome and our content in sync without rebuilding
and reflashing our phones and submitting our patches through the
mozilla-central pathway.

David

[lkcl luke]

On Fri, Mar 9, 2012 at 8:28 PM, David Flanagan <dfla...@mozilla.com> wrote:

> I'm not sure I follow what you're proposing technically.
>
> But I sure hear you about the whopping great rebuild process.

:)

allow me to try to clarify.

right now, there's a top-level namespace in xulrunner which is
occupied by variables such as "parent", "window" and "document".

B2G is different in that a *new* global variable has been added
called "mozKeyboard". this has had to be added by hacking together a
version of xulrunner which has been named "B2G", not part of
mozilla-central etc. etc.

that extra global variable has been implemented in c++.

what i am proposing is that the xulrunner infrastructure be extended
such that it is possible for *PLUGINS* to drop new global variables
into the global namespace. as a GENERIC extension to the xulrunner
infrastructure.

then, you move the implementation of mozKeyboard *out* of B2G's
codebase and into its *own* - much smaller - repository.

you could probably then do the exact same thing for all the other
WebAPI extensions which are being thrown into B2G, and could probably
go *back* to using the mozilla-central codebase *without* requiring to
make any modifications to it whatsoever.

you already have XPCOM, and you already have the XPI plugin system,
so it reallly shouldn't be technically hard to do this.

ultimately then, it should be possible to implement an XPI plugin -
entirely in *javascript* - which implements for example (and it is
only an example because this is a generic infrastructure being
proposed) the "mozKeyboard" concept. no not the "GUI" component - the
actual API which receives the events *from* the GUI component.

this would require that the NPAPI functions be available to
javascript... surely that's been done and/or considered before, right?

anyway, that last bit's for later.

l.

[David Flanagan]

On 3/9/12 12:56 PM, lkcl luke wrote:
> On Fri, Mar 9, 2012 at 8:28 PM, David Flanagan<dfla...@mozilla.com> wrote:
>
>> I'm not sure I follow what you're proposing technically.
>>
>> But I sure hear you about the whopping great rebuild process.
> :)
>
> allow me to try to clarify.
>
> right now, there's a top-level namespace in xulrunner which is
> occupied by variables such as "parent", "window" and "document".
>
> B2G is different in that a *new* global variable has been added
> called "mozKeyboard". this has had to be added by hacking together a
> version of xulrunner which has been named "B2G", not part of
> mozilla-central etc. etc.
>
> that extra global variable has been implemented in c++.

Luke,

I don't know anything about the plugin architecture, so I'm unqualified
to comment on what you write below. I can point out, however, that
mozKeyboard is currently implemented, in JavaScript, here:
http://hg.mozilla.org/mozilla-central/file/bfb1b7520ce9/b2g/chrome/content/webapi.js

Also: the toplevel namespace XUL is irrelevant. The tricky thing is that
the chrome code has to inject this navigator.mozKeyboard property into
the global namespace of the <iframe> elements that apps run in.

David

[lkcl luke]

On Fri, Mar 9, 2012 at 9:26 PM, David Flanagan <dfla...@mozilla.com> wrote:

> Luke,
>
> I don't know anything about the plugin architecture, so I'm unqualified to
> comment on what you write below. I can point out, however, that mozKeyboard
> is currently implemented, in JavaScript, here:
> http://hg.mozilla.org/mozilla-central/file/bfb1b7520ce9/b2g/chrome/content/webapi.js

oh really! very cool! then it could potentially be the case that
it's already implemented. er :)

hmm, it's so awkward this, isn't it? discussing things where the
terminology's actually being invented, and the people contributing
come from quite different backgrounds. thank you for being patient
and going round this a few times.

> Also: the toplevel namespace XUL is irrelevant. The tricky thing is that the
> chrome code has to inject this navigator.mozKeyboard property into the
> global namespace of the <iframe> elements that apps run in.

ah. right. right! exactly. ok. that's *exactly* what i was referring to :)

ok so, then: i believe that this sort of thing should *not* be
considered to be "a hack", but should instead be encouraged and fully
supported... and done in such a way that it is made to be properly
generic.

if for example there is some nasty hacking going on that *only*
allows navigator.mozKeyboard to be dropped into an iframe's namespace,
then that should be sorted out, documented and extended to allow it to
be done more often! :)

so the implications of that are that there needs to be an API which
allows "injection" to be done at the top-level, in a generic fashion
*not* as a one-time hack.

[ where i am using "top level" to refer to that secure-iframes system
which is being developed, the one which allows certain frames to be
isolated from each other, such that you can implement a "window-like
manager" in the quotes top level quotes and the applications can be in
iframes that act effectively as entirely separate spaces, in which you
could implement things like "a fully-functioning web browser" or "a
keyboard" or "a B2G application", as discussed and clarified err...
two months ago i think it was. ]

... could someone come up with a name for that system, btw? a nice
moniker so that it doesn't need an entire paragraph to make sure it's
being referred to unambiguously? :)

my suggestions: frame-manager, secure-frame-manager,
frame-window-manager, etc. etc. because seriously you really *are*
implementing the concept of a Window Manager within B2G, so call it
what it is: a "A Window Manager using IFrames as the means to separate
the windows".

l.