How should focus and key events work for out-of-process tabs?

[Chris Jones]

This is a restatement of a comment in bug 570620. In that bug, we now
have patches to eliminate platform widgets from content processes.

Removing platform widgets from content processes takes us to something
of a crossroads wrt fennec 2.0a1. Fennec *renders* just fine without
platform widgets, but focus and key events are totally broken. Oleg
Romashin and I also have code to draw layers in <browser remote=true>
that are published by widgetless content processes (keys and focus
similarly borked for <browser remote>).

We definitely want to move away from having platform widgets in content
processes. However, I know neither how key events and focus work
currently, nor how we want them to work for widgetless content
processes. If we can make them work without too much effort, I think we
should take the de-widgetification patches for fennec 2.0a1. We'll save
needless rendering to a widget we just draw a canvas over, and work on
cross-process layers for <browser remote> can continue on m-c without
disturbing fennec 2.0a1.

Thoughts from those in the know?

Cheers,
Chris

[Smaug]

Hi,

my guess for focus and key event handling is that:
1) chrome process should keep track on which process should have focus.
2) if focus isn't in the chrome process itself, key events should be
re-dispatched to the content process.
Re-dispatching should probably happen close to the widget level.
Hmm, or perhaps Presshell level is enough.

I don't know in which way the de-widgetification is done.
Is there still some kind of nsIWidget in the content process?

IME handling may cause some problems.
IME events need to go (well, re-dispatched) to the content process, but
IME needs to know where the events are dispatched so that the IME
software can show its UI in the right place.

Masayuki might have some ideas for IME.

-Olli


(Posting using smaug@ email address so that I can get this
to m.d.t.dom too)

Post by Chris Jones
This is a restatement of a comment in bug 570620. In that bug, we now
have patches to eliminate platform widgets from content processes.
Removing platform widgets from content processes takes us to something
of a crossroads wrt fennec 2.0a1. Fennec *renders* just fine without
platform widgets, but focus and key events are totally broken. Oleg
Romashin and I also have code to draw layers in <browser remote=true>
that are published by widgetless content processes (keys and focus
similarly borked for <browser remote>).
We definitely want to move away from having platform widgets in content
processes. However, I know neither how key events and focus work
currently, nor how we want them to work for widgetless content
processes. If we can make them work without too much effort, I think we
should take the de-widgetification patches for fennec 2.0a1. We'll save
needless rendering to a widget we just draw a canvas over, and work on
cross-process layers for <browser remote> can continue on m-c without
disturbing fennec 2.0a1.
Thoughts from those in the know?
Cheers,
Chris

[Chris Jones]

Post by Smaug
Hi,
1) chrome process should keep track on which process should have focus.
2) if focus isn't in the chrome process itself, key events should be
re-dispatched to the content process.
Re-dispatching should probably happen close to the widget level.
Hmm, or perhaps Presshell level is enough.

Either should be possible in the content process. In the chrome
process, we would need to associate an event target with a TabParent and
fire off a "please resdispatch this event" message there, I think.

I think so far fennec has been trying to forward events at the frontend
level. I'm not sure if this is a better or worse approach, CCing
mfinkle for thoughts.

Post by Smaug
I don't know in which way the de-widgetification is done.
Is there still some kind of nsIWidget in the content process?

There is: PuppetWidget that implements nsIWidget, to which we can
dispatch arbitrary events and set arbitrary properties. I would expect
that we would do so in response to PBrowser messages.

Post by Smaug
IME handling may cause some problems.
IME events need to go (well, re-dispatched) to the content process, but
IME needs to know where the events are dispatched so that the IME
software can show its UI in the right place.
Masayuki might have some ideas for IME.

Cool, thanks.

Cheers,
Chris

Post by Smaug
-Olli
to m.d.t.dom too)

This is a restatement of a comment in bug 570620. In that bug, we now
have patches to eliminate platform widgets from content processes.
Removing platform widgets from content processes takes us to something
of a crossroads wrt fennec 2.0a1. Fennec *renders* just fine without
platform widgets, but focus and key events are totally broken. Oleg
Romashin and I also have code to draw layers in <browser remote=true>
that are published by widgetless content processes (keys and focus
similarly borked for <browser remote>).
We definitely want to move away from having platform widgets in content
processes. However, I know neither how key events and focus work
currently, nor how we want them to work for widgetless content
processes. If we can make them work without too much effort, I think we
should take the de-widgetification patches for fennec 2.0a1. We'll save
needless rendering to a widget we just draw a canvas over, and work on
cross-process layers for <browser remote> can continue on m-c without
disturbing fennec 2.0a1.
Thoughts from those in the know?
Cheers,
Chris