Closed Bug 611425 Opened 14 years ago Closed 8 years ago

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

Categories

(Core Graveyard :: Embedding: APIs, defect)

1.9.2 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: caustin, Unassigned)

References

Details

(Whiteboard: [imvu])

Attachments

(1 file)

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".
Whiteboard: [imvu]
: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
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
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: