33735 - [Mac] Keyboard shortcuts broken when no browser windows open

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Nick Meara]

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

Comment 1

[sairuh (rarely reading bugmail)]

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.

Comment 2

[saari (gone)]

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

Comment 3

[Mike Pinkerton (not reading bugmail)]

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

Comment 4

[saari (gone)]

I'll put this in M15 with the assumption that I can just use the code pink wrote.

Sure, I'll take the credit ;-)

Comment 5

[Peter Trudelle]

Mass-moving most M15 bugs to M16

Comment 6

[leger]

Putting on [nsbeta2+] radar.

Comment 7

[John Bafford]

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?)

Comment 8

[sairuh (rarely reading bugmail)]

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

Comment 9

[saari (gone)]

Fixed.

Comment 10

[sairuh (rarely reading bugmail)]

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

Comment 11

[Nick Meara]

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

Comment 12

[Peter Trudelle]

->future

Comment 13

[sairuh (rarely reading bugmail)]

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

Comment 14

[sairuh (rarely reading bugmail)]

*sigh*

Comment 15

[Simon Fraser [no longer active]]

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.

Comment 16

[Simon Fraser [no longer active]]

This should be an easy kill for nsbeta3.

Comment 17

[saari (gone)]

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>

Comment 18

[Simon Fraser [no longer active]]

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

Comment 19

[saari (gone)]

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

Comment 20

[Simon Fraser [no longer active]]

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.

Comment 21

[saari (gone)]

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

Comment 22

[Dan M]

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

Comment 23

[sairuh (rarely reading bugmail)]

vrfy fixed using 2000.10.03.12-n6 bits.