Closed Bug 36016 Opened 25 years ago Closed 23 years ago

Command-key shortcuts not working w/ all windows closed

Categories

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

PowerPC
All
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: koonce, Assigned: danm.moz)

References

Details

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

Attachments

(1 file)

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 ago23 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: