Chris Saari wrote:
> Okay, so this looks reasonable. Could you explain the event sequence
> when someone clicks on the embedded browser?
I'll try.
> Who gets the native event,
The embeddor is required to provide the outermost window chrome (and to
implement nsIBaseWindow and nsIWebBrowserChrome which represent that
window for us), so, they'd be getting first crack at a native event.
> does the embedding app call activate,
That's how I see it.
> what is the sequence of both native and XP events?
Not sure, any thoughts?
> Will there be a provision for the browser to request focus from the
> native app or can it just take it?
I suspect it can just take it.
> Will activate be used both for embedding window reactivation
> notification and for focus changes within the embedded app?
Not sure. If it's robust enough to use internally, we could use it there.
> Are we going to have a concept of focus within the browser (it
> remembers it's last focused element everytime you "activate" it) or
> are we going to have one focus tracker for the entire embedding app
> and the browser (which is generally less jaring to the user, there are
> bugs filed about our dual selection model in 6.0 which is a similar
> issue)?
I envisioned the embedding app maintaining it's concept of what has
focus (and that that item gets focus when the window is
setFocusAtLastElement()'d).
Jud
>
>
> Judson Valeski wrote:
>
>> Potts and Vidur came up w/ the following after discussing focus issues.
>>
>> Judson Valeski wrote:
>>
>>> nsIFocus* - valeski/potts
>>
>>
>> interface nsIWebBrowserFocus {
>> void activate();
>> void deactivate();
>>
>> // Give the first element focus within mozilla
>> // (ie. TAB was pressed and focus should enter mozilla)
>> void setFocusAtFirstElement();
>>
>> // Give the last element focus within mozilla
>> // (ie ALT-TAB was pressed and focus should enter mozilla)
>> void setFocusAtLastElement();
>>
>> attribute nsIDOMWindow focusedWindow;
>> attribute nsIDOMElement focusedElement;
>> };
>>
>> interface nsIWebBrowserChromeFocus {
>> // ALT-TAB was pressed and focus should leave mozilla.
>> void setFocusAtPreviousElement();
>>
>> // TAB was pressed and focus should leave mozilla
>> void setFocusAtNextElement();
>> };
>>
>> "The first interface would be implemented by the WebBrowser component
>> - allowing the containing application to manipulate focus within
>> mozilla... The containing application would QI the WebBrowser
>> component for the interface.
>>
>> The second interface could be optionally implemented by the
>> containing application, if it wanted to be part of the "virtual focus
>> chain". This interface allows tabbing within mozilla to set focus in
>> the containing application. If this interface was not available,
>> then tabbing in mozilla would just "cycle" within mozilla and never
>> "jump out" to the containing app... The WebBrowser should QI the
>> WebBrowserChrome for this interface...
>>
>> There is already an interface called nsIFocusController, which seems
>> to do most of what nsIWebBrowserFocus does :-) So, hopefully we can
>> leverage it when implementing nsIWebBrowserFocus."
>>
>> Jud
>>
>
