start browser in turbo mode press ctl-n -> browser window comes up close browser window, by clicking close button on top right corner press up/down arrow keys -> some sort of seach field comes up there maybe other keyboard cases we don't know of... :-)

event stuff -> saari? punt as needed.

we need to disable keyboard envents if there are no app window visible, but we need to enable keyboard events if there is at least one app window open. -turbo mode is windows only (see bug 75599)

Keybindings should not work without a window on win32. That is a mac only thing. Are you seeing other behavior?

on win32 with law's -turbo mode patch, which runs app in windowless mode, it will respond to keyboard events.

Okay, then there *is* a window somewhere. When does this need to be done? 0.9.2?

not for 0.9.1. :-) however, people are egar to get law to check in his patches.

saari, this is affecting a feature that we're considering turning on for rtm, so we would like to have it in 0.9.2. Is there a way you can help fix it? or does this belong to law?

request for this to be fixed in 0.9.2 :-) changing target milestone...

Someone needs to tell me how turbo mode works. If we're responding to events, there there has to be a win32 window somewhere, it is the only way to get events. So how do I tell the difference between this "turbo" window, and a normal window?

Chris, "turbo mode" *doesn't* work (just look at all the bugs :-). Currently, it is working by re-parenting a Navigator window to a hidden window (plain Win32 window that happens to be lying around for doing IPC between secondary mozilla.exe's and the already-running one). The Navigator window happens to be subclassed while being re-parented, because Windows generates some SetFocus calls when the parent is changed and those were triggering an assertion deep in the guts of the widget/focus code. The subclass window procedure filters all WM_SETFOCUS messages. My first thought was that this subclassing could be maintained during the entire time that the Navigator window is "hidden." That wouldn't be hard to do. But, the whole problem goes away if we fix the raft of other bugs (81712, 81714, etc.) by eliminating this "hidden" Navigator window entirely. So I don't think I'd spend much time on this till that issue plays out. Basically, I don't think it would be wise to hack the widget/focus code to deal with this. The "turbo mode" is supposed to be entirely inoperative if you don't specify the "-turbo" command line switch and I don't think we can tweak the widget/focus code too much while continuing to make that claim.

Okay, based on law's comments in this bug and a converstation with him, I'm reassigning the bug to him for dispersal as he sees fit.

nav triage team: Going on law's comment, we think it best to fix not needing the hidden window, marking target milestone of mozilla1.0

Hmmm. I'd have preferred keeping this one at mozilla0.9.2 so that it doesn't fall off the radar. This problem still has to be fixed for mozilla0.9.2. Just because it is likely being fixed by a checkin for some other bug doesn't change that. Of course, if the goal is simply to reduce the number of currently open mozilla0.9.2 bugs, then maybe retargetting this one makes sense.

Fixed by patch for bug 81712.

Verified build 2001070604 os win95