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

On 07/23/2010 05:44 PM, Smaug wrote:
> 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.
>

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.

> 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.

> 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

> -Olli
>
>
> (Posting using smaug@ email address so that I can get this
> to m.d.t.dom too)
>
> On 7/24/10 1:13 AM, Chris Jones wrote:
>> 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
>