Closed Bug 20298 Opened 25 years ago Closed 24 years ago

Shift-modified Keyboard Shortcuts don't work

Categories

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

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: elig, Assigned: saari)

References

Details

(Keywords: helpwanted, Whiteboard: [PDT-] [nsbeta3-] [rtm-]) 

* TITLE/SUMMARY
"Edit Blank Page" (Shift-N) keyboard shortcut doesn't do anything

* STEPS TO REPRODUCE
0) Launch Apprunner
1) From the Tasks menu, select Composer
2) Try to invoke the Edit Blank Page menu. (I believe you do shift-Command-N on
Mac OS, Shift-Control-N on Win32, and Shift-Alt-N on Linux.)

* RESULT
 - What happened

A new _Browser_ window opens. (The menu item properly invokes a new browser
window when selected via the mouse.

 - What was expected

A new _Composer_ window to open.

* REGRESSION

 - Occurs On
        Win32 Apprunner (1999112908 [NT 4, Service Pack 5])
        Linux Apprunner (1999112908)
        Mac OS Apprunner (1999112908)

 - Doesn't Occur On
        N/A

* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
QA Contact: sujay → elig
[qa assigning to self.]
Assignee: beppe → saari
Component: Editor → XP Toolkit/Widgets
Summary: "Edit Blank Page" (Shift-N) keyboard shortcut doesn't do anything → "Edit Blank Page" (Shift-N) keyboard shortcut doesn't work
All keybindings with shift in them don't work (if there is a keybinding without
shift).  This isn't particular to the editor.  Reassigning to saari.

Chris--let me know if you need some help to fix this one.
Summary: "Edit Blank Page" (Shift-N) keyboard shortcut doesn't work → Shift-modified Keyboard Shortcuts don't work
Thanks, Kathy. I did a query, and can't find any general bugs for "Shift" +
"Command/Control" keys not working, so am leaving this bug open with a clarified
subject per your comments.
Assignee: saari → matt
Component: XP Toolkit/Widgets → XPMenus
QA Contact: elig → sairuh
reassigning QA contact, updating XPMenus component & developer to matt. (but do
lemme know if it's really saari's bug.)
Assignee: matt → saari
As brade said looks like shift control is not working.
I believe this is saari's bug.
Target Milestone: M14
Assignee: saari → pinkerton
Taking menu/popup bugs.
back to saari. mwahahaah
Assignee: pinkerton → saari
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
I'm not sure if this should be in beta1 or not... It is important but I definetly 
have more important things to look at.
Status: NEW → ASSIGNED
Keywords: beta1
Whiteboard: Is this beta1 level?
Putting on pdt- radar for beta1.  This shortcut we would not hold for.  Cool is 
you can get it in.
Whiteboard: Is this beta1 level? → [PDT-]Is this beta1 level?
Hey PDT- so I'm punting to M15
Keywords: beta1
Target Milestone: M14 → M15
This blocks the editor for control-shift-n (new editor window) on Windows 
(and similar keybindings on the other platforms).  Adding dependency.  Note: it 
is currently PDT- so 25085 may have to be fixed in another way or it won't work 
in beta.
Blocks: 25085
Blocks: 27299
Putting beta1 in Keywords thought PDT- and adding relnote keyword.
Keywords: beta1, relnote
Blocks: 23574
Is this same bug causing shift-delete to delete instead of cut?
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
Wow, now shift-delete does a delete followed by another delete.
I'm not going to have time to look at this for beta2
Target Milestone: M16 → M18
pardon the spam: beta1 is long gone...removing this keyword. will soon replace
w/nsbeta2...
Keywords: beta1
clearing out beta1 note in whiteboard, since it's past.
Whiteboard: [PDT-]Is this beta1 level? → [PDT-]
mass-moving all '-' bugs to M20
Target Milestone: M18 → M20
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.
QA Contact: sairuh → jrgm
updating component.
Component: XP Toolkit/Widgets: Menus → Keyboard Navigation
We shoudl be able to support this correctly on all platforms (if it doesn't work 
already). nsbeta3
Keywords: nsbeta3
Keywords: helpwanted
Whiteboard: [PDT-] → [PDT-][nsbeta3-]
Target Milestone: M20 → Future
Renominating for nsBeta 3
Keywords: UE1
Whiteboard: [PDT-][nsbeta3-] → [PDT-][nsbeta3]
To renominate: 
  (1) _remove_ the [nsbeta3-] and make sure that the nsbeta3 keyword is set
  (2) give a concrete argument why it is important to fix this bug for RTM
      as fixing this bug may mean that other, also serious, bugs do not get
      fixed.
Whiteboard: [PDT-][nsbeta3] → [PDT-]
Thanks I was getting abit tired- Here it goes...

Full Keyboard access is escential to any modern computer application except for 
may be a game where you depend on a joystick. The functionality provided by the 
shift allows users to do things that they would either be unable to do with out a 
mouse or it would be enormiously difficult to do. For instance shifted Short cuts 
are planned (UI design) for opening and closing sidebar, Save as in Composer, 
shortcut to focus Folder and Thread panes in Mail. If tab gets implimented then 
we end up with a problem of tabbing focus through an attached web page with a 
long tab string to get back. This is especilly true if CtrL+Tab to switch panes 
doesn't get implimented.

These are only a few of the Shifted access keys that would improve the usability 
of our apps for use in general and especially for the disabled and for government 
contracts.

need info: So what is actually still broken here?  The dependencies are all
fixed, although one says "not in an ideal way".  Is this bug just needed to make
it ideal?  I don't see how that would be serious enough make our short list.  I
know keyboard access is important, but so are things like not crashing, not
losing your data, opening windows within your lifetime, etc.  We already have
too many bugs like that.  Please help me to understand where this fits in our
priorities.
Whiteboard: [PDT-] → [PDT-] [need info]
going...going...
does this make it difficult to create skins, or what?  it probably depends on 
where the non-"ideal" kludges are happening.
nsbeta3-, since there are workarounds in place.
Whiteboard: [PDT-] [need info] → [PDT-] [nsbeta3-] [need info]
this needs to be fixed for nsbeta3 or rtm.
The dom key events are inconsistent in implementations on the various platforms.
This prevents New Composer Page, Redo and possibly other keybindings from 
working.  It could also prevent localized keybindings from working.
in light of the conversation with pdt team today, one of two things should 
happen to this situation:
1. remove the keybinding option in the menus, or
2. fix the keybindings so they work

in the meantime, we need to test all keybinding sequences on all platforms to 
know and understand the entire issue.
Keywords: rtm
I understand the issue. Mac always sends lower case characters in the event, even 
when shift key is depressed. Linux and Windows will send upper case characters. 
We have to decide which one is right, which may be a standards issue, so we're 
waiting till joki is available on Thurs. to decide the proper fix.

Should clear "need info" since there has been an answer to trudelle's 8-16 
comments.
rtm-
Whiteboard: [PDT-] [nsbeta3-] [need info] → [PDT-] [nsbeta3-] [rtm-]
This seems fixed on the branch.

Gerv
Keywords: relnote
Yes, fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Keywords: rtm, UE1 → nsrtm
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.