Closed Bug 69504 Opened 24 years ago Closed 23 years ago

keyboard shortcuts inactive until window contents clicked

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.4

People

(Reporter: dkarr, Assigned: bryner)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: access) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8) Gecko/20010219
BuildID:    2001021904

I use web outlook express for a mail client.  When I click on a message in my
list, it brings up another window to display the message.  If I navigate through
the menu bar for that window, it shows many items to have accelerators. 
However, in the message window, no accelerators work.  However, as soon as I
click anywhere in the message window (not the menu bar), accelerator keys are
now active.  The window already had focus, but accelerators did nothing until I
clicked in the body of the window.

Reproducible: Always
Steps to Reproduce:
1. Bring up Web Outlook Express message list.
2. Click on one message to display it in another window.
3. Without clicking in the window with the mouse, press Ctrl-p (the     window
already has the focus).

Actual Results:  Nothing happens.

Expected Results:  The print dialog should appear.

Alternatively, before step 3, click anywhere in the window, not counting the
menu bar.  Then, the test case succeeds.  Pressing ctrl-p brings up the print
dialog.  It does not make any difference if you click instead on the menu bar. 
That does not make the test case succeed.
I think this is a more general problem where keyboard events don't seem to 
happen a lot of the time unless you click on the document window.  I haven't had 
time to see if this is filed yet, though.
it's gonna be real hard to work on this without an account on an outlook express
server somewhere.
nbaca, would you be able to test this?
QA Contact: sairuh → nbaca
Reporter: Are you in fact referring to "Microsoft Outlook Web Access for 
Microsoft Exchange Server"?

Anyway, I'm convinced that this isn't related specifically to Outlook Web 
Access.  Here's another test case:

1. Go to http://news.cnet.com/news/0-1006-200-4880476.html
2. Under the "Latest Headlines" column on the right side, click "Display on
   Desktop".
3. A new window opens.  This is similar to what happens in Outlook Web Access
   when a message is clicked on.
4. Press Ctrl+P.  Nothing happens.
5. Press Ctrl+W.  Nothing happens.
6. Click on the window.
7. Repeat step 4 or 5.  Works as expected.

This is some sort of keyboard event regression that's been around for a couple 
of weeks now but I, for some reason, haven't reported it.  This is hopefully a 
dupe of another bug that someone is actively working on.
Sarah, Based on the description, this isn't a Messenger bug.  It looks like the
person is accessing a WebMail account through the browser.  They are not adding
it in our Mail app via Mail/News Account Settings.  Reporter please confirm
this.  Also, as Dean points out this problem shows up in the browser on a cnn
site too.
Changing QA back to sariuh
QA Contact: nbaca → sairuh
I'm using Microsoft Web Outlook Express.  I'm not using the standard mail/news
interface.  As others have noted, this bug isn't specific to this, which is a
good thing.
URL: web outlook express message window
Keywords: qawanted
Summary: Menu accelerators inactive in web outlook express message window until window contents clicked → Menu accelerators inactive until window contents clicked
Whiteboard: DUPEME
Keywords: nsdogfood
Summary: Menu accelerators inactive until window contents clicked → keyboard shortcuts inactive until window contents clicked
Nominating for dogfood because this bug totally interrupts my browsing (and also
unnecessarily angers me).
confirming ...but i somehow think the general case of keyboard accelerators not
working till content has focus might already be reported. not sure where the bug
would reside --event handling? toolkit?

cc'ing saari, jesse and aaronl.
Confirming: This is quite similar to bug 67977 - but from the summary that bug
deals specifically with IFRAME's.

I have to agree though that there's probably an older bug, but I can't find it. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 72357 has been marked as a duplicate of this bug. ***
nav triage team:

Marking nsbeta1- because pchen has a similar bug somewhere on his list, but will 
revisit after beta
Keywords: nsbeta1-
OS: Windows NT → All
Hardware: PC → All
Interesting, this doesn't seem to be a problem with embedding.
I used mfcembed to test, and Accel+O still brings up the open dialog, where it 
would fail using the cnet test described by Dean Tessman above.
That's a good thing.
Keywords: nsdogfood → nsdogfood-
I have a similiar problem with:

URL: about:blank (hehe)

If I open a new window with Ctrl+N (opens a blank window), some keyboard
shortcuts fail to work unless I click on the content area.

Ctrl+N, Ctrl+Q work

Ctrl+H, Ctrl+B, Ctrl+W dont... 

Focus is in the location bar.... (I just found in another bug that Ctrl+W
doesn't work because of the emacs braindamage... this simply has to go away).

Also, I just noticed that some keys (Ctrl+N) dont work while typing here ;)
Could be a separate bug.

I think severity should be upgrated to "major".
The same problem occurs when doing "Open in new window" where the focus is not
on the location bar...

I think that the emacs binding should be a pref. Let's not make the unix mozilla
suck like 4.x does (breaking all GUI standards etc...).
Agreed. This is a major accessibility problem.
Severity: normal → major
Has anyone found the alleged dup in pchen's list?  I think someone needs to fix 
this for 0.9.2; we can take it if necessary.  sprinkling on more keyword dust...
Keywords: access, mozilla0.9.2
Possible dups bug 37638, bug 67977 or bug 32349?
sounds like bug 37638 see comment by Matthew Thomas (mpt) 2000-10-18 21:44
No, bug 37638 is not a dup.
That has to do with whether the URL bar should be focused when a new window is 
opened.

This bug has to do with whether the keyboard hotkeys work or not - such as Cmd+P 
to print. These keys are supposed to work no matter where the focus is in the 
page.
Blocks: keydead
Blocks: focusnav
No longer blocks: focusnav
Blocks: focusnav
No longer blocks: focusnav
Bryner taking keyboard inactive/ keydead bugs
Assignee: alecf → bryner
No longer depends on: focusnav
Blocks: focusnav
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
clearing DUPME, going to keep this separate for now.
Whiteboard: DUPEME
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** Bug 84679 has been marked as a duplicate of this bug. ***
*** Bug 79772 has been marked as a duplicate of this bug. ***
Keywords: fcc508
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Seems to work now, checked on Linux and Windows.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
tested using accel+N, accel+B, accel+H, accel+W and accel+Q. vrfy fixed on linux
[2001.09.10.05-br], winnt [2001.09.10.06-br] and mac os 9.x [2001.09.10.03-br].
Status: RESOLVED → VERIFIED
Keywords: qawanted
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.