Closed Bug 36016 Opened 24 years ago Closed 23 years ago

Command-key shortcuts not working w/ all windows closed

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
PowerPC
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: koonce, Assigned: danm.moz)

References

Details

(Keywords: access, regression, Whiteboard: [driver:brendan])

Attachments

(1 file)

don't prematurely add an empty document for a newly created window
4.67 KB, patch
jst
: superreview+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.72 (Macintosh; I; PPC)
BuildID:    2000041608

the command-<key> (ex. command-L for new location) will work fine normally. Once 
i have closed *ALL* of the open mozilla windows, though, the computer no longer 
pays attentin to what's wrong.

Reproducible: Always
Steps to Reproduce:
1.close all windows
2.try to hit command-n or something
3.

Actual Results:  nothing happens...

Expected Results:  handled the event.
skoonce@usc.edu, what I think you're saying is that after closing all Mozilla
windows, command-keys no longer work in any other apps on a Mac. 
Is that correct?
skoonce@usc.edu replied by e-mail:
 > No, the keys still work in other programs. Mozilla, however, doesn't want
 > to have anything to do with my command-q.  

 > Maybe someboday added some AI such that the program doesn't want to die. :)
This is probabably a menu problem, actually.  In the pc versions of the program, 
once you close all the windows, mozilla should die.  On a mac, though, mozilla 
should remain responsive.  I'd bet there's a line or two of code that's making 
mozilla think it's dead when it should still responding to command-key events.

Confirmed. Updated URL/Summary & OS. Mozilla M16 2000042010, Mac OS 9.0.4.

Command-key shortcuts aren't working when all windows are closed. Changing to 
normal as per the mounds of other keyboard shortcut bugs. Candidate for pp?
URL: <none>
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac System 8.5 → All
Summary: Command-<key> not working → Command-key shortcuts not working w/ all windows closed
*** Bug 36042 has been marked as a duplicate of this bug. ***
Saari, I believe you were working on a bug like this?
Assignee: joki → saari
Yeah, fixed this a couple weeks ago.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
verified on build 2001-08-01-08-trunk
Status: RESOLVED → VERIFIED
*** Bug 111111 has been marked as a duplicate of this bug. ***
This bug has been seen again on macOS 9.1 buildID: 2001-11-21-12trunk build

reopening this bug
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This has been broken again for a while.  Still broken on today's trunk build.
Target Milestone: --- → mozilla0.9.8
*** Bug 114840 has been marked as a duplicate of this bug. ***
*** Bug 115332 has been marked as a duplicate of this bug. ***
Keywords: access
QA Contact: madhur → sairuh
*** Bug 115876 has been marked as a duplicate of this bug. ***
I'm seeing this same behavior (accelerator keys not working when no windows are open) under Moz 0.9.7, MacOS 8.6, FYI.
Just to confirm that this is still broken, and add an interesting tidbit:

Sometimes, although very rarely, an accel key will work with all the windows
closed on the Carbon Mac OS X build.  It's works very sparsely, only about 5% of
the time.

When it does work, it's very strange... sometimes pressing [Cmd] + [N] (File>New
Nav. Window) will NOT work, but pressing [Cmd] +[1] (Tasks>Navigator) WILL work.
 Have fun.
*** Bug 117913 has been marked as a duplicate of this bug. ***
note to self: also a problem on 10.x...
Keywords: nsbeta1, regression
*** Bug 116727 has been marked as a duplicate of this bug. ***
d'oh, someone already said that...

anyhow, from bug 116727: looks like this regressed btwn 11/15/2001 [working] and
11/19/2001 [broken].
Severity: normal → critical
*** Bug 118186 has been marked as a duplicate of this bug. ***
*** Bug 118210 has been marked as a duplicate of this bug. ***
*** Bug 118787 has been marked as a duplicate of this bug. ***
a bit more narrowing, thx to claudius: the 2001.11.16.08 bits also worked.
In Build ID 2002011003, Command shortcuts aren't working at all, regardless of
whether windows are open or closed. (Seems like things are going from bad to worse.)
Michael, that is a different bug: bug 119109, which has been fixed.
*** Bug 118316 has been marked as a duplicate of this bug. ***
*** Bug 119591 has been marked as a duplicate of this bug. ***
Blocks: 115520
Another tidbit that may help when debugging this issue:

OS: Mac OS X v. 10.1.2
Build Type: Fizzilla CFM
Build ID: 2002011408

1. Use your mouse to select "File > New Navigator Window".
2. Close the resulting Navigator window.
3. Press [Command] + [N].  A new Navigator window appears.

If you use the mouse to select an item from a menu, you can use the command key
for that item.  Investigating further:

4. Close the Navigator window again.
5. Press [Shift] + [Command] + [L]
6. The "Open Web Location" dialog appears.

So, if you use the mouse to select an item from a menu, you can then use _all_
the accellerator key shortcuts in that menu only.  Try another menu:

7. Use your mouse to select "Tasks > Navigator".
8. Close the resulting Navigator window.
9. Press [Command] + [2].  Mail and News opens.

Hope this discovery helps actually solve the problem (and doesn't lead to a
cheap hack ;o)
commenting on comment#33 - i was able to duplicate all that was noted 
(mac os 10.1.2/ build 2002010308)but wanted to add to this section:

"Investigating further:

4. Close the Navigator window again.
5. Press [Shift] + [Command] + [L]
6. The "Open Web Location" dialog appears."

true, the dialogue appears but it doesn't respond to the keyboard. interesting,
i cannot type in a new url or even paste in a url until i click on the location
line with my mouse.
"...the dialogue appears but it doesn't respond to the keyboard."

Yes, I noticed the same thing. Just noting that this is an issue unrelated to
this bug.  It's a focus bug, of which Mozilla has a plethora.  To the team's
credit, though, many of the ones that used to annoy me have been fixed.
I need to add that, for a menu's accellerator key shortcuts to become active
when all windows are closed, you need to use the mouse to select an item in that
menu *when all windows are closed*.

i.e.: If you have a window open, and choose "File > New Navigator Window" with
the mouse, the menu will still not respond when all windows are closed.  You
must have all windows closed first.

Wierd bug, but I hope it's pinned down now.
Whiteboard: [driver:brendan]
I wonder if the issue is with menus being dynamic (that is, they only have their
content built up, and command listeners set up, as needed).  When a menu's
content hasn't been built up, no commands can be matched... and only after
clicking in the menubar for a given menu (which causes the content to be built)
will command-key shortcuts function.

After a menu has been constructed, command-key shortcuts would work until its
contents were invalidated and flushed.

rjc: that's exactly what's happening. no mystery there. what we still don't know
is why gecko stopped fielding the cmd-keys itself and when.

the fact that it works after you pull down a menu is because the os is sending
us carbon menu events which go through a totally different path than our regular
key events. we shouldn't be getting the carbon events at all.
Running out of time for 0.9.8, should we give up on this one?  Who should it be
assigned to, anyway?  It sounded like saari is busy elsewhere, last I inquired.

/be
Pink will look at this, but probably not before 0.9.8 goes out.
Assignee: saari → pinkerton
Status: REOPENED → NEW
Target Milestone: mozilla0.9.8 → mozilla0.9.9
ok, here's what's going on:

in the case that works (window is open), we trap the keydown and dispatch to the
focussed widget. The widget then calls its registered event handler, which goes
into nsView.

in the hidden window case, we trap the keydown but they focussed widget is the
toplevel window. The registered eventhandler is webShellWindow, which drops the
event on the floor.

This is a focus bug. What regressed?
Priority: P3 → P1
ok, found what caused the regression, but i still don't understand why.

backing out this change from danm:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/global/resources/content&command=DIFF_FRAMESET&file=commonDialog.js&rev1=1.38&rev2=1.39&root=/cvsroot

fixes it. okay danm, work your magic and make it all better ;)
Assignee: pinkerton → danm
Should we back out that change for 0.9.8, or would that be worse than status quo?

