pressing shortcut for context menu causes Composer to ignore keyboard navigation

RESOLVED DUPLICATE of bug 199737

Status

()

Core
Editor
RESOLVED DUPLICATE of bug 199737
15 years ago
15 years ago

People

(Reporter: Uri Dor, Assigned: Joe Francis)

Tracking

({access, pp, sec508})

Trunk
x86
Windows 2000
access, pp, sec508
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401

if the Windows "context menu" key (the one which performs the action of mouse
right-click) is pressed while composing a message, further keystrokes are
ignored, until the composer is clicked with the mouse.

Reproducible: Always

Steps to Reproduce:
1. compose a new message
2. type some text
3. hit the Windows "context menu" key
4. try to type more text

Actual Results:  
can't type, until I click the mouse on the composer window.

Expected Results:  
shown the context menu.

actually, there is another bug related: the "context menu" key doesn't show the
menu in the browser either. To me that's less interesting, but still...

Comment 1

15 years ago
I can confirm this bug on
 build Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030414

When you hit the A key after the "context menu" key, all text in composer window
is selected, if you press P key, clipboard content is pasted to the text.
Navigation through cursor keys and enter works too.

It looks like the context menu is activated but not shown.

Im also seeing this 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030412
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

15 years ago
I see this problem not only in Mail but also in the Composer window when editing
HTML pages.

In the Navigator window the "context menu" key behavior is normal and correct,
menu is shown.
over to shuehan
Assignee: sspitzer → shliang
Keywords: access, nsbeta1, sec508

Comment 5

15 years ago
See bugs 36665, 54946 and 54944, they are all closed but need to be reopened IMHO. 

Comment 6

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Summary: pressing the Windows "context menu" key causes Composer to ignore keyboard → pressing the Windows "context menu" key causes Composer to ignore keyboard
i cannot reproduce this on either linux (rh8.0) or mac (10.2.6), but i can do so
on win2k. so i don't think this should be dup'd to bug 36665.

here's what i've done.

1. open a new composer window.
2. enter some text.
3. try to bring up context menu via keyboard (shift+F10 or the windows key).

result: nothing happens.

4. try to move the caret with the arrow keys.

result: unable to move the caret.

5. click the mouse in the composition area.
6. select some of the text using the mouse.
7. repeat step 3.

results: now the context menu appears --it will also now work in subsequent
composer windows.

note: if at 6 you had done the selection using the keyboard (eg, shift-arrow
keys), then you'd still fail at bringing up the context menu with the keyboard.
seems somehow necessary to use the mouse for selection before keyboard access to
the context menu will work.

this might be an editor: core, selection or layout bug; trying the first one.
Assignee: shliang → jfrancis
Component: Mail Window Front End → Editor: Core
Keywords: pp
Product: MailNews → Browser
QA Contact: esther → sairuh
i know that selection differs amongst the platforms (so punt if that's where
this should live), but i'm not sure if it's really layout (caret) or focus
(mouse clicking and selection).

renominating due to additional info in comment 7.
Keywords: nsbeta1- → nsbeta1
updated summary. keyboard navigation affected includes arrow keys (to move the
caret) and accelerators (eg, ctrl+N, ctrl+W).
Summary: pressing the Windows "context menu" key causes Composer to ignore keyboard → pressing shortcut for context menu causes Composer to ignore keyboard navigation
weird.  I was pretty sure Shuehan and I tested this case as part of fixing bug
199737.
spoke to brian, and he thinks the checkin for bug 199737 was botched, so dupping
this to that bug.

*** This bug has been marked as a duplicate of 199737 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.