47677 - shifted keybindings don't work on the Mac (such as redo)

Status: VERIFIED DUPLICATE of bug 53771

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

Description

[Akkana Peck]

Undo (cmd-Z) works on the mac, but the platform-specific Redo (cmd-shift-z)
doesn't: it flashes the redo, then it undoes.  Kathy and I are speculating that
it has something to do with shifted bindings not working, or the event being
handled twice (once shifted, once unshifted), or something like that.  Redo
works on linux (where it's bound to xul-R), so this is only an issue on the mac
(though it may show up in other shifted bindings on other platforms).

Kathy's going on sabbatical, so I'll try to look at this when I get back from
vacation, but cc'ing saari in the hope that he might also be able to help.

Comment 1

[Kathleen :Brade]

note:  this doesn't work in urlbar, inputs, or textareas.  It does work in 
Composer though.

nominating this as a dogfood bug since I can't redo and this becomes a dataloss 
then (can't get back to what I had before)

Comment 2

[Akkana Peck]

Accepting, suggesting M18, p3.

Comment 3

[leger]

Adding TRUNK ONLY to keep my sanity. For beppe to plus.  

Comment 4

[rubydoo123]

setting to nsbeta3+

Comment 5

[saari (gone)]

the shift modified binding problem again

Comment 6

[leger]

Putting on [dogfood-] radar since not critical to daily work.

Comment 7

[rubydoo123]

this really needs to go back to Kathy

Comment 8

[rubydoo123]

this is event correctness
reviewed by Bijal and beppe, setting to nsbeta3+, p2

Comment 9

[Kathleen :Brade]

someone must have fixed this (??); this now works for me (though I know it was 
broken 7 weeks ago)

Comment 10

[Kathleen :Brade]

reopen; it doesn't work today

Comment 11

[saari (gone)]

May have gotten lost/typo'd in the xul->xbl bindings conversions. Probably good 
to double check those bindings as a first step.

Comment 12

[Jim Roskind]

Undo is somewhat common, but redo is an order of magnitude less common, and
hence less critical to have a key binding for.  This doesn't make it to the PDT
criteria of high profile functionality, or obscure work-around exists (use the
menu and you should get the redo functionality).
Moving to P3, and marking PDTP3.

Comment 13

[rubydoo123]

marking nsbeta3- and setting to future. PDT downgraded to p3 which is below the
nsbeta3/rtm cutoff. If this  impacts your work or if you have a compelling
arguement, please remove the [PDTP3] and [nsbeta3-] in the status whiteboard,
enter your arguement, and set the milestone to --

Comment 14

[rubydoo123]

since this is already checked into the trunk, marking this rtm+, Kathy get the
reviews, etc and attach the patch

Comment 15

[Phil Peterson]

PDT marking [rtm-]. We have bigger fish to fry for seamonkey.

Comment 16

[saari (gone)]

The root of this bug is worse than what PDT may realize. We have a disconnect
between how a key event is constructed on MacOS vs. Windows and linux. On one, a
shift modified key is capitalized in the event, on the other it is not. This is
the root of this bug.

This will affect web designers, not just us.

We need to decide which is correct and make all the platforms send the same
thing in the event.

I'd like PDT to reconsider.

Comment 17

[Akkana Peck]

That sounds simple to fix as well as important.  I can help if we need any
changes to gtk or testing on linux.

Comment 18

[Kathleen :Brade]

remove rtm- to get back on radar of PDT

reminder:  this is a regression from a few weeks ago and affects more than this 
particular keybinding

Comment 19

[Phil Peterson]

Need to know other bad effects besides Redo on Mac before considering [rtm++].
So far, description of symptoms is pretty vague, IMO.

Comment 20

[Kathleen :Brade]

I'm not sure if this explanation will be clear enough for PDT but I'll take a 
stab at explaining this (saari or others please clarify or correct):

 * in the menu, the keybinding (for example) is shown as Command-Shift-Z (using 
Mac-standard symbols of course)  This will be confusing to users (why the 
shortcut shown doesn't work) as well as in your face.
 * many users have learned these shortcuts and won't even look at the menu; 
they'll just assume they can't create a new composer page or that they can't redo 
since they'll try it and it won't work.
 * any International keybinding with the shift modifier will also be broken
 * any JS handling of key events won't work consistently across platforms


Visible places I see this in our current branch builds (at a glance):
 * New Composer Page (command-shift-n) doesn't work
 * Redo (command-shift-z) in edit fields doesn't work
 * Redo in Mail (3pane; like for delete)
 * Reply to All (3pane mail)
 * Discontinue text styles (mail compose and Composer)
 * Fixed Width font (mail compose and Composer)
 * Text Size smaller/larger (mail compose and Composer)
 * Discontinue Link (mail compose and Composer)

Sorry I don't have time to go through the entire product at the moment (like 
Addressbook, aim, psm).  I'm sure we're seeing problems in every piece of the 
product.

Comment 21

[blee]

Same with JA IME. In 09-29-11 MN6, Both Undo and Redo work from Edit menu, but 
key combo only works for Undo (cmd+z) and not for Redo (shift+cmd+z).

Comment 22

[Phil Peterson]

Thanks for the info Kathy. Marking [rtm need info] so it's still on the radar.
Also removed TRUNK ONLY comment since I think that was meant to apply to PR3,
which is finished now.

Comment 23

[bobj]

Please test for IME regressions with this fix and any fix that twiddles with
key event handling.

Comment 24

[Kathleen :Brade]

hurray; this has finally been fixed!


*** This bug has been marked as a duplicate of 53771 ***

Comment 25

[sairuh (rarely reading bugmail)]

mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".

if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.