* 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 assigning to self.]

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.

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.

reassigning QA contact, updating XPMenus component & developer to matt. (but do lemme know if it's really saari's bug.)

As brade said looks like shift control is not working. I believe this is saari's bug.

Taking menu/popup bugs.

back to saari. mwahahaah

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus. XP Menus component will be deleted.

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.

Putting on pdt- radar for beta1. This shortcut we would not hold for. Cool is you can get it in.

Hey PDT- so I'm punting to 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.

Putting beta1 in Keywords thought PDT- and adding relnote keyword.

Is this same bug causing shift-delete to delete instead of cut?

Mass-moving most M15 bugs to 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

pardon the spam: beta1 is long gone...removing this keyword. will soon replace w/nsbeta2...

clearing out beta1 note in whiteboard, since it's past.

mass-moving all '-' bugs to 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.

updating component.

We shoudl be able to support this correctly on all platforms (if it doesn't work already). nsbeta3

Renominating for nsBeta 3

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.

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.

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.

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.

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-

This seems fixed on the branch. Gerv

Yes, fixed.