nsIFocusManager introduced in gecko 1.9.2 doesn't support sibling Gecko and non-Gecko windows

RESOLVED INCOMPLETE

Status

()

Core
Embedding: APIs
RESOLVED INCOMPLETE
7 years ago
2 years ago

People

(Reporter: Chad Austin, Unassigned)

Tracking

1.9.2 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [imvu])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
At IMVU, we use Gecko 1.9.1 for our UI.  The IMVU application is built of a single top-level window with several child windows of different types.  Some are embedded Gecko windows (nsWebBrowser instances) and some are IMVU 3D windows.  Focus passes from one to another when the user clicks on focusable regions.  I will attach a screenshot demonstrating typing in the 3D window while a focusable Gecko window is on the screen.

(As an aside, I am going to refer directly to nsIFocusManager, since nsIWebBrowserFocus is a thin wrapper around nsIFocusManager.)

After several discussions with Enndeakin, I am confused about how to support focus in multi-child-window applications.  Enndeakin suggested that I call nsIFocusManager::WindowRaised when a Gecko window takes focus.  The problem is that, if I don't immediately call WindowRaised on the child window, it ignores focus, even though the nsWindow receives a mousedown notification from the OS.  

I believe the root of the issue is that nsIFocusManager conflates two concepts: activation and focus.  Today, calling WindowRaised means "make this window focusable and also focus it".
(Reporter)

Updated

7 years ago
Whiteboard: [imvu]
(Reporter)

Comment 1

7 years ago
Created attachment 489883 [details]
typing in a 3D window and a focusable inventory search
(Reporter)

Comment 2

7 years ago
:karlt just pointed out bug 533245, which may be the root of our problems.  I'm not sure, so I'll describe a secondary issue we ran into:

If we called nsIFocusManager::WindowRaised on every gecko window, we could click between them and give them focus.  However, if you have called WindowRaised on a window that is not yet loaded, it will call SetFocus on itself when loaded.  Since loading is somewhat nondeterministic, we can't guarantee which window will end up with focus.

My hypothesis is that if bug 533245 is fixed, we wouldn't need to call WindowRaised on every Gecko window, fixing this nondeterminism.
Depends on: 533245

Comment 3

2 years ago
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.