Overview Description: On Mac OS the keyboard shortcuts do not work when Mozilla is running with no windows open. Steps to Reproduce: 1) Launch Mozilla. 2) Close the initial browser window. 3) Type a keyboard shortcut to perform an action, such as quitting the application (Command Q) or opening a new browser window (Command N). Actual Results: The keyboard shortcuts have no effect.Nothing happens. Expected Results: Appropriate action for keyboard shortcut is performed. Build ID and Platform: 2000032808 build on Mac OS 8.6

i keep thinking there's already a bug on this, but i cannot seem to find it. anyhow, it's a definite regression w/respect to 4.x.

There is another bug on this, I think Pink has it (and a proposed fix!).

saari, do you already have this bug? i never checked in my presShell changes, though they are on my machine.

I'll put this in M15 with the assumption that I can just use the code pink wrote. Sure, I'll take the credit ;-)

Mass-moving most M15 bugs to M16

Putting on [nsbeta2+] radar.

Command shortcuts also do not work when a view source window is active. Arrow keys for navigation and pageup/pagedown also don't work when view source is active. (Is this part of the same problem?)

hi John, the problem you're seeing w/keyboard shortcuts in the source window is tracked in bug 26593.

Fixed.

verif on Mac OS 9.0, 2000.05.24.08, opt commercial bits.

This has been reoccurring on the nightly Mac builds lately. Verified with 2000-09-13 build on Mac OS 8.6. Reopening.

->future

*** Bug 51414 has been marked as a duplicate of this bug. ***

*sigh*

The reason that they don't work is because of the test for an empty window content rgn in nsMacMessagePump::DispatchOSEventToRaptor(). Because the hidden window is (I presume) 0,0 pixels, it counds as empty. We just need some special casing here. Reassign to pinkerton in danm's absence.

This should be an easy kill for nsbeta3.

I'm not 100% convinced that is all there is to it Simon (although that would be nice). Did you try this fix? If this doesn't work, it is related to changes in activation <sigh>

It works fine if I omit that check for an empty window.

Cool! I must have been chasing a dead end before.

pink noted that backing out that change will cause tooltips to show up for windowshaded windows, which is pretty brain-dead. So can we filter what events are passed through in this case? Maybe we should send keys, but not mouse moves, for example.

That sounds reasonable. Or is there a better check for being window shaded than "is empty"?

We're now filtering only mousemove events for windowshaded windows, which returns key events to their normal programming. All better.

vrfy fixed using 2000.10.03.12-n6 bits.