/be
*** Bug 119468 has been marked as a duplicate of this bug. ***
danm, what's the status on this bug? Should we back out the offending checkin?
*** Bug 117139 has been marked as a duplicate of this bug. ***
I'm looking at this now. Finally. Backing out the offending checkin will break
bug 88229 and friends (like bug 22681), but those are all fairly obscure. This
is probably OK for 0.9.8. How long do I have to look for the real solution
before 0.9.8 is declared baked?
Been talking. Current opinion is that there are people who are looking forward to 
a Mozilla release with things like bug 88229 fixed (Galeon, for instance) and 
that since there is a fairly visible workaround for this problem, we're going to 
leave it broken in 0.9.8 unless I can come up with a real fix today. It's 
possible.
Status: NEW → ASSIGNED
This is hard to debug, it having something to do with focus and window
activation. Running under a debugger makes it behave completely differently.
And have I complained lately that the CodeWarrior debugger pretty much brings
my whole machine down after about half an hour of heavy use?

</whine>. During window creation we're asking the calling context's window to
cough up a document whether it has one or not. This has kind of seemed like a
problem, and now this bug rather proves the point. In this case, construction
of the hidden window's natural document is sidetracked and this seems to result
in the loss of two focus() calls to that window after it finally comes in.
Haven't really been able to track down why that is. Presumably because of the
missing focus call(s), when the hidden window eventually gets focus after all
other windows have been closed, focus memory gives focus specifically to the
top-level shell window, rather than the content DOM window, where the command
handlers live.

Synchronous document creation in this case seems like a problem anyway. The
window creation code that wants the hidden window's document really only wants
the natural document, if it exists. So I've added a backdoor through
nsPIDOMWindow to allow just that. Ugh. I hope we don't end up needing to
carefully balance when we ask for which kind of document throughout the
codebase.
This should probably be spun off, but it seems closely connected, and hoping it
will help track down the reason for 36016:

When a window tab fails to load (due to connection error or maybe DNS lookup
failure), and that tab is frontmost, the same problem occurs.  Command-key
shortcuts no longer work, even in the presence of open windows.
Comment on attachment 67821 [details] [diff] [review]
don't prematurely add an empty document for a newly created window

Looks reasonable to me, I might have done a simple boolean getter that tells
you if there is a document in the window or not, but that's more a matter of
taste than anything else.

sr=jst
Attachment #67821 - Flags: superreview+
Erick (comment 51): if you mean:

open browser window
cmd-T for new tab
type xxx.nosuchplace.zigg (return) in the URLbar
dismiss the "couldn't find it" alert
cmd-N for new window (doesn't work)

then I agree, that sounds like a different bug. However, this works fine in my
current build, which has the above patch, so maybe it is the same bug and it'll
go away with this one.
ugly as sin, but i guess it's necessary. you sure there's no other way around
this? two things:

- GetDocument() should be (pardon the pun) documented that a document will be
created if none exists
- add a comment where you call GetExtantDocument as to why you're need to call
this instead of GetDocument().

this is all so fragile and makes me feel smarmy, but r=pink with the above changes.
  I think it's not as bad as all that. Generally -- everywhere except this one
case (so far) -- we use the method that always returns a document. This one case
I don't feel too bad about because it's small and well constrained and wants the
window's document for only this one small thing and clearly has no use for a
document where one didn't exist and then it's all over. And the backdoor is well
hidden in a private interface. I'm not so unhappy about this fix. I would be
unhappy to see it propagated. I think we're good.
  Thanks for the reviews, all.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
did you at least add comments at the call site for GetExtantDocument()
describing why we use it instead of GetDocument?
*** Bug 120435 has been marked as a duplicate of this bug. ***
vrfy'd fixed using on 10.1.2 [2002.02.07.09, comm] and 9.1 [emulated,
2002.02.07.03, moz].
Status: RESOLVED → VERIFIED
*** Bug 126233 has been marked as a duplicate of this bug. ***
*** Bug 127225 has been marked as a duplicate of this bug. ***
*** Bug 129194 has been marked as a duplicate of this bug. ***
*** Bug 129527 has been marked as a duplicate of this bug. ***
*** Bug 124778 has been marked as a duplicate of this bug. ***
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: